---- Matthias Wessendorf <[EMAIL PROTECTED]> schrieb:
>> Why would you combine all in one ViewController and then split the
>> method execution per page?
>
> to have one behind my three pages, to edit a complex object,
> but I want to "load" something (like the entity) only on the first page
>> @PreRenderView (executeOn={"/edit1.xhtml"})
>> @PreRenderView (executeOn={"/edit2.xhtml"})
>> @PreRenderView ()
So in this case, what is really wanted is an "init workflow" callback?
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.
As I have mentioned before, I'm still not entirely convinced the ViewController
concept is right. It couples the backing bean to the page too tightly; normally
in JSF dependencies are the other way around. The information about what views
belong together in a workflow is also obscured.
I've been vaguely thinking about alternatives. What follows below is only
half-baked ideas; I'm hoping to put some more thought into this soon.
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.
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
