Is it time to change the technology?

[Vince O'Sullivan]

In our dept., we're putting together JSF 2.0 applications to run on
the company intranet. They're written in Java 1.6 and hosted on a
Tomcat 6 web server on a linux box and they access data in Oracle
databases. They work fine and are proving reliable but JSF and
managing beans does seem to be something of a dark art.

The database is a given and I'd be reluctant to change either the base
language or web server that we use (but might be persuaded).

Given those restrictions, what are the most mainstream alternatives
that we might consider?

[Kevin Wright]

For sheer speed of development, I'm getting some great mileage out of twitter's bootstrap[1] on the client-side and James Strachan's scalate/jade[2] on the server.

As much as possible, I'll use restful json data sources to provide any dynamic content that populates the templates, and also handle any submitted data as json (instead of the traditional http form post technique).

You may also want to consider the play framework[3], it's a bit good!

[1] http://twitter.github.com/bootstrap/
[2] http://scalate.fusesource.org/documentation/jade-syntax.html

[3] http://www.playframework.org/ and http://www.playframework.org/2.0

[A McDowell]

Most of the issues I see clients have with JSF boil down to a few fundamentals:
 - ignorance of the JSF lifecycle (leads to all sorts of trial + error with attributes; performance issues (e.g. repeating controls are in forms))
 - not understanding state saving (leads to memory problems)
 - a lack of class design in managed beans (backing bean is a dumping ground for all sorts of cross-cutting concerns; inappropriate scoping of data)

Of course, you could probably generalize this problem. Anyone who struggles writing a correct Servlet application isn't going to fare any better when you stick JSF on top of that stack. People's eyes tend to glaze over when I suggest referring to the specifications.

Most of the work I've been doing is migrating projects off server-side frameworks to static HTML + REST. The old web tiers have used SOAP to consume services, so this approach is relatively low-impact. If you want to evaluate this approach, look at Apache Wink.

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Rakesh]

definitely consider Grails. Its the next step up without it being
completely different. The Groovy language is very nice but not too
intimidating, with the proviso you can drop into plain Java if you
need to.

The Grails framework essentially gives you a
convention-over-configuration application framework (based on
Spring/Hibernate) excellent for creating corporate CRUD apps quickly.

R

[Fabrizio Giudici]

On Fri, 10 Feb 2012 14:01:04 +0100, Kevin Wright
<kev.lee...@gmail.com> wrote:

> For sheer speed of development, I'm getting some great mileage out of
> twitter's bootstrap[1] on the client-side and James Strachan's
> scalate/jade[2] on the server.

+1 for Twitter Bootstrap, that I'm using for all my new websites, which
have dynamic parts. In this case I use a custom made CMS based on Spring
MVC. For more dynamic websites I'd try Wicket, which works very well with
HTML templates.

--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
fabrizio...@tidalwave.it
http://tidalwave.it - http://fabriziogiudici.it

[Casper Bang]

+1 for Wicket. While still statefull, infinitely better than ivory tower JSF. Easy to create and reuse components and integrate with templates.

[Casper Bang]

[Cédric Beust ♔]

Agree with this, today, I would use Play, Bootstrap and jQuery in a heartbeat.

You'll get up to speed in no time and after that, you can iterate to make your site more customized.

-- 

Cédric

[Cédric Beust ♔]

Oh and for templating, Freemarker if you need to generate on the back end, Mustache or Handlebars for the front end (they're not mutually exclusive).

-- 

Cédric

[Alex Turner]

I have to say, I got a bit disillusioned with Grails. It's kind of messy, and pretty slow. I like what it can do, and the syntax is an upgrade from plain Java, but it's just not that great once you end up with a more complex system than a couple of dozen model classes.

I've heard good things about Play with Scala, I think I'm gonna check that out next.

Alex

[Joe Sondow]

Alex, I'll acknowledge that Grails is slow, but can you elaborate
about what makes it messy? Would your complex system with dozens of
model classes be more organized in a different framework? I'm not
arguing, I'm just curious.

On Feb 11, 9:32 pm, Alex Turner <alexrmtur...@gmail.com> wrote:
> I have to say, I got a bit disillusioned with Grails.  It's kind of messy, and pretty slow.  I like what it can do, and the syntax is an upgrade from plain Java, but it's just not that great once you end up with a more complex system than a couple of dozen model classes.
>
> I've heard good things about Play with Scala, I think I'm gonna check that out next.
>
> Alex
>
> On Feb 10, 2012, at 5:22 AM, Rakesh wrote:
>
>
>
>
>
>
>
> > definitely consider Grails. Its the next step up without it being
> > completely different. The Groovy language is very nice but not too
> > intimidating, with the proviso you can drop into plain Java if you
> > need to.
>
> > The Grails framework essentially gives you a
> > convention-over-configuration application framework (based on
> > Spring/Hibernate) excellent for creating corporate CRUD apps quickly.
>
> > R
>

> > On 10 February 2012 11:56, Vince O'Sullivan <vjosulli...@gmail.com> wrote:
> >> In our dept., we're putting together JSF 2.0 applications to run on
> >> the company intranet.  They're written in Java 1.6 and hosted on a
> >> Tomcat 6 web server on a linux box and they access data in Oracle
> >> databases.  They work fine and are proving reliable but JSF and
> >> managing beans does seem to be something of a dark art.
>
> >> The database is a given and I'd be reluctant to change either the base
> >> language or web server that we use (but might be persuaded).
>
> >> Given those restrictions, what are the most mainstream alternatives
> >> that we might consider?
>
> >> --
> >> You received this message because you are subscribed to the Google Groups "The Java Posse" group.
> >> To post to this group, send email to java...@googlegroups.com.
> >> To unsubscribe from this group, send email to javaposse+...@googlegroups.com.

> >> For more options, visit this group athttp://groups.google.com/group/javaposse?hl=en.

[mgkimsal]

I'm working on a Grails project with 162 domains so far (20ish of them
are mostly empty subclassed shells, but the rest aren't). As I work
through it, I find myself wondering how I'd build this if I started
from scratch, either in Grails or something else, to have things be
'less messy'. I'm not sure it's really possible, to the extent I want
it to be, while still being able to hit any reasonable deadlines for
delivering business goals.

Much of the 'messiness' I see in this project are the same sorts of
things I've encountered on other large projects in Grails, PHP and
even in one case Rails (smaller, but it still got messy imo): devs on
the team change; devs changed their mind about an approach and didn't
go back to refactor earlier code; few or no tests in place; lack of
up to date documentation for devs or end-users. None of these are
encouraged by Grails, or indeed any other language/platform.

So yes, I'd also like to hear about the 'messiness' and how something
like Play would make a project not messy. I'll grant that starting
over from scratch will give the feeling of non-messiness to start
with, but much of the feelings of 'messy' from projects have far more
to do with developer discipline and understanding of their own tools
vs anything inherent in a particular platform.

[Rakesh]

as impressed as I am with Grails, I should point out that it really
makes a difference if you are building a typical web app - 3 tier
architecture with DAOs, Service Layer and pretty much CRUD.

If you don't want that, then Grails is not for you.

As much as I see its value, I have to point out that there is a
learning curve to learning Groovy and the way Grails does things.

My app has a requirements where the war file is created ONCE and then
pushed through the environments and eventually ending up in prod (with
various test phases along the way).

This is not the preferred Grails way however and I spent many days
circumventing the build system to get it to do what I want (and I
still feel its a hack).

I really, really like Groovy. However, it will take time to get used
to and use it appropriately. I still forget the sort of magic you can
do (because its so non-obvious). Like with maps (reference key as if
attribute) and Expando and MockFor and StubFor, etc...

So I guess what I'm saying is do your due diligence for suitability,
then plan some time to learn it and make mistakes - don't push for it
on the first business critical project that comes along because you
think you can develop it quickly (because thats what you heard on a
forum somewhere).

Thanks

R

[Alex Turner]

Maybe it's just my poor knowledge of Grails, but I couldn't find a way to create domain objects in different packages.  Once I started needing domain objects for deserialized things like facebook data, sometimes with names that overlapped, it became kind of a nightmare.  I also find the mixture of Groovy syntax and Java syntax a bit off-putting.  You're never quite sure which syntax you need for a method declaration.  Whilst a higher level of familiarity with language details might fix that, I think one of the main arguments for Grails is the shallow learning curve, so I think I'm probably not the only person who gets going very quickly, only to find things like this further down the road that become stumbling blocks.  It's hard once you become accustomed to things just falling together in a framework to suddenly be struggling with something that seems so basic.

On the flip-side is the amazing speed at which you can prototype.  The simplicity of the structure makes things go very fast for a smaller system.  I love the way service objects work, and gsp is pretty darn good.

Once the system gets bigger, the cycle time from changing a file to seeing it updated on the site can get pretty gnarly.  Grails seems to have an increasing propensity to bomb-out when a file changes the larger the system gets, and I find myself having to restart the container pretty frequently, which is painfully slow.  Any speed in the beginning is lost with interest further down the line it seems.

I did find Groovy to be a great gateway drug into Scala, and with SBT and FSC, many of the problems with cycle time go away.  Same goes for syntax.  Scala syntax is cleaner than grails.  I just haven't looked at Play yet, so I have no idea if it has the same rapid development capabilities that Grails does.

Alex

[Wayne Fay]

> My app has a requirements where the war file is created ONCE and then
> pushed through the environments and eventually ending up in prod (with
> various test phases along the way).
>
> This is not the preferred Grails way however and I spent many days
> circumventing the build system to get it to do what I want (and I
> still feel its a hack).

Feel like sharing how you did it? This is a best practice at many
organizations due to change controls.

Wayne

[phil swenson]

Dead on. What Cedric said.

2012/2/10 Cédric Beust ♔ <ced...@beust.com>:

[Lenny P]

-1 for Wicket.
We did a web framework bake-off and wicket lost for 2 reasons:
designer friendliness (lack thereof) and violation of the DRY
principle.
(see http://groups.google.com/group/javaposse/browse_thread/thread/5a133dc17ca63462
)
We are now using Tapestry with Glassfish with both Java and Groovy
page classes
and it is working wonders!

[phil swenson]

does wicket still have troubles with restful URLs?

[phil swenson]

here is an example of a wicket URL (for artifactory):
http://artifactoryserver:8082/artifactory/webapp/?wicket:interface=:2::::

Horrible!

[Fabrizio Giudici]

On Thu, 16 Feb 2012 18:40:49 +0100, phil swenson <phil.s...@gmail.com>
wrote:

> here is an example of a wicket URL (for artifactory):
> http://artifactoryserver:8082/artifactory/webapp/?wicket:interface=:2::::
>
> Horrible!

It's possible to "mount" a pretty-looking URL in place of that stuff.

[Kevin Wright]

Just spotted this on DZone.  It might be relevant: http://css.dzone.com/articles/comparing-web-frameworks-and

[Fabrizio Giudici]

On Fri, 17 Feb 2012 14:26:00 +0100, Kevin Wright
<kev.lee...@gmail.com> wrote:

> Just spotted this on DZone. It might be relevant:
> http://css.dzone.com/articles/comparing-web-frameworks-and

Interesting. Lift would be even worse than JSF, and Play not much better.

[Josh Berry]

On Fri, Feb 17, 2012 at 9:39 AM, Fabrizio Giudici
<Fabrizio...@tidalwave.it> wrote:
> On Fri, 17 Feb 2012 14:26:00 +0100, Kevin Wright <kev.lee...@gmail.com>
> wrote:
>
>> Just spotted this on DZone.  It might be relevant:
>> http://css.dzone.com/articles/comparing-web-frameworks-and
>
>
> Interesting. Lift would be even worse than JSF, and Play not much better.

I'm curious what makes Lift so bad. Having templates that are 100%
html is something that still looks highly enticing to me. The css
based replacement mechanism looks very strong. (I have only done a
few toy projects in lift, but to say there are more than a few
features from it I always wish I had would be an understatement.)

Or are you just referring to how stateful it is? I'm still not
convinced that is a poor choice. I was under the impression JSF was
bad because of the odd lifecycle of everything.

[Kevin Wright]

"worse" on what dimension?

All of these frameworks have to be measured on several criteria:

• availability of support
• strength of community
• designer-friendliness of templates
• maturity
• stagnation
• flexibility
• performance
• scalability
• robustness
• statefulness
• programming language support
• internationalisation
• separation of concerns
• verbosity/tendency towards boilerplate
• presence of built-in patterns that fit your domain
• interaction with client-side frameworks/technology
• interaction with other server-side frameworks in your stack
• is it a complete self-contained solution?
• etc.

Every single framework listed there is simultaneously both "best" and "worst".  It all depends on context!

is it suited for REST? for a client-facing app?

[Fabrizio Giudici]

On Fri, 17 Feb 2012 16:34:14 +0100, Kevin Wright
<kev.lee...@gmail.com> wrote:

> "worse" on what dimension?

Don't ask me, of course, ask the presentation author :-) I see a diagram
where frameworks are ordered by a certain score, which if I understand
well is created by summing intermediate values. It's not clear to me who
gave those values.

[phil swenson]

The grid doesn't seem useful to me. Maybe if I heard the presentation
I'd see the value.

You have to make some value judgements.

To me the values are off the top of my head (with no weighting or
order, and probably incomplete):
1) restful URLs
2) ease of development/productivity
3) performance
4) active community
5) ability for designers to "tweak" (easy CSS/HTML tweaks w/o having
to build/restart)
6) intuitiveness
7) ease of testing
8) weight (is it huge, does it take forever to start?)
9) extensibility

Rails wins on all this except performance, but it's ruby which is a
non-starter for most Java shops
From what I see Play is the best Java alternative. It has much of the
rails philosophy, ease but it's in Java.

I also say this without developing a major app in Play. I'd like to
hear other's thoughts on this who have used Play extensively.

[Kevin Wright]

I've used play a bit, both 1.x and fledgeling 2.0 (currently at RC2)

For both versions, tweakability is fantastic.  Not just in CSS and HTML, but also in the underlying source files.

v1.x can sometimes be a bit slow for changes to Scala source, but works fantastically well for groovy and Java (the core template framework was groovy-native).  V2.0 is Scala native and works quickly across the board, using the dependency tracking from sbt to optimise rebuild times.  So a very good score on points 2,3,5 and 7

It's very restful and intuitive, the routing config is a joy to use (points 1 & 6): http://www.playframework.org/documentation/1.2.4/routes

It's extensible, with a wide range of modules available (point 9): http://www.playframework.org/modules

It's also very fast (point 3), with the slowest bit being the groovy-based templating in 1.x.  Scala's static typing in 2.x is a much better fit for the JVM, so there's no reason to expect it would run slower than any other JVM-based framework.

My only critique is that I prefer scalate's jade templating language over play's own templates.  But there's a module available for that, so it's really not a very big complaint :)

[Cédric Beust ♔]

Kevin, that's an awesome list.

-- 

Cédric

--

[Cédric Beust ♔]

On Fri, Feb 17, 2012 at 9:35 AM, Kevin Wright <kev.lee...@gmail.com> wrote:

My only critique is that I prefer scalate's jade templating language over play's own templates.  But there's a module available for that, so it's really not a very big complaint :)

This is another important aspect for a web framework, in my opinion: being template technology neutral.

There are many, many ways to generate content with templates. First the back-end/front-end dichotomy. On the back-end, you have Freemarker, maybe Velocity (kinda abandoned I think?), Scalatra and then the web frameworks' own templating mechanisms.

On the front-end, you have another embarrassing of riches, such as Mustache or Handlebars. Going even further, you can reconfigure your CSS with on-the-fly technologies such as Less, or generate them statically and including them the normal way.

And of course, the web framework must also be at least Javascript neutral and ideally, offer some kind of integration with mainstream Javascript technologies such as jQuery.

-- 

Cédric

[phil swenson]

All good points Cedric. So which framework meets these criteria?

2012/2/17 Cédric Beust ♔ <ced...@beust.com>:

[Serge Boulay]

too bad about velocity .. I rather liked the syntax. Has anyone tried  thymeleaf ? Looks like a pretty nice server side templating system.

http://www.thymeleaf.org/

2012/2/17 Cédric Beust ♔ <ced...@beust.com>

[Cédric Beust ♔]

On Fri, Feb 17, 2012 at 10:59 AM, phil swenson <phil.s...@gmail.com> wrote:

All good points Cedric.  So which framework meets these criteria?

No idea, I don't know much about web frameworks :-)

-- 

Cédric

[Moandji Ezana]

2012/2/17 Cédric Beust ♔ <ced...@beust.com>

This is another important aspect for a web framework, in my opinion: being template technology neutral.

Since any decent templating engine can easily be invoked programmatically, I don't even see a reason for a server-side framework to make any templating choice at all.

For modern web applications, I don't really get the point of server-side frameworks that do more than serve up data.

Moandji

[Kevin Wright]

On Feb 17, 2012 6:44 PM, "Cédric Beust ♔" <ced...@beust.com> wrote:
>
> On Fri, Feb 17, 2012 at 9:35 AM, Kevin Wright <kev.lee...@gmail.com> wrote:
>>
>> My only critique is that I prefer scalate's jade templating language over play's own templates.  But there's a module available for that, so it's really not a very big complaint :)
>
>
> This is another important aspect for a web framework, in my opinion: being template technology neutral.
>
> There are many, many ways to generate content with templates. First the back-end/front-end dichotomy. On the back-end, you have Freemarker, maybe Velocity (kinda abandoned I think?), Scalatra and then the web frameworks' own templating mechanisms.

Not quite, Scalatra is an entire framework in its own right, heavily inspired by ruby's Sinatra framework (see! It doesn't only have rails...)

Scalatra then uses the scalate scala-based template engine, which is the latest brainchild of James Strachan (creator of Groovy)

> On the front-end, you have another embarrassing of riches, such as Mustache or Handlebars. Going even further, you can reconfigure your CSS with on-the-fly technologies such as Less, or generate them statically and including them the normal way.
>
> And of course, the web framework must also be at least Javascript neutral and ideally, offer some kind of integration with mainstream Javascript technologies such as jQuery.
>
> -- 
> Cédric
>
>

[Cédric Beust ♔]

Yes, sorry, I meant Scalate, not Scalatra.

-- 

Cédric

[Kevin Wright]

This is certainly the REST ideal, but it's not so simple as it sounds. Even in a rich-client environment you can still expect back end servers to:

Handle json serialisation/parsing
Manage routing to restful endpoints
Perform caching and gzip compression
Co-ordinate chunked http streams
Convert coffeescript to Javascript
Convert less/sass to CSS
Minify/aggregate resources
Marshall data across domain boundaries
Authorisation/authentication/oauth/ssh termination
Etc.

even with a client-side framework like bootstrap, I still prefer to generate the html from jade templates, it allows for better Modularity.

"just" serving up data really isn't all that trivial...

--

[Fabrizio Giudici]

On Fri, 17 Feb 2012 20:29:30 +0100, Kevin Wright
<kev.lee...@gmail.com> wrote:

> This is certainly the REST ideal, but it's not so simple as it sounds.
> Even
> in a rich-client environment you can still expect back end servers to:
>
> Handle json serialisation/parsing
> Manage routing to restful endpoints
> Perform caching and gzip compression
> Co-ordinate chunked http streams
> Convert coffeescript to Javascript
> Convert less/sass to CSS
> Minify/aggregate resources
> Marshall data across domain boundaries
> Authorisation/authentication/oauth/ssh termination
> Etc.

Agreed. My ideal requirement is that the web framework, starting from
Cédric's principles, has got a core that only serves data, as Moandji
said. All the other things should be provided by add ons (libraries,
plug-ins, etc...) that I only add when I need.

[Mark Derricutt]

Out of actual, honest to goodness curiosity - why are "restful URLs" a good, desired thing?

That all depends on the type of webframework, or the type of application your writing.  For "web sites" I can see restful URLs that are -stateless- would be useful. "restful URLs" that also use fragments are client side only so don't really relate to server frameworks.....

--
"Great artists are extremely selfish and arrogant things" — Steven Wilson, Porcupine Tree

On Sat, Feb 18, 2012 at 5:39 AM, phil swenson <phil.s...@gmail.com> wrote:

1) restful URLs

[Kevin Wright]

The main win for me using rest (get requests) as opposed to e.g.  soap (post requests), is cacheability.

Fronting such a service with a varnish cache is about as easy as it gets.  Even in the face of rapidly changing data, varnish works perfectly well with cache times down to 1/2 a second. This may not seem very useful at first, but it can make a significant difference when scaling up to thousands or millions of hits per hour.

If latency is even more critical than that, or if caching doesn't make sense because your clients all have distinct results, then I'm a big fan of json over chunked/streaming http - at least until Web sockets become a great deal more prevalent.

[phil swenson]

1) restful urls often indicate what they are showing
(http://blah/users/philswenson/profile)
2) more importantly, they are sharable and bookmark-able. It's
important when you want to send a link to someone to share the exact
state/location of the application/data

[Joe Sondow]

When applied to URLs, the word "restful" is one of those words that a
lot of people feel strongly about even if they don't completely agree
with others about the exact definition. I would generalize the
sentiment by describing the desirable kind of URLs as "intuitive" or
"pretty". Prettiness matters. It matters in code, in UI design, in
naming, in visual metaphors, and in the poetry of short helpful
documentation. URLs straddle the border between being an API concern
and a human user interface concern. URLs are both. For your web app to
have a good user experience for application developers accessing it
(such as Google's web crawler) and also for people using a web
browser, the URLs should be short, semantic, consistent, and
predictable. If I can hover over a link and understand where it will
send me just by reading the URL then I can make a better decision
about whether I want to bother clicking on it.

[Moandji Ezana]

On Fri, Feb 17, 2012 at 9:29 PM, Kevin Wright <kev.lee...@gmail.com> wrote:

This is certainly the REST ideal, but it's not so simple as it sounds. Even in a rich-client environment you can still expect back end servers to:

Handle json serialisation/parsing
Manage routing to restful endpoints
Perform caching and gzip compression
Co-ordinate chunked http streams
Convert coffeescript to Javascript
Convert less/sass to CSS
Minify/aggregate resources
Marshall data across domain boundaries
Authorisation/authentication/oauth/ssh termination

I agree with Fabrizio: most of those things should be handled by other libraries. The web framework should just translate HTTP to Java, Scala, etc. and back. From there, a well-designed framework would make it easy to integrate wro4j, Jackson/Gson, my favourite templating engine, an ORM, etc. It would be great if such a web framework could be built around just @Inject or maybe CDI, so as to minimise its impact while easing integration.

even with a client-side framework like bootstrap, I still prefer to generate the html from jade templates, it allows for better Modularity.

I was just reading a 37 Signals blog post about how they do exactly this. Instead of passing JSON to the client, they pass server-rendered HTML. A previous bad experience with a project that did that made me wary of the approach, but now I'm rethinking my stance. With a good templating engine (ie. not JSP) and a disciplined approach, maybe it could work well.

Moandji

[Cédric Beust ♔]

On Sun, Feb 19, 2012 at 5:30 AM, Moandji Ezana <mwa...@gmail.com> wrote:

I was just reading a 37 Signals blog post about how they do exactly this. Instead of passing JSON to the client, they pass server-rendered HTML. A previous bad experience with a project that did that made me wary of the approach, but now I'm rethinking my stance. With a good templating engine (ie. not JSP) and a disciplined approach, maybe it could work well.

I think there are valid reasons to follow this approach, the most important to me being: what language is more convenient for you to render the template? There are a few cases where Java's module support can lead to more reusability/maintenance than Javascript when you start generating complex HTML+CSS stuff. This also applies when the UI composition is done on the back-end with something like GWT, obviously. Obviously, another advantage is a more unified stack (everything is done in Java/Scala as opposed to having to throw HTML/CSS/Javascript in the mix).

-- 

Cédric

[Fabrizio Giudici]

On Sun, 19 Feb 2012 18:51:54 +0100, Cédric Beust ♔ <ced...@beust.com>
wrote:

> On Sun, Feb 19, 2012 at 5:30 AM, Moandji Ezana <mwa...@gmail.com> wrote:
>
>> I was just reading a 37 Signals blog

>> post<http://37signals.com/svn/posts/3112-how-basecamp-next-got-to-be-so-damn-fast-without-using-much-client-side-ui>about

>> how they do exactly this. Instead of passing JSON to the client, they
>> pass server-rendered HTML. A previous bad experience with a project that
>> did that made me wary of the approach, but now I'm rethinking my stance.

>> With a good templating engine <http://www.jamon.org> (ie. not JSP) and a

>> disciplined approach, maybe it could work well.
>>
>
> I think there are valid reasons to follow this approach, the most
> important
> to me being: what language is more convenient for you to render the
> template? There are a few cases where Java's module support can lead to
> more reusability/maintenance than Javascript when you start generating
> complex HTML+CSS stuff. This also applies when the UI composition is done
> on the back-end with something like GWT, obviously. Obviously, another
> advantage is a more unified stack (everything is done in Java/Scala as
> opposed to having to throw HTML/CSS/Javascript in the mix).

After so many years, a thing that I still don't like, but it's present in
FreeMarker, Play, etc..., is that templating uses a syntax other than
HTML. This is fine for pure programmers, not good when a graphic designer
must be involved - or when you want to use a HTML editor. I prefer an
approach where everything is HTML.

[Kevin Wright]

On 19 February 2012 21:48, Fabrizio Giudici <Fabrizio...@tidalwave.it> wrote:

On Sun, 19 Feb 2012 18:51:54 +0100, Cédric Beust ♔ <ced...@beust.com> wrote:

On Sun, Feb 19, 2012 at 5:30 AM, Moandji Ezana <mwa...@gmail.com> wrote:

I was just reading a 37 Signals blog post<http://37signals.com/svn/posts/3112-how-basecamp-next-got-to-be-so-damn-fast-without-using-much-client-side-ui>about how they do exactly this. Instead of passing JSON to the client, they

pass server-rendered HTML. A previous bad experience with a project that
did that made me wary of the approach, but now I'm rethinking my stance.

With a good templating engine <http://www.jamon.org> (ie. not JSP) and a

disciplined approach, maybe it could work well.

I think there are valid reasons to follow this approach, the most important
to me being: what language is more convenient for you to render the
template? There are a few cases where Java's module support can lead to
more reusability/maintenance than Javascript when you start generating
complex HTML+CSS stuff. This also applies when the UI composition is done
on the back-end with something like GWT, obviously. Obviously, another
advantage is a more unified stack (everything is done in Java/Scala as
opposed to having to throw HTML/CSS/Javascript in the mix).

After so many years, a thing that I still don't like, but it's present in FreeMarker, Play, etc..., is that templating uses a syntax other than HTML. This is fine for pure programmers, not good when a graphic designer must be involved - or when you want to use a HTML editor. I prefer an approach where everything is HTML.

The catch here is that HTML is a *terrible* format for the way we use it.  HTML grew out of SGML, and is still fundamentally a format that grew from the demands of publishing printed material; large blocks of text with the occasional special character, image, table, or heading. 

Web pages aren't structured like this.  They're, well, much more structured!  They're complex layouts with dynamic content, and rich semantic meaning - a world apart from the chapter/paragraph model used in traditional publishing.

With XML/XHTML it gets worse.  We not only ramp up the number of elements demanded by ever-richer content, but also have the rule that each element must be 'closed' so that we can maintain structural validity even whilst manipulating those elements.  It's an explosion of boilerplate in a format taken far outside of its original use-case.

Sad but true...  HTML is still a necessity for no other reason than tool support.  Even then, attempts to use HTML as a templating language have often been less than successful; I'm sure we all remember how many earlier tools would just choke and die when encountering JSP's <% %> and other such non-standard tags from alternate frameworks.

Because of this mess, most web devs I know nowadays won't use that approach any more.  They'll take assets supplied by designers (single images for buttons, borders, etc) and compose them in whatever non-html language is being used.  The round-trip time in the current crop of tools (play/rails/grails/etc.) is essentially instant, so the approach works well.

[Kevin Wright]

On 19 February 2012 13:30, Moandji Ezana <mwa...@gmail.com> wrote:

On Fri, Feb 17, 2012 at 9:29 PM, Kevin Wright <kev.lee...@gmail.com> wrote:

This is certainly the REST ideal, but it's not so simple as it sounds. Even in a rich-client environment you can still expect back end servers to:

Handle json serialisation/parsing
Manage routing to restful endpoints
Perform caching and gzip compression
Co-ordinate chunked http streams
Convert coffeescript to Javascript
Convert less/sass to CSS
Minify/aggregate resources
Marshall data across domain boundaries
Authorisation/authentication/oauth/ssh termination

I agree with Fabrizio: most of those things should be handled by other libraries. The web framework should just translate HTTP to Java, Scala, etc. and back. From there, a well-designed framework would make it easy to integrate wro4j, Jackson/Gson, my favourite templating engine, an ORM, etc. It would be great if such a web framework could be built around just @Inject or maybe CDI, so as to minimise its impact while easing integration.

Just to clarify:  I didn't mean to imply that a single back-end framework should perform all these roles, just that they're all tasks to be handled on a server or servers as opposed to happening client-side.

I'm in total agreement that a good framework will allow you to abstract various responsibilities and choose whatever best-of-breed component you need for the task.  I'd even go so far as to say that the Java servlet and servlet container specification is often too monolithic here, and prefer working with self-contained frameworks such as blueeyes or spray-can then choosing my own JSON serialiser, template engine, etc. whilst outsourcing SSH termination, compression, caching, load-balancing and suchlike to a separate server

[Mark Derricutt]

For this I'm quite liking the look of Spark:

  http://www.sparkjava.com/readme.html

It's extremely minimal and works well with Guice etc.

--
"Great artists are extremely selfish and arrogant things" — Steven Wilson, Porcupine Tree

[Fabrizio Giudici]

On Sun, 19 Feb 2012 23:39:22 +0100, Kevin Wright
<kev.lee...@gmail.com> wrote:

> With XML/XHTML it gets worse. We not only ramp up the number of elements
> demanded by ever-richer content, but also have the rule that each element
> must be 'closed' so that we can maintain structural validity even whilst
> manipulating those elements. It's an explosion of boilerplate in a
> format
> taken far outside of its original use-case.

I don't understand why so many people (not only Kevin) see XML as a
problem, while I see XHTML an improvement over HTML, and don't see tons of
boilerplate. But I understand the remainder of the points.

>
> Sad but true... HTML is still a necessity for no other reason than tool
> support. Even then, attempts to use HTML as a templating language have
> often been less than successful; I'm sure we all remember how many
> earlier
> tools would just choke and die when encountering JSP's <% %> and other
> such
> non-standard tags from alternate frameworks.

Exactly. But what I meant was precisely templating by HTML tags, not
"quasi-HTML" tags. For instance, Wicket basically uses plain HTML.

[Moandji Ezana]

On Mon, Feb 20, 2012 at 10:13 AM, Mark Derricutt <ma...@talios.com> wrote:

For this I'm quite liking the look of Spark:

  http://www.sparkjava.com/readme.html

It's extremely minimal and works well with Guice etc.

I tried it out and found it *too* minimal. For example, you're left to deal with converting request parameters to objects by yourself. Also, all the controllers have to be singletons, which kind of negates some of the benefits of a DI framework. Finally, the code base is extremely monolithic, with lots of static calls, which makes it hard to modify in any way (I tried).

Moandji 

[Deniz Oğuz]

Sorry for waking up a 4 months old thread. We are a JSF focused company and not tried any of the client side template alternatives like Mustache.js, Dust.js etc. In our new project RESTful web services will have a major part. Being a POST based framework JSF has some nuisances with RESTFul web services. If there are anyone who tried both jsf and client side templates + REST alternatives, could you share your experiences with both alternatives?

[Kevin Wright]

For purely client-side stuff, my favourite stack right now is:

http://twitter.github.com/bootstrap/ + http://backbonejs.org/

As for the underlying REST service, the world is your oyster. Almost all Java web frameworks have an offering in that space, and even over here in Scala-land we're spoilt for choice with scalatra, lift, play-lite, unfiltered, finagle, bowler, blueeyes, circumflex and spray.

For server-side templating, I think you'd really struggle to find a cleaner solution than either Play or James Strachan's Scalate framework.

[phil swenson]

javascript is also really taking off on the server side:

checkout node.js, backbone, and meteor

> --
> You received this message because you are subscribed to the Google Groups

[clay]

I have used JSF 1.x quite a bit: it was pretty terrible. There is no good reason to use it.

I've built web apps with REST (Jersey) web services + client side HTML/JS with jQuery and ExtJS but without a server-side HTML templating piece. I love this approach, but sometimes a server-side HTML templating framework is neeeded, in which case Play seems like the most elegant choice today.

Client side templates? Is this where HTML is generated by client-side JavaScript from web services data?

[Deniz Oğuz]

If you consider an enterprise application that will have a few hundred forms in a 3 years period, do you think that it will be manageable if client side is completely implemented in html/js?

--

You received this message because you are subscribed to the Google Groups "Java Posse" group.

To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/XLf0AHrd-7YJ.

[Fabrizio Giudici]

On Wed, 27 Jun 2012 01:48:59 +0200, clay <clayt...@gmail.com> wrote:

> I have used JSF 1.x quite a bit: it was pretty terrible. There is no good
> reason to use it.

I don't like JSF too, but please let's not refer to JSF 1.x. It's like
bashing EJBs referring to EJB 1.x or 2.x.

[Moandji Ezana]

On Wed, Jun 27, 2012 at 1:48 AM, clay <clayt...@gmail.com> wrote:

I've built web apps with REST (Jersey) web services + client side HTML/JS with jQuery and ExtJS but without a server-side HTML templating piece. I love this approach, but sometimes a server-side HTML templating framework is neeeded, in which case Play seems like the most elegant choice today.

Play's templating system is great. If you can't use Play or really want to stick to Java, you can get an almost as good experience with Jamon, which has the advantage of being a standalone templating library, rather than a full-stack framework.

 

Client side templates? Is this where HTML is generated by client-side JavaScript from web services data?

Yes, that's what mustache.js and others do.

Moandji

[Moandji Ezana]

On Wed, Jun 27, 2012 at 7:11 AM, Deniz Oğuz <deni...@gmail.com> wrote:

If you consider an enterprise application that will have a few hundred forms in a 3 years period, do you think that it will be manageable if client side is completely implemented in html/js?

If you have people who know html & js well and choose some good client-side frameworks, it should be OK. But if your app is fairly static and mostly about server-side validation, then a good middle way might be to have good server-side templating tools and send partial, server-rendered HTML over AJAX. 37Signals recently implemented this approach for Basecamp: http://37signals.com/svn/posts/3112-how-basecamp-next-got-to-be-so-damn-fast-without-using-much-client-side-ui

Moandji

[Jeb Beich]

Sencha ExtJS is pretty well suited to that. Somewhat of a learning curve, but very powerful framework, great support, and widely used (for all js/html/css client).

--
Jeb Beich
http://www.red-source.net/jeb