Hey Craig, Are you willing to update the wiki to also include your ideas on using Shale remoting for this?
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 <[EMAIL PROTECTED]> wrote: > > > > On 3/6/06, David Schlotfeldt <[EMAIL PROTECTED]> 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 > >
