You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Hampus Wingren <ha...@bredband.net> on 2011/07/05 15:39:42 UTC
Comparing CODI pages/navigation to Spring WebFlow
Hi again,
We´re currently using Spring WebFlow for JSF navigation but I´m a bit
concerned about the future of WebFlow and wonder how you would compare
it to CODI pages/navigation? I see the CODI stuff to be more of a
natural fit for JSF flow/navigation but as I currently lack a complete
understanding of its functionality I really can´t argue for my case.
Regards,
Hampus
Re: Comparing CODI pages/navigation to Spring WebFlow
Posted by Hampus Wingren <ha...@bredband.net>.
Ok, sounds great. I´ll have to try this out.
Thanks!
Regards,
Hampus
On Tue, 5 Jul 2011 16:45:31 +0200, Gerhard Petracek
<ge...@gmail.com> wrote:
> the conversation concepts are different - you don't have to think about
> special things like sub-flows or nested conversations because you get the
> concept of parallel conversations.
> + conversations are decoupled from the type-safe navigation (you can use
> both but you don't have to).
>
> if you don't group conversation scoped beans, they exist in parallel. you
> can group beans which should exist in the same logical conversation-group.
> closing one group won't affect other groups.
>
> e.g. if you have a booking-wizard and in the middle of it, you have to
> display a registration wizard, you don't have to think about something like
> a sub-flow.
> just open the registration-wizard and at the end of it close the
> conversation of the bean/s behind the registration-wizard. the conversation
> scoped beans of the booking-wizard won't get affected and you can continue
> with the wizard.
>
> regards,
> gerhard
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
>
>
> 2011/7/5 Hampus Wingren <ha...@bredband.net>
>
>> What about subflows? If I´ve got a navigation flow could I then
>> incorporate another flow (packaged in a jar for example) as a reusable
>> navigation flow that could participate in the conversation?
>>
>> regards,
>> Hampus
>>
>> On Tue, 5 Jul 2011 15:59:38 +0200, Gerhard Petracek
>> <ge...@gmail.com> wrote:
>> > hi hampus,
>> >
>> > you can think about it like implicit navigation (introduced in jsf2) but
>> in
>> > a type-safe way based on the view-config concept.
>> > view-configs allow to provide configs e.g. for security, a view
>> > controller,... in a type-safe, extensible and easy way (you can e.g.
>> inherit
>> > configs like it's described in the wiki).
>> > in addition you can (re-)use those view-config classes (which represent
>> the
>> > pages) for type-safe (implicit) navigation.
>> >
>> > most flow-features of swf are only needed because you have to use xml.
>> you
>> > won't find xml in codi - so you don't need those features, if you are
>> using
>> > codi (if you have a more complex flow, you can just write your
>> > conditions/... in java).
>> > however, if you see a missing part which you would need, you are welcome
>> to
>> > describe the use-case.
>> >
>> > regards,
>> > gerhard
>> >
>> > http://www.irian.at
>> >
>> > Your JSF powerhouse -
>> > JSF Consulting, Development and
>> > Courses in English and German
>> >
>> > Professional Support for Apache MyFaces
>> >
>> >
>> >
>> > 2011/7/5 Hampus Wingren <ha...@bredband.net>
>> >
>> >> Hi again,
>> >>
>> >> We´re currently using Spring WebFlow for JSF navigation but I´m a bit
>> >> concerned about the future of WebFlow and wonder how you would compare
>> it to
>> >> CODI pages/navigation? I see the CODI stuff to be more of a natural fit
>> for
>> >> JSF flow/navigation but as I currently lack a complete understanding of
>> its
>> >> functionality I really can´t argue for my case.
>> >>
>> >> Regards,
>> >> Hampus
>> >>
>> >>
>>
>>
Re: Comparing CODI pages/navigation to Spring WebFlow
Posted by Gerhard Petracek <ge...@gmail.com>.
the conversation concepts are different - you don't have to think about
special things like sub-flows or nested conversations because you get the
concept of parallel conversations.
+ conversations are decoupled from the type-safe navigation (you can use
both but you don't have to).
if you don't group conversation scoped beans, they exist in parallel. you
can group beans which should exist in the same logical conversation-group.
closing one group won't affect other groups.
e.g. if you have a booking-wizard and in the middle of it, you have to
display a registration wizard, you don't have to think about something like
a sub-flow.
just open the registration-wizard and at the end of it close the
conversation of the bean/s behind the registration-wizard. the conversation
scoped beans of the booking-wizard won't get affected and you can continue
with the wizard.
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/7/5 Hampus Wingren <ha...@bredband.net>
> What about subflows? If I´ve got a navigation flow could I then
> incorporate another flow (packaged in a jar for example) as a reusable
> navigation flow that could participate in the conversation?
>
> regards,
> Hampus
>
> On Tue, 5 Jul 2011 15:59:38 +0200, Gerhard Petracek
> <ge...@gmail.com> wrote:
> > hi hampus,
> >
> > you can think about it like implicit navigation (introduced in jsf2) but
> in
> > a type-safe way based on the view-config concept.
> > view-configs allow to provide configs e.g. for security, a view
> > controller,... in a type-safe, extensible and easy way (you can e.g.
> inherit
> > configs like it's described in the wiki).
> > in addition you can (re-)use those view-config classes (which represent
> the
> > pages) for type-safe (implicit) navigation.
> >
> > most flow-features of swf are only needed because you have to use xml.
> you
> > won't find xml in codi - so you don't need those features, if you are
> using
> > codi (if you have a more complex flow, you can just write your
> > conditions/... in java).
> > however, if you see a missing part which you would need, you are welcome
> to
> > describe the use-case.
> >
> > regards,
> > gerhard
> >
> > http://www.irian.at
> >
> > Your JSF powerhouse -
> > JSF Consulting, Development and
> > Courses in English and German
> >
> > Professional Support for Apache MyFaces
> >
> >
> >
> > 2011/7/5 Hampus Wingren <ha...@bredband.net>
> >
> >> Hi again,
> >>
> >> We´re currently using Spring WebFlow for JSF navigation but I´m a bit
> >> concerned about the future of WebFlow and wonder how you would compare
> it to
> >> CODI pages/navigation? I see the CODI stuff to be more of a natural fit
> for
> >> JSF flow/navigation but as I currently lack a complete understanding of
> its
> >> functionality I really can´t argue for my case.
> >>
> >> Regards,
> >> Hampus
> >>
> >>
>
>
Re: Comparing CODI pages/navigation to Spring WebFlow
Posted by Hampus Wingren <ha...@bredband.net>.
What about subflows? If I´ve got a navigation flow could I then
incorporate another flow (packaged in a jar for example) as a reusable
navigation flow that could participate in the conversation?
regards,
Hampus
On Tue, 5 Jul 2011 15:59:38 +0200, Gerhard Petracek
<ge...@gmail.com> wrote:
> hi hampus,
>
> you can think about it like implicit navigation (introduced in jsf2) but in
> a type-safe way based on the view-config concept.
> view-configs allow to provide configs e.g. for security, a view
> controller,... in a type-safe, extensible and easy way (you can e.g. inherit
> configs like it's described in the wiki).
> in addition you can (re-)use those view-config classes (which represent the
> pages) for type-safe (implicit) navigation.
>
> most flow-features of swf are only needed because you have to use xml. you
> won't find xml in codi - so you don't need those features, if you are using
> codi (if you have a more complex flow, you can just write your
> conditions/... in java).
> however, if you see a missing part which you would need, you are welcome to
> describe the use-case.
>
> regards,
> gerhard
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
>
>
> 2011/7/5 Hampus Wingren <ha...@bredband.net>
>
>> Hi again,
>>
>> We´re currently using Spring WebFlow for JSF navigation but I´m a bit
>> concerned about the future of WebFlow and wonder how you would compare it to
>> CODI pages/navigation? I see the CODI stuff to be more of a natural fit for
>> JSF flow/navigation but as I currently lack a complete understanding of its
>> functionality I really can´t argue for my case.
>>
>> Regards,
>> Hampus
>>
>>
Re: Comparing CODI pages/navigation to Spring WebFlow
Posted by Gerhard Petracek <ge...@gmail.com>.
hi hampus,
you can think about it like implicit navigation (introduced in jsf2) but in
a type-safe way based on the view-config concept.
view-configs allow to provide configs e.g. for security, a view
controller,... in a type-safe, extensible and easy way (you can e.g. inherit
configs like it's described in the wiki).
in addition you can (re-)use those view-config classes (which represent the
pages) for type-safe (implicit) navigation.
most flow-features of swf are only needed because you have to use xml. you
won't find xml in codi - so you don't need those features, if you are using
codi (if you have a more complex flow, you can just write your
conditions/... in java).
however, if you see a missing part which you would need, you are welcome to
describe the use-case.
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/7/5 Hampus Wingren <ha...@bredband.net>
> Hi again,
>
> We´re currently using Spring WebFlow for JSF navigation but I´m a bit
> concerned about the future of WebFlow and wonder how you would compare it to
> CODI pages/navigation? I see the CODI stuff to be more of a natural fit for
> JSF flow/navigation but as I currently lack a complete understanding of its
> functionality I really can´t argue for my case.
>
> Regards,
> Hampus
>
>