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.
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.
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.
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?
Say, a way to configure begins to use flushmode=MANUAL by default. Maybe this could be configured in components.xml.
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...