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. >> >> >> 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
