On 9/28/06, Ingo Düppe <[EMAIL PROTECTED]> wrote:
Yes that would work too with the ViewController, but then I prefer my
solution.
Because you can write little action classes like this one.
@bean(name="userActivate",scope=Scope.REQUEST)
class UserActivateAction {
// fill properties from param
public String activate() {
//do something
return "outcome"
}
}
Why I would like to combine it with shale-remoting is the dynamic
interpretation of the request path like
/dynamic/userActivate/activate.faces. So I wouldn't need to define the
action path explicitly.
To integrate such a solution in shale we need to define a new uri prefix
like "/dynamic" and a new Processor.
It would certainly be technically feasible to create something like this,
but I'm not convinced it will actually make your life easier :-).
It sounds like you are proposing a scenario where you want to dynamically
decide whether or not to forward to a particular page (based on expiration
of "link validity" or on some other criteria). Your solution seems to
require:
* One Java class for the decision making logic
* One Java class (backing bean) and a JSP (or whatever) for the actual
content
rendering, assuming that it has not expired yet.
Whereas the solution I proposed embeds the "decision making logic" part
*inside* the backing bean that you need to create anyway. Why make yourself
write one more class?
SIDE NOTE -- I am presuming that you would also want to map all requests for
the same basic data to the same view identifier URL, instead of making up a
unique one for each user). You can still customize the details of what gets
returned by including request parameters in the emailed link ... those
parameters can be used, for example, to select the correct data from the
database, or implement whatever else you need to do to specialze the
response for this particular user.
So, you could end up with some URL like this:
http://www.mycompany.com/myapp/dataQueryResults.faces?ticket=123456
and, in the prerender() method, you'd grab the "ticket" parameter and use it
to look up stuff from the database. You could even implement "you can only
access this data once" type checks by updating the database data for this
ticket identifier the first time it is accessed.
But, the bottom line is, fewer classes makes for better, more maintainable,
code. And, this keeps Shale Remoting focused on what it is aimed at --
supporting asynchronous callbacks, not the entire JSF lifecycle (including
navigation). The standard FacesServlet covers that need quite nicely
already :-).
Craig
- Ingo
Craig McClanahan schrieb:
> On 9/28/06, Ingo Düppe <[EMAIL PROTECTED]> wrote:
>>
>> Hi Craig,
>>
>> guess you are right that the remoting is not the solution for my
>> problem. What I like to realize is the following:
>> - The user gets an email with a link to the webapp.
>> - When the user click on this link an action method should decide
>> whether the link is still valid or not.
>> - If the link is still valid the user is redirected to the login page.
>> - If not the user is redirected to a new request page.
>
>
> That seems like a reasonable use case.
>
>
> So what I need is a solution to trigger an action method by a get
>> request that returns an outcome that is handled by jsf?
>
>
> JSF doesn't have any direct support for this, but here's an approach
> to it
> using Shale. An interesting fact is that the prerender() method of a
> ViewController gets called before rendering, even on a GET request. The
> return method here is void, so you can't just return a string and let
the
> standard NavigationHandler do its thing, but you *can* fake this out.
> Consider the following:
>
> public class MyLinkChecker extends AbstractViewController {
> ...
> public void prerender() {
> FacesContext context = FacesContext.getCurrentInstance();
> boolean isValid = ...; // Examine current state, determine if
> its valid
> if (!isValid) {
> // Force the user to see the logon page instead of the
> requested one
> ViewController vc = context.getApplication
> ().getViewController();
> vc.createView(context, "/logon.jsp");
> } else {
> ... prepare any data needed to render this page ...
> }
> ...
> }
>
> You could put logic like this in the view controller of any page that
> needs
> this sort of check, or perhaps build a common superclass to
> encapsulate it.
> Then, just use a normal URL for the page in the email link that you send
> out.
>
> Craig
>
