Re: Remoting and Outcome

[Ingo Düppe <ma...@dueppe.com>]

Hi Craig, Hi William,

William, I understood you that I could implement my feature by 
implementing a new MethodBindingProcessor to extend the shale remoting 
library.

That leads me into the discussion is it worst to extend the shale 
remoting to general support this feature. Especially most of the needed 
classes are already there.
As you mentioned one just need an additional MethodBindingProcessor (and 
maybe an additional url prefix).

But I totally agree to Craig objection that adding this feature would 
soften the original use case of shale remoting and it should be focused 
on what it is aimed at.

Why I prefer an addition class is that I assume that the resulting pages 
including the backing beans and the jsps in my scenario already exist. 
And then I need an additional object to decide where the 
none-jsf-request should be forward to. To keep up the separation of 
concerns I divided my classes in ViewController and Actions. 
ViewController aimed at controlling everything in a specific view (1:1 
or 1:n). Actions aimed at processing external events like a 
none-jsf-request.

As far as I understood I always need a jsp (or xhtml if using facelets 
:-) to bind a ViewController to a url so that the lifecycle invokes the 
ViewController methods.
So I like my solution with a PhaseListener and action classes  because 
I  don't need any dummy jsps. I just configure the methods to be invoked 
in a spring configuration file. Btw. I still can catch up the parameter 
of request within my action classes.

To sum it up It would certainly be technically feasible to create 
something like this. But Craig is right that extending the shale 
remoting is the wrong place. Keeping things focused is always better. 
But maybe we found another place to provide this feature to explicit 
bind an url to a method of a backing bean that generates outcomes.

Regards
- Ingo


Craig McClanahan schrieb:
> On 9/28/06, Ingo Düppe <ma...@dueppe.com> 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