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 <[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
