On 3/7/06, David Schlotfeldt <[EMAIL PROTECTED]> wrote:
If I'm understanding you correctly, doesn't this mean you will never have any JSF component state to restore, so that every request will seem like a new request? And therefore bypass the normal request processing lifecycle? (Normally, in Restore View, if there is no state to restore, JSF will create a new tree and then proceed directly to Render Response phase.)
I can see how it *might* work if you are using server side state saving, and the view id that the external site sends back happens to be one for which there was server side state, but you are skating on the thin ice of implementation dependencies (rather than features that are defined by the spec to be portable) here.
Craig
I have written a new way to solve this issue with the idea I described
below. After receiving responses to my original post I was going to use
NonFacesRequestServlet but realized that it wouldn't do any validation.
(At least I am PERTTY sure it doesn't. Someone correct me if I am wrong.)
What I have done is created a servlet filter that can be used to make it
seem as if a person has already loaded the page and has filled it out
and clicked a link or button. -- simply by requesting a URL. What I did
is a servlet filter that makes a request to the JSF page, searches the
response for form fields, and then merges those fields default values
with the request parameters from the real request. It then calls
doChain(...) with a wrapped http request that has all the values from
the form and the real request. This makes it possible to seem as if
someone went to the page and clicked a button or link. (In fact it does
happen, but the filter does it.)
For example the following url can be used on an order form I am creating
to cause the next button to be pushed.
register.html?doReq=true&formId=placeOrder&placeOrder:next=true
doReq=true triggers the fitler. FormId is the id of the form.
PlaceOrder:next is a button I am causing to be pushed.
If I'm understanding you correctly, doesn't this mean you will never have any JSF component state to restore, so that every request will seem like a new request? And therefore bypass the normal request processing lifecycle? (Normally, in Restore View, if there is no state to restore, JSF will create a new tree and then proceed directly to Render Response phase.)
I can see how it *might* work if you are using server side state saving, and the view id that the external site sends back happens to be one for which there was server side state, but you are skating on the thin ice of implementation dependencies (rather than features that are defined by the spec to be portable) here.
Craig
I did all of this because I have a multi step form with a step in the
middle that is on another site. Using this filter I can make the
external step send the user back to the JSF form and cause an action to
take place when it comes back.
What are peoples opinion on this approach?
(I don't know how the API having to do with JSF's life cycle works so
maybe its possible to do this type of thing from a servlet so a fake
request doesn't have to be made.)
Thanks,
David
David Schlotfeldt 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.
>
> 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...)
>
