myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthias Wessendorf" <mat...@apache.org>
Subject Re: [orchestra] ViewController design
Date Tue, 23 Oct 2007 08:33:12 GMT
I think Simon was talking about the dialog config, where a "flow" is configured.

The entry of the flow is responsible to start conversation, etc

On 10/23/07, Mario Ivankovits <mario@ops.co.at> wrote:
> 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
>
>


-- 
Matthias Wessendorf

further stuff:
blog: http://matthiaswessendorf.wordpress.com/
mail: matzew-at-apache-dot-org

Mime
View raw message