anonymous wrote : 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.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4057003#4057003
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4057003
_______________________________________________
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
