On 10/24/07, Mario Ivankovits <[EMAIL PROTECTED]> wrote: > Repost .... (sent directly to Matthias by accident) > > On 10/23/07, Mario Ivankovits <[EMAIL PROTECTED]> wrote: > > > >> ok, so then, if we'd like to go down that road we should follow the scxml > >> way if possible. > >> I am +0 on that as I don't want to be a competitor with spring webflow - > >> at least I'd know what we can do better here. > >> <snip/>
You are testing my tenacity by rehashing a discussion [1] on [EMAIL PROTECTED] from more than a year ago ;-) While I don't intend to replay all that here (but do take a look, if you are interested in how it all came about) -- an important part of the value proposition relates to standardization. There is an upcoming standard at the W3C which relates to state machines, the standard is agnostic to the container or environment, it can be used all the way from the client to the business end (and things in between, such as web flows) -- this uniformity, when realized, has obvious benefits. By using the standard, you neither have to own the vocabulary nor the core state machine implementation, so you've done better already IMO. Then there is the pluggability (of data models, ELs), extensibility (to a true compound namespace vocabulary, based on individual application needs even), UML tooling benefits if you'd prefer drawing state chart diagrams over XML documents etc. Some of this is even documented :-), though potentially there may be the need to correlate docs from the Commons site and the Shale site for the larger picture, perhaps that needs to be improved. -Rahul [1] http://www.nabble.com/-dialog--Using-SCXML-to-describe-Shale-dialogs-tf2161516.html > >> > >> Mario > >> > >> -----Original Message----- > >> From: "Matthias Wessendorf" <[EMAIL PROTECTED]> > >> Date: Tuesday, Okt 23, 2007 10:33 am > >> Subject: Re: [orchestra] ViewController design > >> To: "MyFaces Development" <[email protected]>, [EMAIL PROTECTED] > >> > >> 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 > >>>>> > >> > > > > > > > > > -- > mit freundlichen Grüßen > > Mario Ivankovits > Software Engineering > > OPS EDV VertriebsgesmbH > A-1120 Wien, Michael-Bernhard-Gasse 10 > > Firmenbuch Nr.: FN51233v, Handelsgericht Wien > Tel.: +43-1-8938810; Fax: +43-1-8938810/3700 > http://www.ops.co.at > > E-Mail: [EMAIL PROTECTED] > Skype: mario_ivankovits > >
