Seam-gen: Insufficient use of conversations?

[luxspes]

Hi!
Is it just me, or the way Seam-gen creates applications uses too many query strings and parameters and almost ignores the conversational capabilities of Seam?

I mean, as you navigate the a seam-gen application the query string grows a lot, why it doesn't just keep the id of the entity selected in the first list you use and keep all the other information that is passed between pages in the conversation?

Regards,

[christian.bauer]

Because this is a demonstration of bookmarkable navigation points. You can only have one of the two.

[luxspes]

Hi!

Interesting (I think it that should  be stated somewhere in seam-gen documentation...)

I would prefer a conversation based seam-gen,why? well, I (and a friend) have been struggling with the freemarker templates to improve seam-gen (we are planning on sharing that with the community btw), but I think we are hitting the limit of the bookmarkable navigation strategy: recursive relationships.

We have found the way to extend the querystrings to support the select to connect use case, but we just can not make it work fo the add a new child use case, for that, I think we need nested conversations (without them if I try to add a child I just end up in the editor page of the parent entity instead of editing a new child). The problem is that the child could also have a another child, and that child another child (and so on and so forth) and that means we would need to dinamically handle the querystring in a way that AFAIK is not possible (or maybe just very inconvenient) with Seam... Am I right?

Any hints on how to deal with this? (Or do you recommend me to recode all my seam-gen templates take better advantage of seam conversations?)

Regards,

[dan.j.allen]

What you are describing is caused by impedance between a stateful and a stateless design. Seam goes to great lengths to allow you to be stateful while appearing stateless (RESTful URLs, natural conversations), but after a while you do have to make a choice.

If you want to get the most milage out of conversations, whilst still retaining bookmarkable URLs, I highly recommend that you take advantage of both nested conversations and workspaces. The workspaces are necessary to get the user back to the conversation in the event that the user proceeds on some tangential path and ends up dropping the conversation.

For a more detailed discussion, I do cover this exactly scenario in Seam in Action. I start with seam-gen in chapter 2, and then in chapter 7 I discuss ways that you can establish inner-relationships between conversations from seam-gen using nested relationships. As you can imagine, there is some complexity here, but the complexity is in what you want to do, not in Seam itself.

As for the reference documentation, it is not intended to be an architectural guide to Seam. It documents the features of Seam and how to make them work. Architecture discussions are better left up to books, magazine articles, seminars, and the like.

[luxspes]

Hi!

I think that perhaps the problem is that the applications generated by seam-gen need to have a better balance between the stateless and the stateful part.

For example, the navigation of a seam-gen application goes pretty much like this:

Select entity list in menu -->(No conversation)-->Entity List-->Select entity from list-->(Short conversation)-->Entity View-->(Conversation Begins)-->Entity Edit-->(Conversation Ends)-->EntityList.

It uses a Conversation for the edit part, I think that is right because that is the part that won't (shouldn't) need bookmarkable navigation, this part is intrinsically stateful (even if coding things the old way without Seam, the database will be modified by the DAOs and the general state of the system will be modified)

But, I seem a problem here: what if don't want to modify the properties of the entity, but I want to modify its relationships with other entities, then, the navigation goes like this:

Select entity list in menu --(No conversation)-->Entity List-Select entity from list--(Short conversation)-->Entity View-->Add Entity-->(Conversation Begins)-->Related Entity Edit-->Save Entity-->(Conversation Ends)-->EntityView

Again, the a conversation is used for the new related entity, but it doesn't provide much, in fact, here is where one realizes that  it also didn't help much for the other case, everything was controlled by the RequestParameters, and everything messes up if the Entity and the Related Entity are instances of the same Class

Now.. where should the conversation begin? I am thinking that maybe it is beginning in the right place, but the Entity Edit page shouldn't base its behavior on RequestParameters, it should work based only on information stored in the conversation... but then we have a another problem... pages use the EntityHome/List to do all their work, but here the EntityHome is already used by the Entity and can not be used by the New related entity... and here I start to feel really confused... what is an EntityHome? what is an EntityList? what is their relationship with a page? if a have pages thad creates Views entities of type X and that allows to add recursively entities of type X to that entity instances then... I have found a leak in the the EntityHome/EntityList abstraction? Does it  leaks just for recursive models?

Regards,

P.D.
Thanks for reminding me I needed to buy your book (I had been postponing it for a couple of months, now that I have the .pdf I will read chapter 2 and 7 ASAP, I really hope to find some clues in the book).

[dan.j.allen]

A couple of comments here:

Select entity list in menu -->(No conversation)-->Entity List-->Select entity from list-->(Short conversation)...

There is no such thing as a short conversation. There is either a temporary conversation (which really isn't a conversation at all but rather a flash scope to help survive a redirect) and a long-running conversation. Of course, a long-running conversation could be short (in time) but it is still long-running (in state).

It uses a Conversation for the edit part, I think that is right because that is the part that won't (shouldn't) need bookmarkable navigation, this part is intrinsically stateful (even if coding things the old way without Seam, the database will be modified by the DAOs and the general state of the system will be modified)

In seam-gen it's both. If you request the edit page directly, a conversation is started. For instance, you could request /CourseEdit.seam?courseId=23 and it would be no different than clicking on the edit button. The only time it stops being bookmarkable is when you are selecting a new related entity.

But, I seem a problem here: what if don't want to modify the properties of the entity, but I want to modify its relationships with other entities,

Okay, seam-gen doesn't try to produce an production-ready application. Call it a limit of code generation (or a matter of simplity) that you are not going to be returned to the original entity if you start editing a related entity. You can implement this in Seam using nested conversations, but suffice to say, seam-gen doesn't generate apps with this feature.

everything was controlled by the RequestParameters, and everything messes up if the Entity and the Related Entity are instances of the same Class

Here is where you reach the stateless/stateful impedance. Request parameters are dumb in that they see the world as always the same. Personally, I don't like using page parameters as much as they are used in seam-gen apps because you do get into trouble like this.

but here the EntityHome is already used by the Entity and can not be used by the New related entity... and here I start to feel really confused... what is an EntityHome? what is an EntityList? what is their relationship with a page? if a have pages thad creates Views entities of type X and that allows to add recursively entities of type X to that entity instances then... I have found a leak in the the EntityHome/EntityList abstraction? Does it  leaks just for recursive models?

Not so much. Remember, Seam is all about component names, so you could have 100 of the same class, as long as you have 100 different names, Seam can keep them all sorted.

I know I am not handing you a solution on a platter here, but what I am saying is that you are smarter than seam-gen. Even if we improve the seam-gen app, you are likely going to need to add the knowledge of your own domain and desired navigation paths to the application. Don't be afraid to leave the path.

[luxspes]

Hi! Thanks for answering.

There is no such thing as a short conversation.

I agree, I was meaning to say short-running (in state) but that is too long. I'll call them temporary conversations from now on.

Okay, seam-gen doesn't try to produce an production-ready application

Yes, it is missing a lot of features (but I am heavily modifying the  freemarker templates and my version of seam-gen doesn't a lot extra things like: Many2Many support, Ajax Validation, Ajax Searching, Ajax Sorting, Chained SelectOnes, Add/Select for Relationships, Ordering of FormElements, Labels for Forms Elements, and so forth, my goal is to reach the usability level of Direct2WebFramework and the NakedObjectsFramework, in fact I am taking a lot of new java annotation ideas from what I read from that last one). So I know seam-gen can evolve and produce production ready stuff.

Not so much. Remember, Seam is all about component names, so you could have 100 of the same class, as long as you have 100 different names, Seam can keep them all sorted.

Yes, but AFAIK Seam is unable (or it is really counter-intuitive/hard to use it )  to dynamically create components. In Direct2WebFramework I can navigate the object graph in any way I want, through any number of relationships and recursive relationships, that means that it is impossible to pre -define the number of required components (I could add a child, for a child, for a child, and so forth). From that point of view, the idea of one EntityHome component for each xhtml crud page just doesn't seem appropriate... and the idea 1 component for all pages doing crud on different instances of the same instance doestn seem to work... perhaps NestedConversations should come to the rescue here, but i tried with:

Select entity list in menu --(No conversation)-->Entity List-Select entity from list--(Begin conversation)-->Entity View-->Add Entity-->(Begin Nested Conversation)-->Related Entity Edit-->Save Entity-->(End Nested Conversation)-->EntityView--(End conversation)-->EntityList

And it didn't work, I am thinking that it didn't work because the  parameters make the nested conversation useless (the seam generated application uses RequestParams to know what it is doing and the conversation (nested or not) is just irrelevant)

Even if we improve the seam-gen app, you are likely going to need to add the knowledge of your own domain and desired navigation paths to the application. Don't be afraid to leave the path.

I agree, I just want to make seam-gen more helpful, I don't want it to do anything but CRUD, but I want enhance it so that if a model is representable with JPA, seam-gen is able to do CRUD with it (I know it is going to be hard, but I also think it will be worthwhile).

So, what do you think it would be the best strategy to make seam-gen more conversation-aware?

Regards,