> So in this case, what is really wanted is an "init workflow" callback?
yes; > > That sounds reasonable; the generic case of "call this method when in this > view, call this other method when in a different view" sounds odder. > yeah, a bit :-) ... > > I feel that it would be better to have information about what conversation a > view is in (rather than just what backing beans receive its lifecycle events) > [1]. Alternately, we define what views are in a conversation; same info but > somewhat different emphasis. I think, that a) or c) are nice, than b) I don't like to add components, just because I use a "conversation framework". The component should make sense inside of the view and not somehow "mark" some pages to be part of a flow. I understand that some don't like to write XML (a); so (c) might be the way to go, but there is the a dependency. Looks like b) and c) have somehow some dependencies, that aren't always wanted. Perhaps a) ? -Matthias > > Once we know what conversation a view is in, we check if the conversation > already exists. If no, and this is not the first view in the conversation, > then redirect to the first page[2], load all beans that are declared as being > in the scope of this conversation and have lifecycle annotations [3], and > invoke any init-workflow methods on them. > > This is not really very different in practice from what is currently done. It > just makes workflows "declarative" (configured) rather than "procedural" > (defined by bean behaviours). > > [1] Determining the conversation for a view could be done via (a) an external > config-file, (b) via a component in the view, or (c) via annotations on beans. > > (a) is effectively what Spring WebFlow and Shale ViewController does, AIUI. > > (b) seems nice to me too. As Mario has mentioned earlier, there are problems > with JSF1.1+jsp when using a component in the page to declare the > conversation for a view. On the first render of the page, the component > doesn't exist until after earlier components have been rendered. Personally I > don't think this is a major issue; that combination is being phased out, and > anyway it isn't unreasonable to just tell people to put the tag as the first > child of their f:view. Using components like this means we cannot "print out > a list" of all the workflows defined in the system, which is a nice feature > of something like WebFlow. However it does mean far less configuration; > adding a new view to the workflow means adding the tag to the view - and no > more. > > (c) is the current approach. I don't like the dependencies, but I think we > can still deduce what views belong in the same workflow from the > declarations, ie scan all the classes for @ViewController annotations, and > build a list of workflows as follows; > for each conversation-scope name that has been declared > create a workflow > for each bean in that scope > for each view that is declared via @ViewController > add that view to the workflow if it isn't already there > > [2] Not sure how to best figure out what the "entry page" for a workflow is, > except via a Spring WebFlow type system > where everything is externally configured. > > [3] Instantiating all the beans for the conversation is optional, but sounds > nice. If any misconfiguration exists, then an error will occur immediately > rather than just when some page in the conversation is entered. > Interestingly, beans can then use their constructor (or Spring init-method) > to do "init workflow" type stuff, without needing an explicit Orchestra > annotation. > > Thoughts? > > Regards, > > Simon > > -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org
