On 19 February 2012 13:30, Moandji Ezana <[email protected]> wrote: > On Fri, Feb 17, 2012 at 9:29 PM, Kevin Wright <[email protected]>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 > 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<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. > > Moandji > > -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
