anonymous wrote :
| Specifically: Why do you need join="true" if you just have ended the
previous conversation with propagation="end"?
|
He talked about starting a new one with join=true. The join=true bit ensures
that you don't start a new one each time the page is rendered.
maku01 :
Regarding the conversation tags in pages.xml, I believe (and I could be wrong
on this) that you need to rephrase the constant to something like :
| <conversation name="PartnerMaintConv"
| parameter-name="cid"
| parameter-value="#{PartnerMaintConv}"/>
|
The constant should force a reuse of the conversation that you are looking for,
although there are some problems with this mechanism which are currently being
fixed.
http://jira.jboss.org/jira/browse/JBSEAM-1423
Proper use of conversations has been a thorn in my side for a while. If you
notice, most Seam example apps have very little editing in them, and there is
no master detail editing involved. The issue tracker was the only one with any
kind of editable features, including master/detail and nested editing, but it
was pulled in 2.0, possibly because it wasn't working properly.
There is very little in the way of best practices for Seam, and everyone seems
to be off doing their own thing and muddling together a solution.
Pete, you've seen my sample bookstore app from my Jira issue (#1423), I have a
couple of different ones (including something similar to the issue tracker)
that I have been using to test this stuff out. I'm more than happy to donate
something. The only caveat is that it uses the same kind of mechanisms as the
bookstore app (RESTFul URLS, no @Begin annotations, and parameter passing)
since it seems that this is the best way to develop a seam app that is well
decoupled and a little more lightweight (i.e. not invoking new beans into a
conversation that doesn't need them or is about to end). If you guys are
interested, just let me know what I need to do with it to get it up to scratch.
I think the two things seam needs right now is some indication of best
practices, and some more diverse examples, and there is some overlap of those
two issues.
The documentation and examples are great for describing what you can do, but
not always what you should do. There needs to be a little bit more diversity in
the examples that highlight how to solve the problems people face on a daily
basis, or at least indicate which problems can't be solved so we know we need
to design around those issues (i.e. master/detail editing with nested
conversations).
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4081397#4081397
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4081397
_______________________________________________
jboss-user mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/jboss-user
