Seam Conversations - Best practices?

[rapowder]

Hello,

I am developing a webclient application using Seam 1.2.1, Hibernate and a Postgres DB on a Jboss 4.0.5.GA server.
There is a tab menu that allows to select the category and list all items of this category. Each item can be clicked to edit its properties.

So far, to handle the navigation between one page and the other I used conversations (a "root" conversation for the categories and a nested conversation to edit an item) because I need to keep in memory in which category I find myself, and which item I am editing.

So far so good, but now I added some "super-categories", clicking on which the corresponding sub-categories are shown. The links are implemented as

<s:link value="CategoryName" action="cat_action" propagation="join"/>

Sometimes I get errors (item lists not correctly updated, wrong item is still in the context) caused by random clicking on the various links.
So I am not sure that conversations are the best solution to handle this kind of navigation.

Can anyone suggest a "best practice" in such a case? Thank you!

[pmuir]

I would seam-gen up an application, add a couple of CRUD entities and take a look at the approach used there - it's what we would recommend. You "nest" as many CRUDs as you like using this pattern - it's simple to extend.

[rapowder]

sorry but what you mean by seam-gen up an application? could you give me a small example? ..I'm not yet an advanced user of seam, started a couple of months ago.. thank you!

[pmuir]

http://docs.jboss.com/seam/1.3.0.ALPHA/reference/en/html/gettingstarted.html

[delphi'sghost]

I would seam-gen up an application, add a couple of CRUD entities and take a look at the approach used there - it's what we would recommend. You "nest" as many CRUDs as you like using this pattern - it's simple to extend.

I did try to seam-gen up an application using my dummy dev database (Projects, and Issues per project), and it simply created pages to list, view and edit the projects or issues. I'm not sure whether it was supposed to pick up on the foreign key and list the issues per project or not, but it didn't work with either Seam 1.2.1 or 1.3 Alpha (I'm using mySQL for test dev work).

So, with that in mind, I'm not quite sure what you mean by nesting CRUDs, but does it handle sharing the persistence contexts between multiple nested conversations and only flushing the item you are editing? Based on the docs and my experiences, nested conversations are about providing multiple continuation points within the same conversation as opposed to having the same amount of work in just one conversation.
Nesting is fine for browsing (i.e. breadcrumbs), but it seems that only one editing page can be involved in one conversation at a time when the flushMode is manual. While the logical flow may only provide one edit page within a conversation at a time, there is still the "open in new window" that could result in multiple editors within the conversation and an ensuing chaos.

I'm trying out a single conversation view page with the edit Widget page, and the Widget subDetail editing taking place in new separate top level conversations without any nesting involved. This way, the user can open editors in new windows, or tabs, without any dire consequences. I pass the Ids to the urls in an slink with a propagation of none, and the links are bookmarkeable.

Part of the reason for this was the lack of an immediately obvious way to click on a subDetail item to edit it which would then POST my changes to the currently edited widget , start a new conversation for the subDetail editor, and pass over some kind of value from the old conversation indicating which subDetail I am supposed to be editing. The s:link with propagation and a param does all that, except for the POST, hence it is being launched from a view only page.

It feels like the only option left, but at the same time, it feels like I'm only using a fraction of the power of Seam to do master/detail editing which is the bread and butter of software development. (Generate CRUD which is a close second is something Seam excels at). Alternatively, I could be using it exactly in the right way it was designed to be used for this particular scenario. It's hard to tell without any kind of standard best practices of how to use the different elements within seam. The examples highlight particular parts of the framework as opposed to demonstrating how to use them all together.

[pmuir]

"Delphi's Ghost" wrote:
I did try to seam-gen up an application using my dummy dev database (Projects, and Issues per project), and it simply created pages to list, view and edit the projects or issues. I'm not sure whether it was supposed to pick up on the foreign key and list the issues per project or not, but it didn't work with either Seam 1.2.1 or 1.3 Alpha (I'm using mySQL for test dev work).

No, I don't think it does this, though it could be a nice extension.

So, with that in mind, I'm not quite sure what you mean by nesting CRUDs, but does it handle sharing the persistence contexts between multiple nested conversations and only flushing the item you are editing?

Normally, you would have a (SM)PC associated with the outer conversation, which would then be used by nested conversations. If you want to only flush certain changes, then you *don't* want to share the PCs.

Based on the docs and my experiences, nested conversations are about providing multiple continuation points within the same conversation as opposed to having the same amount of work in just one conversation.
Nesting is fine for browsing (i.e. breadcrumbs), but it seems that only one editing page can be involved in one conversation at a time when the flushMode is manual.

I sort of follow what you are saying. If you have one SMPC, then when you flush it *any* changes made to entities loaded with it will be saved.

I'm trying out a single conversation view page with the edit Widget page, and the Widget subDetail editing taking place in new separate top level conversations without any nesting involved. This way, the user can open editors in new windows, or tabs, without any dire consequences. I pass the Ids to the urls in an slink with a propagation of none, and the links are bookmarkeable.

That sounds sensible, and sort of what I was trying to say earlier (well, what I meant to say at least).

Part of the reason for this was the lack of an immediately obvious way to click on a subDetail item to edit it which would then POST my changes to the currently edited widget , start a new conversation for the subDetail editor, and pass over some kind of value from the old conversation indicating which subDetail I am supposed to be editing. The s:link with propagation and a param does all that, except for the POST, hence it is being launched from a view only page.

It feels like the only option left, but at the same time, it feels like I'm only using a fraction of the power of Seam to do master/detail editing which is the bread and butter of software development. (Generate CRUD which is a close second is something Seam excels at). Alternatively, I could be using it exactly in the right way it was designed to be used for this particular scenario. It's hard to tell without any kind of standard best practices of how to use the different elements within seam. The examples highlight particular parts of the framework as opposed to demonstrating how to use them all together.

Yes, this is a pattern that isn't quite down yet! I'll mull it over ;)