JBossDeveloper

"trouby" wrote:
Well, sorry for being so annoying but I still don't get the point, If I have buttons that should start a conversation, propagation='none' is not an option

"pete.muir@jboss.org" wrote:
Post your use case for this.

• 
  
• submitting a search query using the button.
  
• navigation forwards though the results using the next link.
  
• navigation backwards though the results using the previous link.
  
  
  I'd also like the submission of a new query to start a new conversation. Ideally, clicking the button should end the existing conversation and begin a new one. So far I can't see an easy way of doing this.
  
  With a simple @Begin attribute on the search method, performing a second search throws an exception - which is expected, we are already in a conversation.
  
  Using @Begin(join=true) does not meet the requirement of starting a new conversation per search.
  
  I could add a clear button that calls an @End attributed method but this is does not really meet your average user's expectations of a search tool.
  
  
  
  
  

"trouby" wrote:
My case? I think it's any case with buttons that always exist on the template,

Lets make an example:
I have a top menu(that is always with visible) with few options,
[my items: a, b, c, d]

Pressing on one item should start a conversation, as this item is heavily being managed later on.

I have added a 'done' button with propagation='none' but no one is using it : )

"schlafsack" wrote:

"pete.muir@jboss.org" wrote:

• 
  
• submitting a search query using the button.
  
• navigation forwards though the results using the next link.
  
• navigation backwards though the results using the previous link.
  
  
  I'd also like the submission of a new query to start a new conversation. Ideally, clicking the button should end the existing conversation and begin a new one. So far I can't see an easy way of doing this.

Normally you wouldn't make a search screen conversational. Why do you want to make it conversational?

If you really do want to make it conversational, then you can use <end-conversation before-redirect="true" /> in pages.xml, and start a new conversation after the redirect. But I don't think this is the best way to write a search screen.

"pete.muir@jboss.org" wrote:

Normally you wouldn't make a search screen conversational. Why do you want to make it conversational?

"pete.muir@jboss.org" wrote:

If you really do want to make it conversational, then you can use <end-conversation before-redirect="true" /> in pages.xml

"pete.muir@jboss.org" wrote:
Normally you wouldn't make a search screen conversational. Why do you want to make it conversational?

Have you taken a look at the way seam-gen does it? It produces a pageable, bookmarkable search screen that saves the search criteria without using a conversation.

"pete.muir@jboss.org" wrote:
Have you taken a look at the way seam-gen does it? It produces a pageable, bookmarkable search screen that saves the search criteria without using a conversation.

I think part of the problem here is that outside of a few, small example applications provided by the gracious Seam team, there are no true examples of a large, enterprise-level application properly using Seam conversations.

Seam is so closely coupled with conversations that there is no true way of escaping them. Yet the amount of confusion over how to manage them in an Web environment where the user is truly allowed to go anywhere, do anything, start any process and end it at any time, should point out to the Seam team that *are* issues with conversations in general.

They're a great idea - but I know we're struggling with their usage. Results are unpredictable at best. The authors of Seam documentation attempt to show its great value but in practice it is hard to come by. Try using breadcrumbs based off of Seam conversations - I'll tell you upfront that it simply will cause more headaches than it is worth in a system with many pages and processes.

I think there needs to be a definitive, large-scale example on how to manage conversations in an enterprise application. There is simply too much confusion for this to be ignored.

My two cents.

Chris,

Interesting post. Thanks for the feedback. We do have one large scale app written in Seam in the examples dir - the wiki example which is the basis of the new Seam community site (which is up and running). The problem with large example apps is that they are hard to understand which makes them bad examples!

Before moving to JBoss I did work on a fairly large app with Seam using conversations, and had no real problems with conversation management. I've also seen apps use conversations well in support cases and when consulting.

My tip is to avoid starting conversations from navigation links (those links that take you to other areas of the app), always make navigation disable conversation propagation, and just use conversations *within* each area of the app.

Pete,

Thanks for not taking my post harshly as it wasn't meant to be as such. I, for one, am extremely appreciative of what all of you are doing to evolve Seam and to engage the end-user as much as possible, through these forums and elsewhere.

We *had* been setting propagation="none" on most navigation links and just recently started to think that we actually *shouldn't* be doing this. So hearing from you that this is indeed something that should be set (to "none") helps greatly.

It is tips like these that could be really helpful to people struggling to grasp ho how to use conversations. Looks like the new Wiki will be a good source for this kind of information.

I'll take a look at the example itself as well.

Thanks!

"pete.muir@jboss.org" wrote:
My tip is to avoid starting conversations from navigation links (those links that take you to other areas of the app), always make navigation disable conversation propagation, and just use conversations *within* each area of the app.

The problem I find when setting propagation="none" on my navigation links is that the conversation is not ended and is maintained on memory untill it expires.

Wouldn't it be better to set propagation="end"?