Mailing-List: contact dev-help@myfaces.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "MyFaces Development" <dev@myfaces.apache.org>
Received-SPF: softfail (athena.apache.org: transitioning domain of
 mario@ops.co.at does not designate 194.48.124.114 as permitted sender)
Date: Tue, 23 Oct 2007 10:29:00 +0200
From: Mario Ivankovits <mario@ops.co.at>
Subject: Re: [orchestra] ViewController design
To: dev@myfaces.apache.org
Reply-to: mario@ops.co.at
Message-id: <3275980180.618496@smtp.a1.net>
Content-transfer-encoding: 7BIT

hi,

I am not aware that the shale vc has something like a configuration. Doesn't it just use the viewId mapping?

Well, I can live with an extra configuration, but then, we should have a look how the shale dialog scxml fits in here - just that any eventual adaption of shale dialog in the future fits in easier then - and maybe not introduce yet another config then.
The pro might be that one can have different VC depending on the dialog state per page then - if this is of any use at all ;-)

Mario

-----Original Message-----
From: "Matthias Wessendorf" <matzew@apache.org>
Date: Tuesday, Okt 23, 2007 9:38 am
Subject: Re: [orchestra] ViewController design
To: Reply-    "MyFaces Development" <dev@myfaces.apache.org>To: "MyFaces Development" <dev@myfaces.apache.org>

> 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