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 <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> > Date: Tuesday, Okt 23, 2007 9:38 am > Subject: Re: [orchestra] ViewController design > To: Reply- "MyFaces Development" <[email protected]>To: "MyFaces > Development" <[email protected]> > > > 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
