There has been a discussion on configuration in the view (with components) some time ago, and some of the JSF experts on this list argued that one shouldn't use non-visible components in the view (e.g. Adam, Craig, others).
I actually like the option with annotations best - until we need a configuration file for the dialog handling anyways, and this configuration file will best be the one of Shale ;) regards, Martin On 10/23/07, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: > 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 > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
