myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mario Ivankovits <ma...@ops.co.at>
Subject Re: [orchestra] ViewController design
Date Wed, 24 Oct 2007 07:29:44 GMT
Repost .... (sent directly to Matthias by accident)
> On 10/23/07, Mario Ivankovits <mario@ops.co.at> 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" <matzew@apache.org>
>> Date: Tuesday, Okt 23, 2007 10:33 am
>> Subject: Re: [orchestra] ViewController design
>> To: "MyFaces Development" <dev@myfaces.apache.org>, mario@ops.co.at
>>
>> 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
>>>>>           
>>     
>
>
>   


-- 
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: mario@ops.co.at
Skype: mario_ivankovits


Mime
View raw message