Another conversation question: how to correctly begin one??

[mschmidke]

There are a lot of possibilities for starting a conversation, but I still am not sure which is the best for the most cases. What do you think?

1. Beginning a conversation by action method

public class MainMenuBean {

 @Begin(flushMode=FlushModeType.MANUAL)
 public String doUsecase1() {
 return "/pages/usecase1";
 }

 @Begin(flushMode=FlushModeType.MANUAL)
 public String doUsecase2() {
 return "/pages/usecase2";
 }
}

- violates DRY (specify flushmode everytime, for example)
- scatters business logic (why should my menu bean be aware of the flushmode my component intends to use?)

2. Beginning a conversation by <begin-conversation flush-mode="MANUAL"> in pages.xml.
- violates DRY
- scatters business logic (program logic details in a xml file? why??).
- impossible to reload the page ("begin called from long running ...")

3. Create a page action method annotated with @Begin(flushMode=MANUAL)
+ Parameters concerning program logic at the right place (in the class which makes use of their functionality)
+ DRY-aware (put page action method in a common base class)
- impossible to reload the page

4. Use #{conversation.begin}
- same as 2

5. Annotate the @Create method with @Begin
+ Parameters at the right place
+ DRY
+ possible to reload the page

Until yesterday, I feeled that (5) was the best possibility, but as you have probably read, I found out that this does not work with page parameters. In fact, (1) seems to be the only variant which works in that situation.

What do you use?


Marcus.

[jacob.orshalick]

I use pages.xml which, IMO, puts the logic where it belongs as generally conversations are scoped to a section of the application. As page flow is defined in the pages.xml file, it makes sense to demarcate the boundaries of the conversation there.

"MSchmidke" wrote:
2. Beginning a conversation by <begin-conversation flush-mode="MANUAL"> in pages.xml.
- violates DRY
- scatters business logic (program logic details in a xml file? why??).
- impossible to reload the page ("begin called from long running ...")

I'm not sure why you feel this violates DRY or scatters business logic. You define your conversation logic in one location in the pages.xml which is where the pageflow is defined (so it *feels* like the right place) and it should not be repeated anywhere else. You then use s:links to specify propagation="none" when moving between conversations (or simply use h:outputLink based on your needs).

Generally if you are having issues with reloading the page, you need to specify propagation=join and/or rules around when the conversation should be started in the pages.xml. This is quite easy with the support that pages.xml provides.

Hope that helps.

[mschmidke]

Yes ... perhaps this is the problem. Until today I did not understand this page flow thing.

I've been a WebObjects developer for years, had the luck to skip Struts and "Seam-less" JSF.

In WebObjects, every html page is represented by a Java class, and directing to a particular page from an action method is done by instantiating and returning the corresponding Java object. No resource file names, no outcomes anywhere in the code (and especially no xml files). I got very accustomed to have _everything_ in Java code.

I was very glad when I found Seam which similarly allowed me to do everything in code (using absolute paths instead of outcomes as return values). I still do not understand why I should be snipping this part out of my code and putting it in a XML file, and so my pages.xml is really teeny-weeny.

Perhaps I should do some research and practice on this navigation rule thing (but this is a little off topic here), but for return to the topic: I feel that the way my persistence context should be handled (flushed manually or not) drastically affects the code I write, and so I think the best place is just exactly in company with that code.

And since I write many beans which rely on flushmode=MANUAL, I like to have a common base class which sets this for all of them. This is what I meant with DRY.

But I see that all of you does something else than me, and so I am thinking.

Marcus,

[jacob.orshalick]

"MSchmidke" wrote:
And since I write many beans which rely on flushmode=MANUAL, I like to have a common base class which sets this for all of them.

Maybe instead of a common base class, a way to globally configure the flushmode setting. Say, a way to configure begins to use flushmode=MANUAL by default. Maybe this could be configured in components.xml.

This would save a lot of what is generally boilerplate configuration since this is common usage. Thoughts?

[matt.drees]

"jacob.orshalick" wrote:
Say, a way to configure begins to use flushmode=MANUAL by default. Maybe this could be configured in components.xml.

+1

[nickarls]

Sounds like a good idea. Even if it would be the silent default, the natural think to do would be to start doing explicit flushes when you don't see anything sticking in the DB...

[jacob.orshalick]

JIRA issue raised:

http://jira.jboss.com/jira/browse/JBSEAM-2512