myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig McClanahan" <craig...@apache.org>
Subject Re: action link
Date Tue, 07 Mar 2006 18:35:17 GMT
On 3/7/06, Mike Kienenberger <mkienenb@gmail.com> wrote:
>
> Hey Craig,
>
> Are you willing to update the wiki to also include your ideas on using
> Shale remoting for this?


Actually, the first place this needs to go is on the Shale web site page
describing remoting[1], which is ... umm ... slightly content-light at the
moment :-).  Then we can point at it from the MyFaces Wiki.

Craig

[1] http://struts.apache.org/struts-shale/features-remoting.html

Currently the wiki page only contains this Shale info, and nothing
> about remoting:
>
> http://wiki.apache.org/myfaces/InvokingJsfPagesWithStandardUrls
> =================
> Use Struts Shale
>
> Apparently the Struts Shale library for JSF has a ViewController class
> that provides useful functionality for accessing these params.
> =================
>
> On 3/6/06, Craig McClanahan <craigmcc@apache.org> wrote:
> >
> >
> >
> > On 3/6/06, David Schlotfeldt <tcphp@plauditdesign.com> wrote:
> > > I need a way to have a URL that will cause a JSF action to take place.
> > > Anyone know of a way? (For an example, lets say I need to put the link
> > > in an email.)
> > >
> > > All I find are "hackerish" javascript solutions to this issue.
> > >
> > > Would it be possible to create a version of the commandLink that
> didn't
> > > need a form around it and didn't use javascript? Obviously it couldn't
> > > include any information from form fields but that is okay with me.
> >
> >
> >  Isn't that basically what <h:outputLink> (instead of <h:commandLink>)
> does?
> >  The only question then becomes how to figure out the appropriate URL
> (to
> > which you can attach query parameters as necessary).
> >
> >  This is the same kind of problem that AJAX components have when they
> want
> > to trigger server side handlers asynchronously.  See below for one
> approach
> > to this.
> >
> >
> > > Or would it be possible to create a servelet filter that converts a
> > > normal request to a request JSF wants?
> > >       Eg. We have a form with a field called 'name' and a button
> called
> > > 'sayHi'. With the filter I could send a person to a url like
> > >
> > http://test.com/page-form-is-on.html?link=sayHi&name=David
> > >     The filter would take the request and convert convert the params
> > > into what JSF wants. I don't know how to do this... except maybe make
> a
> > > fake request in the fitler to the JSF for the form to get jsf_state_64
> > > and jsf_tree_64 values and then send the request on with the request
> > > parameters rewritten.
> > >
> > > Suggestions? Anyone know of a good solution?   (...other than mine
> that
> > > would take me 3 weeks, 4 days, and 7382 Red Bulls...)
> > >
> > >
> > >
> >
> >  Shale[1] includes a Remoting[2] feature that supports a version of this
> > sort of functionality -- the significant restriction (at least for the
> > current version) is that the server side code will not have access to
> the
> > saved JSP component state, and therefore no access to the component
> tree.
> > But, if you are using "*.faces" mappings for your JSF requests, and
> default
> > mappings for Shale Remoting, a URL like this:
> >
> >      http://localhost:8080/myapp/dynamic/foo/bar.faces
> >
> >  will tell Shale Remoting to create a method binding expression "#{
> foo.bar}"
> > and execute it.  This, in turn, causes the creation of a managed bean
> named
> > "foo" (if you have defined it that way; otherwise the bean must already
> > exist in some scope), and then a public method named bar() that takes no
> > parameters and returns void is called.  This method is responsible for
> > creating the entire HTTP response for this request, which it can do in a
> > number of ways:
> >
> >  * Get a ResponseWriter (there's a convenient helper factory
> >    included in Shale Remoting) and write XML/XHTML output
> >    the same way that a component renderer would do it.
> >
> >  * Forward to a JSP page that creates the response
> >
> >  * Forward to a URL mapped to FacesServlet, and have
> >    a JSF view create the response.
> >
> >  To handle request parameters inside the handler, you can call
> > FacesContext.getExternalContext().getRequestParameterMap() and pull them
> out
> > yourself.  Or, if you are using managed beans, you can let JSF do
> dependency
> > injection for you.  Consider a managed bean named "handler" defined like
> > this:
> >
> >      <managed-bean>
> >          <managed-bean-name>handler</managed-bean-name>
> >          <managed-bean-class>...your bean class...</managed-bean-class>
> >          <managed-bean-scope>request</managed-bean-scope>
> >          <managed-property>
> >              <property-name>name</property-name>
> >              <value>#{param.name}</value>
> >          </managed-property>
> >      </managed-bean>
> >
> >  and a managed bean like this:
> >
> >      public class MyBean {
> >          ...
> >          public void setName(String name) { ... }
> >          ...
> >          public void sayHi() { ... }
> >          ...
> >      }
> >
> >  With this setup, a call to a URL like
> >
> >
> > http://localhost:8080/myapp/dynamic/handler/sayHi?name=David
> >
> >  will cause Shale Remoting to create the bean in request scope, pass
> "David"
> > to the setName() method, and then call your sayHi() function.  (In any
> given
> > app, you can have as many different managed beans, and as many
> activatable
> > methods on those beans, as you like.)
> >
> >  The documentation is a little light at the moment ... but start with
> the
> > Package Description for package "org.apache.shale.remoting" on the
> second
> > link below.  Also, you can take a look at the "Use Cases" example
> > application for a worked-out example ... on the main menu, take a look
> at
> > the "new-style remoting" links, and you'll see how they execute method
> > binding expressions "#{remoting$business.listCategories}"
> > and "#{remoting$business.listLocales}" respectively.  These
> > kinds of method calls are quite useful for asynchronous callbacks from
> AJAX
> > client widgets, but (as you can see here) they work just fine as a
> standard
> > request link too.
> >
> >  Craig
> >
> >  [1] http://struts.apache.org/struts-shale
> >  [2]
> > http://struts.apache.org/struts-shale/shale-remoting/apidocs/index.html
> >
> >
>

Mime
View raw message