You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by De...@ak.blm.gov on 2005/11/09 00:53:45 UTC
declarative action chaining
Are there any chances for the following in the 1.2 spec? I would like to
increase the learning curve w/ declarative action chaining ;-). For
example, (notice the to-action-id element).
<navigation-rule>
<from-view-id>/admin/removeUser.jsp</from-view-id>
<navigation-case>
<from-action>#{UserBean.deleteUser}</from-action>
<from-outcome>SUCCESS</from-outcome>
<to-action-id>#{UserLister.load}</to-action-id>
</navigation-case>
<navigation-case>
<from-action>#{UserLister.load}</from-action>
<from-outcome>SUCCESS</from-outcome>
<to-view-id>/admin/displayAllUsers.jsp</to-view-id>
</navigation-case>
</navigation-rule>
This means you could implement a deleteUser action method that does just
that, and there is no need to implement a method that has to delete the
user AND reload a list of users. Developers could spend less time writing
"compound actions" and our conf files could get even more bloated ;-)
Dennis Byrne
Re: declarative action chaining
Posted by Mike Kienenberger <mk...@gmail.com>.
Dennis,
You'll have to propose this to the JSF EG to get it into the spec.
You know the drill.
>From http://wiki.apache.org/myfaces/FAQ:
=======
I don't like something about the JSF specification. How can I change it?
Send email to jsr-252-comments@jcp.org to send your suggestion for the
next version of JSF.
=======
One thing you could do instead is to create a custom Navigation
Handler that also handled this situation. Might be a good tomahawk
extension.
On 11/8/05, Dennis_Byrne@ak.blm.gov <De...@ak.blm.gov> wrote:
>
> Are there any chances for the following in the 1.2 spec? I would like to
> increase the learning curve w/ declarative action chaining ;-). For
> example, (notice the to-action-id element).
>
> <navigation-rule>
> <from-view-id>/admin/removeUser.jsp</from-view-id>
> <navigation-case>
> <from-action>#{UserBean.deleteUser}</from-action>
> <from-outcome>SUCCESS</from-outcome>
> <to-action-id>#{UserLister.load}</to-action-id>
> </navigation-case>
> <navigation-case>
> <from-action>#{UserLister.load}</from-action>
> <from-outcome>SUCCESS</from-outcome>
>
> <to-view-id>/admin/displayAllUsers.jsp</to-view-id>
> </navigation-case>
> </navigation-rule>
>
> This means you could implement a deleteUser action method that does just
> that, and there is no need to implement a method that has to delete the user
> AND reload a list of users. Developers could spend less time writing
> "compound actions" and our conf files could get even more bloated ;-)
>
> Dennis Byrne
>
>
Re: declarative action chaining
Posted by Andrew robinson <an...@gmail.com>.
Sorry to piggy back on this subject, but since the topic has shifted to shale...
I am looking at using JBoss-Seam with Facelets as someone recommended
that it is built more for JSF/Facelets than Shale/Clay. The topic
didn't receive more discussion than that. I really don't know that
much about Shale & Clay.
Is there someone that has looking into both Seam and Shale? Are they
competitors or would they compliment each other? Also curious if using
Shale in JSF is a hack like trying to use Tiles in JSF (please don't
say that it isn't as working with Facelets is a drastic improvement -
like no ugly verbatim tags, and the ability to find components in
different pages from code which you can't in the JsfTiles view
handler).
Thanks in advance,
Andrew
On 11/10/05, Craig McClanahan <cr...@apache.org> wrote:
>
>
> On 11/9/05, Sean Schofield <se...@gmail.com> wrote:
> > Yes Shale dialogs are very nice indeed :-)
>
> I should mention an alternative approach that Shale enables as well ...
> putting the setup logic for a new view in the same page bean class as will
> process submits from this form. The prerender() method provided by
> ViewController is perfect for this task.
>
> If you like all the code related to the same page available in the same
> class, this approach will appeal to you. If you like fine grained actions
> that can be composed together, the Dialogs approach will be more attractive.
> Shale doesn't care which method you choose ... it helps you with either.
>
> Craig
>
>
Re: declarative action chaining
Posted by Craig McClanahan <cr...@apache.org>.
On 11/9/05, Sean Schofield <se...@gmail.com> wrote:
>
> Yes Shale dialogs are very nice indeed :-)
I should mention an alternative approach that Shale enables as well ...
putting the setup logic for a new view in the same page bean class as will
process submits from this form. The prerender() method provided by
ViewController is perfect for this task.
If you like all the code related to the same page available in the same
class, this approach will appeal to you. If you like fine grained actions
that can be composed together, the Dialogs approach will be more attractive.
Shale doesn't care which method you choose ... it helps you with either.
Craig
Re: declarative action chaining
Posted by Sean Schofield <se...@gmail.com>.
Yes Shale dialogs are very nice indeed :-)
On 11/9/05, Craig McClanahan <cr...@apache.org> wrote:
> On 11/8/05, Dennis_Byrne@ak.blm.gov <De...@ak.blm.gov> wrote:
>
> >
> > Are there any chances for the following in the 1.2 spec? I would like to
> increase the learning curve w/ declarative action chaining ;-). For
> example, (notice the to-action-id element).
> >
> > <navigation-rule>
> >
> <from-view-id>/admin/removeUser.jsp</from-view-id>
> > <navigation-case>
> > <from-action>#{UserBean.deleteUser}</from-action>
> > <from-outcome>SUCCESS</from-outcome>
> > <to-action-id>#{UserLister.load}</to-action-id>
> > </navigation-case>
> > <navigation-case>
> > <from-action>#{UserLister.load}</from-action>
> > <from-outcome>SUCCESS</from-outcome>
> >
> <to-view-id>/admin/displayAllUsers.jsp</to-view-id>
> > </navigation-case>
> > </navigation-rule>
> >
> > This means you could implement a deleteUser action method that does just
> that, and there is no need to implement a method that has to delete the user
> AND reload a list of users. Developers could spend less time writing
> "compound actions" and our conf files could get even more bloated ;-)
>
> Dennis,
>
> In the mean time, you might want to take a look at how Dialogs are
> implemented in Shale. Instead of trying to corrupt :-) the standard
> navigation rules, it allows you to define transitions between action states
> and view states in a separate configuration file ... and you can explicitly
> chain action states together if you like.
>
> http://struts.apache.org/shale/
>
> Craig McClanahan
>
>
> > Dennis Byrne
> >
> >
>
>
Re: declarative action chaining
Posted by Craig McClanahan <cr...@apache.org>.
On 11/8/05, Dennis_Byrne@ak.blm.gov <De...@ak.blm.gov> wrote:
>
>
> Are there any chances for the following in the 1.2 spec? I would like to
> increase the learning curve w/ declarative action chaining ;-). For example,
> (notice the to-action-id element).
>
> <navigation-rule>
> <from-view-id>/admin/removeUser.jsp</from-view-id>
> <navigation-case>
> <from-action>#{UserBean.deleteUser}</from-action>
> <from-outcome>SUCCESS</from-outcome>
> <to-action-id>#{UserLister.load}</to-action-id>
> </navigation-case>
> <navigation-case>
> <from-action>#{UserLister.load}</from-action>
> <from-outcome>SUCCESS</from-outcome>
> <to-view-id>/admin/displayAllUsers.jsp</to-view-id>
> </navigation-case>
> </navigation-rule>
>
> This means you could implement a deleteUser action method that does just
> that, and there is no need to implement a method that has to delete the user
> AND reload a list of users. Developers could spend less time writing
> "compound actions" and our conf files could get even more bloated ;-)
Dennis,
In the mean time, you might want to take a look at how Dialogs are
implemented in Shale. Instead of trying to corrupt :-) the standard
navigation rules, it allows you to define transitions between action states
and view states in a separate configuration file ... and you can explicitly
chain action states together if you like.
http://struts.apache.org/shale/
Craig McClanahan
Dennis Byrne
>
>