Yes, after I made the post, I realized that a link to shale's docs would probably be more appropriate. I added the link and the two-cent description to our page for your motivation :)
============= Also see Shale remoting for executing method binding expressions specified by URLs. http://struts.apache.org/struts-shale/features-remoting.html ============= On 3/7/06, Craig McClanahan <[EMAIL PROTECTED]> wrote: > On 3/7/06, Mike Kienenberger <[EMAIL PROTECTED]> 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 <[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 > > > > > > > > > >
