First let me say I love seam-gen, specially when run from eclipse using jboss-tools, i am starting a new project, and seam-gen has helped me impress my coworkers... I also love the architecture, I think that seam is the first web framework that makes me feel like I am using a modern version of WebObjects (I have been looking for a replacement of WebObjects everywhere, first with WebWork, then with Spring, then in ASP.NET, but now, with seam I think I have finally found it)
Well, lets start with my question:
One of the things I still miss from the equivalent of seam-gen in WebObjects, was the
single save button, what do I mean by that? well, in seam-gen if you generate the CRUD pages for 2 entites connected by a one-to-many relationship (one P to many Q), you will have to save the P first and then you can connect it with the Q, that means you can not save both of in the same
user transaction (the user has to hit the
save button 2 times). I believe that applications generated by seam-gen shouldn't have this limitation... since seam has conversations support (A thing AFAIK Webobjects didn't have) it should be possible to avoid this problem...IMHO the problem is that the
Add Q buttons in the P editor shouldn't have to add the primary key to the url, it should:
1) Store the current
master object in the conversation scope, and use that to link the Q to P
2) Add to seam (or hibernate?) the ability to automatically add a kind of
temporal primary key that would allow to select a particular
I think that the first solution should be pretty easy to implement.. I am planning on implementing it by altering the freemarker templates of seam-gen... but I am worried because I don't get why it wasn't built like this the first time, IMHO it would have been an excelent way to
show off the great conversational and transactional features of seam... is there a caveat I am not seeing?
I think the second solution might also need to be implemented... why? well, after adding several Q to P, those Q shouldn't have a primary key (after all, nothing should be saved until the save button in P is clicked) but what if I want to go back to a particular Q and modify it? how do I identify it on a grid?
I am right to think that this
single save approach should be somewhat easier to build with seam that with the other, stateless (conversationless) frameworks? how do you tipically solve the problem of the lack of primary key for an unsaved pojo that needs to be referenced from a JSF control? should I perhaps initialize the pk with a fake perhaps negative value (-1, -2, -3)? since hibernate can use the @version property to determine if a pojo was saved, then there should be no problem? could it happen that my pojo ended up being persisted with the temporary primary key? what do you recommend for this problem?
Thanks a lot, and congratulations on this new great framework site.