Does working with domain objects in views have to be so hard?

[too_many_details]

Hi,

recently I have been working on a project using JSP+Spring MVC + Hibernate.

I found working with JSPs and JSTL to be quite tedious and labour intensive.

Do all view technologies have this? Ultimately I can see how you are taking an object and 'serializing' it to a web page and then reassembling it again.

I've heard that the so-called component web technologies can help - JSF/Tapestry/GWT.

Any advice on this appreciated,

Cheers

R

[tatvamasi]

Well depends on the question below

What do you call domain object? DTO or Object with behavior?

[debasishg]

I've heard that the so-called component web technologies can help - JSF/Tapestry/GWT.

It is true JSF (along with Facelets) and Tapestry offer component models as opposed to the action based frameworks like Spring MVC and Struts. But there ain't anything called free lunch. JSF has till now been successfully used in small projects - there are problems with scalability in JSF. And as far as viewing is concerned, u have to accept some form of templating - whether in Tapestry or as facelets ..

Cheers.

[Jörg Heinicke]

I can only recommend XML and XSLT. You somehow need to merge your data with something like a template, but you can do it on a much more abstract level and add the styling details later in the XSLT transformations. I also guess you can reach much higher consistency - and readability. You can also easily get a higher separation of concerns.

Jörg

PS: You might want to have a look at Apache Cocoon, with which I work mostly. (Actually I'm a committer.) Just have a look on CForms and how binding and templating is handled there.

[Bosmon]

Hi,

recently I have been working on a project using JSP+Spring MVC + Hibernate.

I found working with JSPs and JSTL to be quite tedious and labour intensive.

Do all view technologies have this? Ultimately I can see how you are taking an object and 'serializing' it to a web page and then reassembling it again.

I've heard that the so-called component web technologies can help - JSF/Tapestry

Well, I can suggest that Spring users in particular take a look at RSF (http://www2.caret.cam.ac.uk/rsfwiki ) - since unlike other view techs that merely "integrate" with Spring, it is built entirely out of Spring components. I have to admit that my recommendation isn't completely unbiased :P

RSF "is" a kind of component web technology, but unlike JSF/Tapestry the purpose of the components is not to persist on the server but be discarded at the end of the request. So while giving the abstraction benefits of a component architecture, it gives the (space) performance and idiomatic benefits of the more "stateless" technologies over the fence such as PHP and the one beginning with "R".

In terms of working with Hibernate and domain objects, the goal is to make this as effortless as possible - the "Hibernate Cookbook" contains no Spring, Hibernate or Servlet dependencies, nor any explicit persistence code http://www2.caret.cam.ac.uk/rsfwiki/...nateCookBook_4. So the tedium factor reduces considerably - although with a more ambitious architecture (e.g. ClassLoader separation) you would have to do more legwork, the same principles would apply.

The key is that RSF allows you to deliver a *particular* domain object into a handler/service on a subsequent web request without either polluting its interface, or keeping it in memory. I don't believe there is anything else out there with this capability, please correct me if I am mistaken :P

/GWT.
R

GWT is a completely parallel track which is highly interesting. *client*-side heavy component architectures make perfect sense, unlike server-side ones. GWT has in its favour the enormous muscle of Google devs, but the deficiency that part of the architecture (actually the compiler) has not been open-sourced. If you are going with a GWT-only strategy this needn't be a problem, but it does raise question marks over the long term - ideally we would like to see GWT technology "unbundled" so that it could cooperate with a wider variety of server-side technologies - at the moment the compiler assumes that it has complete control of the client pane and navigation.

There is an alternative to GWT, "Java2Script" http://j2s.sourceforge.net/ based on exactly the same principles (only where GWT has its own component set, J2S goes for the standard SWT). While *all* parts of this architecture are open sourced, the natural downside is that the dev team is much smaller - also there are question marks that the use of SWT implies an undesirably high minimum on client startup times - the GWT set was designed for this usage from the start.

Since Spring is already so admirably set up for stateless "RPC"-type arch boundaries, pure client-side techs look extremely attractive for the most highly interactive cases when simply paired up with pure Spring - perhaps there is a possibility for cooperation with Spring Remoting, although I don't see any activity in this area. But these technologies are still a little immature.

Cheers,
A.