You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Hubert Rabago <hr...@gmail.com> on 2006/04/13 18:06:47 UTC
JSF can handle GET requests *just as easily* as other frameworks
Jacob Hookom, in discussing JSF myths [1], claims that:
"Also, JSF can handle GET requests just as easily as other frameworks.
Because of JSF's
managed bean (IoC container), you can do the same kinds of things as
you can with
WebWork -- from parameter assignment to backing beans. An example is
linking from page
to page where id's are passed -- you can go the same route as Struts
or WebWork and just
render "employee.jsf?id=#{emp.id}" -- you don't have to use stateful component
communication between pages."
Is there any truth to this? I thought the reason we had extensions
like NonFacesRequestServlet [2] was because this wasn't supported by
the core functionality?
thanks,
Hubert
[1] http://virtuas.com/articles/webframework-sweetspots.html
[2] http://wiki.apache.org/myfaces/InvokingJsfPagesWithStandardUrls
Re: JSF can handle GET requests *just as easily* as other frameworks
Posted by Mario Ivankovits <ma...@ops.co.at>.
Werner Punz schrieb:
>>
> well with a hello world it is :-D
>
>
Ok, you won :-D
---
Mario
Re: JSF can handle GET requests *just as easily* as other frameworks
Posted by Werner Punz <we...@gmx.at>.
Mario Ivankovits schrieb:
> Hi!
>> Theoretically you could write a form object which allows http get
>> but there are severe limitations and problems with a pure get, so no one
>> has done it so far.
>>
> Only if you also pass the viewstate and tree as get-parameter.
> Given the size limitations of urls I'll say its not even theoretically
> possible ;-)
>
well with a hello world it is :-D
Re: JSF can handle GET requests *just as easily* as other frameworks
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi!
> Theoretically you could write a form object which allows http get
> but there are severe limitations and problems with a pure get, so no one
> has done it so far.
>
Only if you also pass the viewstate and tree as get-parameter.
Given the size limitations of urls I'll say its not even theoretically
possible ;-)
---
Mario
Re: JSF can handle GET requests *just as easily* as other frameworks
Posted by Werner Punz <we...@gmx.at>.
I do not think this is totally true,
a http form get is only achievable by bypassing
jsf out of the box. Since all form handling
relies severely on http post (for many reasons)
A parametrized link however can be achieved even without bypassing jsf.
Theoretically you could write a form object which allows http get
but there are severe limitations and problems with a pure get, so no one
has done it so far.
Hubert Rabago schrieb:
> Jacob Hookom, in discussing JSF myths [1], claims that:
>
> "Also, JSF can handle GET requests just as easily as other frameworks.
> Because of JSF's
> managed bean (IoC container), you can do the same kinds of things as
> you can with
> WebWork -- from parameter assignment to backing beans. An example is
> linking from page
> to page where id's are passed -- you can go the same route as Struts
> or WebWork and just
> render "employee.jsf?id=#{emp.id}" -- you don't have to use stateful component
> communication between pages."
>
> Is there any truth to this? I thought the reason we had extensions
> like NonFacesRequestServlet [2] was because this wasn't supported by
> the core functionality?
>
> thanks,
> Hubert
>
> [1] http://virtuas.com/articles/webframework-sweetspots.html
> [2] http://wiki.apache.org/myfaces/InvokingJsfPagesWithStandardUrls
>
Re: JSF can handle GET requests *just as easily* as other frameworks
Posted by Hubert Rabago <hr...@gmail.com>.
Ok, thanks. I just wanted to make sure I didn't miss something
obvious, or something not so obvious.
Oh wait a sec. How *would* you do it? I mean, what's a better way
than NonFacesRequestServlet? Can you explain to a noob like me, or
maybe point to me to a URL?
You say "along the same lines as some of Jacob's thoughts" so maybe
that's what I'm looking for. Maybe that's what Jacob is referring to.
Hubert
On 4/14/06, Adam Winer <aw...@gmail.com> wrote:
> It doesn't execute a managed bean; that's not how JSF
> works. It's not an action framework. (I misunderstood
> your statement, which wasn't precisely worded.)
>
> This *does* mean that the request is specifically targetted
> at a page, and does not go through navigation rules.
> That's a legit nit to pick, and that's useful functionality
> for something like NonFacesRequestServlet, though I'd
> probably do this in a different way inside the JSF lifecycle
> along the same lines as some of Jacob's thoughts.
>
> -- Adam
>
Re: JSF can handle GET requests *just as easily* as other frameworks
Posted by Adam Winer <aw...@gmail.com>.
It doesn't execute a managed bean; that's not how JSF
works. It's not an action framework. (I misunderstood
your statement, which wasn't precisely worded.)
This *does* mean that the request is specifically targetted
at a page, and does not go through navigation rules.
That's a legit nit to pick, and that's useful functionality
for something like NonFacesRequestServlet, though I'd
probably do this in a different way inside the JSF lifecycle
along the same lines as some of Jacob's thoughts.
-- Adam
On 4/14/06, Hubert Rabago <hr...@gmail.com> wrote:
> On 4/14/06, Adam Winer <aw...@gmail.com> wrote:
> > On 4/14/06, Hubert Rabago <hr...@gmail.com> wrote:
> > > Without something like NonFacesRequestServlet, the request goes
> > > directly to the JSP and bypasses managed beans. That was my
> > > understanding. Jacob says I'm wrong, and I was wondering if someone
> > > can show me the way.
> >
> > That's just plain false. A GET request does not bypass
> > managed beans. Jacob is 100% accurate to describe that
> > as a myth.
> >
> > -- Adam
>
> Oh, wow, learn something new everyday, including Fridays.
> How does it know what backing bean to call and what method does it execute?
>
> Hubert
>
Re: JSF can handle GET requests *just as easily* as other frameworks
Posted by Hubert Rabago <hr...@gmail.com>.
On 4/14/06, Adam Winer <aw...@gmail.com> wrote:
> On 4/14/06, Hubert Rabago <hr...@gmail.com> wrote:
> > Without something like NonFacesRequestServlet, the request goes
> > directly to the JSP and bypasses managed beans. That was my
> > understanding. Jacob says I'm wrong, and I was wondering if someone
> > can show me the way.
>
> That's just plain false. A GET request does not bypass
> managed beans. Jacob is 100% accurate to describe that
> as a myth.
>
> -- Adam
Oh, wow, learn something new everyday, including Fridays.
How does it know what backing bean to call and what method does it execute?
Hubert
Re: JSF can handle GET requests *just as easily* as other frameworks
Posted by Adam Winer <aw...@gmail.com>.
On 4/14/06, Hubert Rabago <hr...@gmail.com> wrote:
> On 4/14/06, Craig McClanahan <cr...@apache.org> wrote:
> > On 4/14/06, Werner Punz <we...@gmx.at> wrote:
> > > I think what the original poster wanted was to have the entire form and
> > > event handling based on get
> >
> > If that is indeed what the original poster wanted, then I hope the original
> > poster will realize that what he/she wants is *not* what the HTTP specs say
> > a GET request should do.
>
> And then the OP says: Whoa! You guys are flying above my head!
>
> All I wanted was an idea on what Jacob Hookom was talking about. HE
> is the one who presented the example:
>
> "An example is linking from page to page where id's are passed -- you
> can go the same route as Struts or WebWork and just render
> "employee.jsf?id=#{emp.id}" -- you don't have to use stateful
> component communication between pages."
>
> Without something like NonFacesRequestServlet, the request goes
> directly to the JSP and bypasses managed beans. That was my
> understanding. Jacob says I'm wrong, and I was wondering if someone
> can show me the way.
That's just plain false. A GET request does not bypass
managed beans. Jacob is 100% accurate to describe that
as a myth.
-- Adam
> I guess I shoulda ask Jacob directly, but I was hoping he'd either
> hang out here and see the question, or one of you guys can help me
> out.
>
> Hubert
>
Re: JSF can handle GET requests *just as easily* as other frameworks
Posted by Joey Geiger <jo...@staff.onmilwaukee.com>.
You can pass get requests, but you lose the current state of the
application.
I have a setup that uses a URL like /product/product.jsf?prodid=1234
product.xhtml (partial)
...snip...
<c:set var="bean" value="#{productPageBean}"/>
<c:set var="entity" value="#{bean['product']}"/>
<h:outputText value="#{productPageBean['redirect']}" escape="false"
rendered="#{not productPageBean.found}" />
...snip...
<span class="hugeBoldText">#{entity['title']}</span>
...snip...
ProductPageBean.java (partial)
protected void init() {
this.productid = FacesUtils.getRequestParameter("prodid");
this.product = dao.getProduct(this.productid);
}
FacesUtils.java (partial)
public static String getRequestParameter(String name) {
return
(String)FacesContext.getCurrentInstance().getExternalContext().getRequestParameterMap().get(name);
}
Re: JSF can handle GET requests *just as easily* as other frameworks
Posted by Adam Brod <AB...@intralinks.com>.
If you have your faces servlet configured to receive *.jsf, then all
requests to jsp pages that use *.jsf will be intercepted by JSF. That
means the target JSP can have a full component tree with jsf component
goodness. However, as another user mentioned, you will lose the state of
the originating page (but often times that's ok).
Adam Brod
Product Development Team
Re: JSF can handle GET requests *just as easily* as other frameworks
Posted by Hubert Rabago <hr...@gmail.com>.
On 4/14/06, Craig McClanahan <cr...@apache.org> wrote:
> On 4/14/06, Werner Punz <we...@gmx.at> wrote:
> > I think what the original poster wanted was to have the entire form and
> > event handling based on get
>
> If that is indeed what the original poster wanted, then I hope the original
> poster will realize that what he/she wants is *not* what the HTTP specs say
> a GET request should do.
And then the OP says: Whoa! You guys are flying above my head!
All I wanted was an idea on what Jacob Hookom was talking about. HE
is the one who presented the example:
"An example is linking from page to page where id's are passed -- you
can go the same route as Struts or WebWork and just render
"employee.jsf?id=#{emp.id}" -- you don't have to use stateful
component communication between pages."
Without something like NonFacesRequestServlet, the request goes
directly to the JSP and bypasses managed beans. That was my
understanding. Jacob says I'm wrong, and I was wondering if someone
can show me the way.
I guess I shoulda ask Jacob directly, but I was hoping he'd either
hang out here and see the question, or one of you guys can help me
out.
Hubert
Re: JSF can handle GET requests *just as easily* as other frameworks
Posted by Craig McClanahan <cr...@apache.org>.
On 4/14/06, Werner Punz <we...@gmx.at> wrote:
>
> Adam Winer schrieb:
> > Mike,
> >
> > What do you mean by "not supported in the core"?
> >
> > A GET request turns into an initial render request - no
> > phases other than Render Response - but Jacob's entirely
> > correct that JSF *does* support GET, and you can funnel
> > request parameters directly into your managed beans.
> > This is definitely supported by the core, required by the
> > spec, etc. No theory here.
> >
> I think what the original poster wanted was to have the entire form and
> event handling based on get, that is not possible with the current state
> of components to my knowledge unless someone writes a get parametrizable
> form.
If that is indeed what the original poster wanted, then I hope the original
poster will realize that what he/she wants is *not* what the HTTP specs say
a GET request should do. In particular, a GET request should be idempotent
-- it should be no problem to repeat the request multiple times (no fair
charging my credit card again if this happens to be the checkout page of a
shopping app), and you should (in general) get the same results each time
you invoke the same URL via a GET.
Applications that are based on GET requests that process form submits, then,
should generally be considered broken, as far as the HTTP spec is concerned
... and that is not anything specific to JSF.
What matters for JSF and GETs is to be able to create bookmarkable URLs for
idempotent requests ("show me the current items in my shopping cart" or
"show me the current items that match my most recent query"). No, that is
not the default behavior of links created by the standard "command"
components. But yes, it is easy to do the same thing you would do in any
other framework to deal with such requests. Indeed, because of the managed
property ability to do dependency injection on backing beans, it is actually
*easier* to deal with this kind of situation than it is in something like
Struts 1.x.
But we all know how much limitations such an approach imposes and that
> it causes more problems than it really solves.
>
>
Craig McClanahan
Re: JSF can handle GET requests *just as easily* as other frameworks
Posted by Werner Punz <we...@gmx.at>.
Adam Winer schrieb:
> Mike,
>
> What do you mean by "not supported in the core"?
>
> A GET request turns into an initial render request - no
> phases other than Render Response - but Jacob's entirely
> correct that JSF *does* support GET, and you can funnel
> request parameters directly into your managed beans.
> This is definitely supported by the core, required by the
> spec, etc. No theory here.
>
I think what the original poster wanted was to have the entire form and
event handling based on get, that is not possible with the current state
of components to my knowledge unless someone writes a get parametrizable
form.
But we all know how much limitations such an approach imposes and that
it causes more problems than it really solves.
Re: JSF can handle GET requests *just as easily* as other frameworks
Posted by Adam Brod <AB...@intralinks.com>.
> the interesting question (which you're posing) is how to make
> JSF better tomorrow than it is today.
Exactly! Simplifying some action-style interactions just makes the
framework richer and expands its usefulness.
Adam Brod
Product Development Team
"Adam Winer" <aw...@gmail.com>
04/14/2006 06:10 PM
Please respond to
"MyFaces Discussion" <us...@myfaces.apache.org>
To
"MyFaces Discussion" <us...@myfaces.apache.org>
cc
Subject
Re: JSF can handle GET requests *just as easily* as other frameworks
On 4/14/06, Adam Brod <AB...@intralinks.com> wrote:
>
> Adam-
>
> I don't think your response is quite what I was getting at. In Struts
> world, I have lots of ugly code sprinkled everywhere that converts
request
> params to very low-level custom objects in our system (for example,
Enums
> for statuses, types, and flags as well as other objects like
Identifiers,
> Credit Card Numbers, EmailAddresses, etc.), When using JSF post-backs,
we
> can use Converters to handle all that boiler-plate request param ->
object
> mapping. If using JSF with GET requests, we cannot use converters, can
we?
For JSF 1.2, you'll have type coercion - but that only gets you
to primitive types. There's no direct support in the EL APIs for
extending the type coercion semantics. I think you could do so with
a particularly clever AOP layer on top of a managed bean.
Or, more elegantly, use an ELResolver (or PropertyResolver in 1.1)
that knows how to go from a String to a particular type of object;
make that resolver dynamically hooked up to metadata that
is per-page specific (or annotation-based), and you can cleanly
automate a lot of this.
So, for instance, you could work towards a system like;
/**
* @requestParameter mailto
* @convertOnSet mypackage.foo.EmailConverter
public void setEmail(EmailBean bean)
... that would automate all of that conversion.
> If my understanding is correct, that is a definitely limitation of using
GET
> with JSF.
True. The question on our plate was whether JSF is worse
than other frameworks, and based on your description above of
all the nastiness in Struts, we definitely have one counterexample.
But the issue of whether JSF is worse or better is basically
a question most suited for another pointless "smackdown", and
the interesting question (which you're posing) is how to make
JSF better tomorrow than it is today.
-- Adam
Re: JSF can handle GET requests *just as easily* as other frameworks
Posted by Adam Winer <aw...@gmail.com>.
On 4/14/06, Adam Brod <AB...@intralinks.com> wrote:
>
> Adam-
>
> I don't think your response is quite what I was getting at. In Struts
> world, I have lots of ugly code sprinkled everywhere that converts request
> params to very low-level custom objects in our system (for example, Enums
> for statuses, types, and flags as well as other objects like Identifiers,
> Credit Card Numbers, EmailAddresses, etc.), When using JSF post-backs, we
> can use Converters to handle all that boiler-plate request param -> object
> mapping. If using JSF with GET requests, we cannot use converters, can we?
For JSF 1.2, you'll have type coercion - but that only gets you
to primitive types. There's no direct support in the EL APIs for
extending the type coercion semantics. I think you could do so with
a particularly clever AOP layer on top of a managed bean.
Or, more elegantly, use an ELResolver (or PropertyResolver in 1.1)
that knows how to go from a String to a particular type of object;
make that resolver dynamically hooked up to metadata that
is per-page specific (or annotation-based), and you can cleanly
automate a lot of this.
So, for instance, you could work towards a system like;
/**
* @requestParameter mailto
* @convertOnSet mypackage.foo.EmailConverter
public void setEmail(EmailBean bean)
... that would automate all of that conversion.
> If my understanding is correct, that is a definitely limitation of using GET
> with JSF.
True. The question on our plate was whether JSF is worse
than other frameworks, and based on your description above of
all the nastiness in Struts, we definitely have one counterexample.
But the issue of whether JSF is worse or better is basically
a question most suited for another pointless "smackdown", and
the interesting question (which you're posing) is how to make
JSF better tomorrow than it is today.
-- Adam
Re: JSF can handle GET requests *just as easily* as other frameworks
Posted by Adam Winer <aw...@gmail.com>.
In the context of a mini-controller with "action" UIComponents of
a sort, Converters and Validators make sense; it'd be very interesting
to see where this could go. BTW, JSF 1.2 has better support for
letting a RenderKit override whether a request counts as a postback,
which'd make it possible to mark something like this sort of a page as
a postback (and therefore run the full request lifecycle) even on a GET.
This "mini-controller" would definitely be a great experiment to try, and
might help solidify some of the ideas Jacob and I have had for
JSF 2.0.
I still don't think Converters and Validators are the right fit for
EL coercion. e.g., <property-value>#{myBean.personId}</property-value>
is not a Converter scenario.
-- Adam
On 4/16/06, Martin Marinschek <ma...@gmail.com> wrote:
> Mario,
>
> you're right.
>
> and even if I smell model 1 here, I want this in MyFaces. This is the
> KISS principle put into place for JSF.
>
> regards,
>
> Martin
>
> On 4/15/06, Mario Ivankovits <ma...@ops.co.at> wrote:
> > Hi!
> > >
> > > There is a common tendency for developers using
> > > JSF to see any "String in, Object out" case as
> > > being Converter-based; I'd recommend against
> > > making that assumption. ;)
> > >
> > >
> > > I would agree with that basic sentiment ... after all, the next thing
> > > people would want for this use case is validators :-).
> > I still dont get you all. Yes the above is true, we want converters and
> > validators even for url-get-parameters.
> > And I dont know what should be bad with this, It makes absolutely no
> > difference if the user entered the stuff in an form or if the data comes
> > from the url.
> >
> > So this is why I propose to use a minimalistic view as (mini)
> > controller, though, this is not an requirement, to handle this stuff.
> > We can have another tag so we can have the full flexibility as we have
> > now in JSF.
> >
> > In code it might look like this:
> >
> > <t:getParams>
> > <t:getParam id="documentId" value="#{documentBean.documentId}"
> > converter="a.b.c.DocumentIdEntityConverter">
> > <f:validator .... />
> > </t:getParam>
> > </t:getParams>
> >
> > <h:messages/>
> >
> > the analogy to JSF is, that t:getParams is much like a h:form and
> > t.getParam is the same as h:inputHidden.
> >
> > To get the parameters into the url one can e.g.use outputLink or a
> > enhanced navigation rule.
> >
> > I still cant see what will be bad with this.
> >
> >
> > Ciao,
> > Mario
> >
> >
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
Re: JSF can handle GET requests *just as easily* as other frameworks
Posted by Martin Marinschek <ma...@gmail.com>.
Mario,
you're right.
and even if I smell model 1 here, I want this in MyFaces. This is the
KISS principle put into place for JSF.
regards,
Martin
On 4/15/06, Mario Ivankovits <ma...@ops.co.at> wrote:
> Hi!
> >
> > There is a common tendency for developers using
> > JSF to see any "String in, Object out" case as
> > being Converter-based; I'd recommend against
> > making that assumption. ;)
> >
> >
> > I would agree with that basic sentiment ... after all, the next thing
> > people would want for this use case is validators :-).
> I still dont get you all. Yes the above is true, we want converters and
> validators even for url-get-parameters.
> And I dont know what should be bad with this, It makes absolutely no
> difference if the user entered the stuff in an form or if the data comes
> from the url.
>
> So this is why I propose to use a minimalistic view as (mini)
> controller, though, this is not an requirement, to handle this stuff.
> We can have another tag so we can have the full flexibility as we have
> now in JSF.
>
> In code it might look like this:
>
> <t:getParams>
> <t:getParam id="documentId" value="#{documentBean.documentId}"
> converter="a.b.c.DocumentIdEntityConverter">
> <f:validator .... />
> </t:getParam>
> </t:getParams>
>
> <h:messages/>
>
> the analogy to JSF is, that t:getParams is much like a h:form and
> t.getParam is the same as h:inputHidden.
>
> To get the parameters into the url one can e.g.use outputLink or a
> enhanced navigation rule.
>
> I still cant see what will be bad with this.
>
>
> Ciao,
> Mario
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: JSF can handle GET requests *just as easily* as other frameworks
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi!
>
> There is a common tendency for developers using
> JSF to see any "String in, Object out" case as
> being Converter-based; I'd recommend against
> making that assumption. ;)
>
>
> I would agree with that basic sentiment ... after all, the next thing
> people would want for this use case is validators :-).
I still dont get you all. Yes the above is true, we want converters and
validators even for url-get-parameters.
And I dont know what should be bad with this, It makes absolutely no
difference if the user entered the stuff in an form or if the data comes
from the url.
So this is why I propose to use a minimalistic view as (mini)
controller, though, this is not an requirement, to handle this stuff.
We can have another tag so we can have the full flexibility as we have
now in JSF.
In code it might look like this:
<t:getParams>
<t:getParam id="documentId" value="#{documentBean.documentId}"
converter="a.b.c.DocumentIdEntityConverter">
<f:validator .... />
</t:getParam>
</t:getParams>
<h:messages/>
the analogy to JSF is, that t:getParams is much like a h:form and
t.getParam is the same as h:inputHidden.
To get the parameters into the url one can e.g.use outputLink or a
enhanced navigation rule.
I still cant see what will be bad with this.
Ciao,
Mario
Re: JSF can handle GET requests *just as easily* as other frameworks
Posted by Craig McClanahan <cr...@apache.org>.
On 4/14/06, Adam Winer <aw...@gmail.com> wrote:
>
> Craig, Adam B.,
>
> I don't think Converters are a good path to go down here.
> Converters are globally registered, not contextually,
> so they don't reflect the local meaning of what a "personId"
> might mean, which is certainly not going to be a fixed mapping
> across an entire application. They're also generally supposed to
> used alongside of a UIComponent - which is explicitly *not*
> what's happening here. Finally, Converters exist for
> user-friendly, Localized presentation of data, whereas URLs
> parameters should always be non-Localized. You can hack
> around these things, but cumulatively, they should represent
> a clear message that Converters aren't the right way to go!
>
> I agree with Adam B. that user-friendly errors are
> sort of besides the point here - another thing pointing
> away from Converters - since errors in URLs point to
> either system malfunctions or malicious misuse (or,
> sometimes, stale URLs), and all should be directed to
> (user-friendly) error pages - a 404 Page Not Found as
> a pretty good starting point.
>
> I think you want a system that is much more driven by,
> for example, annotations, and is ELResolver based -
> since an ELResolver will very specifically be
> operating on a specific property of a given bean in a
> very specific context.
There is a common tendency for developers using
> JSF to see any "String in, Object out" case as
> being Converter-based; I'd recommend against
> making that assumption. ;)
I would agree with that basic sentiment ... after all, the next thing people
would want for this use case is validators :-).
-- Adam
Craig
On 4/14/06, Craig McClanahan <cr...@apache.org> wrote:
> > On 4/14/06, Adam Brod <AB...@intralinks.com> wrote:
> >
> > >
> > >
> > > But in your example, personId is a primitive. What I really want is
> to
> > pass my own model objects from the List to the Detail page (without
> > post-backs). Would your example work if personId were a
> PersonIdentifier
> > object?
> >
> >
> > No. As I mentioned earlier, the set of conversions supported is the
> same as
> > those for <jsp:setProperty>, which basically means you get the
> primitives
> > for free, but need to convert other things yourself.
> >
> > >
> > > What about other custom properties such as Enums, EmailAddresses,
> etc?
> > If so, then how? Does it invoke converters at ManagedBean creation
> time?
> >
> >
> > JSF 1.1 (and 1.2) don't currently do this for you, but you certainly
> could
> > do it yourself if you've registered your own JSF converters for these
> types.
> > You'd code the properties like personId as strings, and then in the
> logic
> > that deals with them, do something like this:
> >
> > FacesContext context = FacesContext.getCurrentInstance();
> > Converter converter =
> > context.getApplication().getConverter("PersonIdentifierConverter");
> > PersonIdentifier pi = (PersonIdentifier) converter.getAsObject
> (context,
> > null, getPersonId());
> >
> > >
> > > Adam Brod
> > > Product Development Team
> >
> > Craig
> >
> >
> > >
> > >
> > >
> > > "Craig McClanahan" <cr...@apache.org>
> > > Sent by: craigmcc@gmail.com
> > >
> > >
> > > 04/14/2006 06:31 PM
> > >
> > >
> > > Please respond to
> > > "MyFaces Discussion" <us...@myfaces.apache.org>
> > >
> > >
> > > To "MyFaces Discussion" <us...@myfaces.apache.org>
> > >
> > > cc
> > >
> > >
> > > Subject Re: JSF can handle GET requests *just as easily* as other
> > frameworks
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > On 4/14/06, Adam Brod <ABrod@intralinks.com > wrote:
> > >
> > > Craig-
> > >
> > > Thanks for your response. I understand that the existing Shale
> remoting
> > code wouldn't work, but as you wrote - the same principle could be
> applied.
> > >
> > >
> > > "However, dealing with conversion errors on unedited request
> > parameters (it'll likely throw an exception) is probably not as user
> > friendly as it really ought to be. "
> > >
> > > Back to parameter mapping: since we are talking about request URLs, we
> > don't generally need to be concerned about user-friendly errors. A
> > malformed URL is a developer error in this case. In most cases, we'd
> > probably be "passing" the id from the person list to the person detail
> page.
> > (To be clear, I'm talking about using action-style urls just for
> > navigation, not for form submissions where we expect conversion
> errors. I
> > find that navigating from a list page to a detail page is too
> heavy-weight
> > using post-backs with potentially large datasets.)
> > >
> > > As an added benefit, you can get bookmarkable URLs out of the deal
> too.
> > >
> > > If the framework didn't do this and I were to use longs and Strings in
> my
> > managed bean properties, then I'd have to write code that creates the
> model
> > objects. In the exceptional case that the primitive managed properties
> > couldn't be converted, I would probably just throw an
> exception. Exceptions
> > are generally okay for developer errors that can be fixed at development
> > time. I'd rather the framework do this basic conversion for me since it
> > works great 90+% of the time. If I have a special case that needs
> special
> > error handling, I'll hand-code those few cases (or use post-backs).
> > >
> > > Does that make sense?
> > >
> > > Yep, that makes sense. Indeed, JSF today does what you want already.
> > Here's a pattern I've used that makes life pretty easy:
> > >
> > > <managed-bean>
> > > <managed-bean-name>backing</managed-bean-name>
> > > <managed-bean-class>com.foo.BackingBean</managed-bean-class>
> > > <managed-property>
> > > <property-name>personId</property-name>
> > > <value>#{param.personId}</value>
> > > </managed-property>
> > > </managed-bean>
> > >
> > > with a backing bean like this:
> > >
> > > public class BackingBean implements ViewController {
> > >
> > > private int personId;
> > > public int getPersonId() { return this.personId; }
> > > public void setPersonId(int personId) { this.personId =
> personId; }
> > >
> > > ...
> > >
> > > public void prerender() {
> > > // By the time you get here, personId has aready
> > > // been converted and injected, so use it to go look
> > > // up the relevant information
> > > }
> > >
> > > }
> > >
> > > No muss ... no fuss ... if you're willing to have the exception thrown
> on
> > a conversion error.
> > >
> > >
> > > Adam Brod
> > > Product Development Team
> > >
> > > Craig
> > >
> > >
> > > "Craig McClanahan" <craigmcc@apache.org >
> > > Sent by: craigmcc@gmail.com
> > >
> > > 04/14/2006 05:42 PM
> > >
> > >
> > >
> > >
> > > Please respond to
> > > "MyFaces Discussion" <users@myfaces.apache.org >
> > >
> > >
> > > To "MyFaces Discussion" <users@myfaces.apache.org >
> > >
> > > cc
> > >
> > >
> > > Subject Re: JSF can handle GET requests *just as easily* as other
> > frameworks
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > On 4/14/06, Adam Brod < ABrod@intralinks.com> wrote:
> > >
> > > If you wanted a GET to execute an action (and pass parameters), why
> not
> > adapt Shale's url convention
> > /[managedBeanName]/[actionMethod] (for example:
> > /documentController/documentID?id=1234)?
> > >
> > > This capability was specifically designed for being the back end of
> AJAX
> > style requests, but it works quite nicely for bookmarkable URLs too.
> > However ...
> > >
> > > That would enable GET requests to go through the NavigationHandler and
> > have even more of the JSF framework goodness.
> > >
> > > You don't get this out of the box with the current implementation in
> > Shale. That's because, from a JSF lifecycle point of view, Shale's
> phase
> > listener fires after Restore View -- and it will do this:
> > >
> > > * Determine that the URL matches one of the patterns it is configured
> > > to watch for (/dynamic/* by default)
> > >
> > > * Execute the corresponding method via a programmatic method
> > > binding call. As a side effect, this might trigger managed bean
> > > creation of the bean instance containing this method.
> > >
> > > * Expect that the method has created the entire response, so it
> > > calls FaceContext.responseComplete() and returns.
> > >
> > > As you can see, we never actually entered Invoke Application phase, we
> > never pay attention to anything that the invoked method returns (indeed,
> the
> > expected method signature is "public void methodname()"), and we never
> > invoke the navigation handler.
> > >
> > > That's not saying you couldn't configure a Processor that does that
> sort
> > of thing -- its just that the default one doesn't.
> > >
> > > For a use case like a bookmarkable URL, I tend to take a different
> > approach, because of what JSF's lifecycle will do for you anyway -- if
> > Restore View detects that there is no view state to restore, it jumps
> > immediately to Render Response phase. If you can interpose some
> processing
> > logic that happens right before rendering, and hav that logic pull out
> the
> > request parameters you need (or let JSF inject them via the managed
> > properties stuff), then it is very straightforward to process GET
> requests.
> > Shale even gives you a very easy place to put this kind of logic, if
> your
> > backing bean implements ViewController -- stick it in the prerender()
> > method. This approach certainly isn't harder than doing the same sort
> of
> > thing in Struts 1.x.
> > >
> > > Regarding conversion of request parameters to model data types,
> Section
> > 5.3.1.2 of the JSF 1.1 spec discusses using managed properties to inject
> > values into managed beans as they get created. It requires the same
> > implicit conversions that JSP provides for the <jsp:setProperty> tag, so
> > you're covered for things like Java primitives, but not for custom data
> > types. That means you could use a value expression like "#{
> param.personId}
> > to pull out the personId request parameter, and assign it to a bean
> property
> > of type int or long. However, dealing with conversion errors on
> unedited
> > request parameters (it'll likely throw an exception) is probably not as
> user
> > friendly as it really ought to be. I would tend to use string
> properties
> > for that reason.
> > >
> > > Adam Brod
> > > Product Development Team
> > >
> > >
> > > Craig
> > >
> > >
> > >
> >
> >
>
Re: JSF can handle GET requests *just as easily* as other frameworks
Posted by Adam Winer <aw...@gmail.com>.
Craig, Adam B.,
I don't think Converters are a good path to go down here.
Converters are globally registered, not contextually,
so they don't reflect the local meaning of what a "personId"
might mean, which is certainly not going to be a fixed mapping
across an entire application. They're also generally supposed to
used alongside of a UIComponent - which is explicitly *not*
what's happening here. Finally, Converters exist for
user-friendly, Localized presentation of data, whereas URLs
parameters should always be non-Localized. You can hack
around these things, but cumulatively, they should represent
a clear message that Converters aren't the right way to go!
I agree with Adam B. that user-friendly errors are
sort of besides the point here - another thing pointing
away from Converters - since errors in URLs point to
either system malfunctions or malicious misuse (or,
sometimes, stale URLs), and all should be directed to
(user-friendly) error pages - a 404 Page Not Found as
a pretty good starting point.
I think you want a system that is much more driven by,
for example, annotations, and is ELResolver based -
since an ELResolver will very specifically be
operating on a specific property of a given bean in a
very specific context.
There is a common tendency for developers using
JSF to see any "String in, Object out" case as
being Converter-based; I'd recommend against
making that assumption. ;)
-- Adam
On 4/14/06, Craig McClanahan <cr...@apache.org> wrote:
> On 4/14/06, Adam Brod <AB...@intralinks.com> wrote:
>
> >
> >
> > But in your example, personId is a primitive. What I really want is to
> pass my own model objects from the List to the Detail page (without
> post-backs). Would your example work if personId were a PersonIdentifier
> object?
>
>
> No. As I mentioned earlier, the set of conversions supported is the same as
> those for <jsp:setProperty>, which basically means you get the primitives
> for free, but need to convert other things yourself.
>
> >
> > What about other custom properties such as Enums, EmailAddresses, etc?
> If so, then how? Does it invoke converters at ManagedBean creation time?
>
>
> JSF 1.1 (and 1.2) don't currently do this for you, but you certainly could
> do it yourself if you've registered your own JSF converters for these types.
> You'd code the properties like personId as strings, and then in the logic
> that deals with them, do something like this:
>
> FacesContext context = FacesContext.getCurrentInstance();
> Converter converter =
> context.getApplication().getConverter("PersonIdentifierConverter");
> PersonIdentifier pi = (PersonIdentifier) converter.getAsObject(context,
> null, getPersonId());
>
> >
> > Adam Brod
> > Product Development Team
>
> Craig
>
>
> >
> >
> >
> > "Craig McClanahan" <cr...@apache.org>
> > Sent by: craigmcc@gmail.com
> >
> >
> > 04/14/2006 06:31 PM
> >
> >
> > Please respond to
> > "MyFaces Discussion" <us...@myfaces.apache.org>
> >
> >
> > To "MyFaces Discussion" <us...@myfaces.apache.org>
> >
> > cc
> >
> >
> > Subject Re: JSF can handle GET requests *just as easily* as other
> frameworks
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On 4/14/06, Adam Brod <ABrod@intralinks.com > wrote:
> >
> > Craig-
> >
> > Thanks for your response. I understand that the existing Shale remoting
> code wouldn't work, but as you wrote - the same principle could be applied.
> >
> >
> > "However, dealing with conversion errors on unedited request
> parameters (it'll likely throw an exception) is probably not as user
> friendly as it really ought to be. "
> >
> > Back to parameter mapping: since we are talking about request URLs, we
> don't generally need to be concerned about user-friendly errors. A
> malformed URL is a developer error in this case. In most cases, we'd
> probably be "passing" the id from the person list to the person detail page.
> (To be clear, I'm talking about using action-style urls just for
> navigation, not for form submissions where we expect conversion errors. I
> find that navigating from a list page to a detail page is too heavy-weight
> using post-backs with potentially large datasets.)
> >
> > As an added benefit, you can get bookmarkable URLs out of the deal too.
> >
> > If the framework didn't do this and I were to use longs and Strings in my
> managed bean properties, then I'd have to write code that creates the model
> objects. In the exceptional case that the primitive managed properties
> couldn't be converted, I would probably just throw an exception. Exceptions
> are generally okay for developer errors that can be fixed at development
> time. I'd rather the framework do this basic conversion for me since it
> works great 90+% of the time. If I have a special case that needs special
> error handling, I'll hand-code those few cases (or use post-backs).
> >
> > Does that make sense?
> >
> > Yep, that makes sense. Indeed, JSF today does what you want already.
> Here's a pattern I've used that makes life pretty easy:
> >
> > <managed-bean>
> > <managed-bean-name>backing</managed-bean-name>
> > <managed-bean-class>com.foo.BackingBean</managed-bean-class>
> > <managed-property>
> > <property-name>personId</property-name>
> > <value>#{param.personId}</value>
> > </managed-property>
> > </managed-bean>
> >
> > with a backing bean like this:
> >
> > public class BackingBean implements ViewController {
> >
> > private int personId;
> > public int getPersonId() { return this.personId; }
> > public void setPersonId(int personId) { this.personId = personId; }
> >
> > ...
> >
> > public void prerender() {
> > // By the time you get here, personId has aready
> > // been converted and injected, so use it to go look
> > // up the relevant information
> > }
> >
> > }
> >
> > No muss ... no fuss ... if you're willing to have the exception thrown on
> a conversion error.
> >
> >
> > Adam Brod
> > Product Development Team
> >
> > Craig
> >
> >
> > "Craig McClanahan" <craigmcc@apache.org >
> > Sent by: craigmcc@gmail.com
> >
> > 04/14/2006 05:42 PM
> >
> >
> >
> >
> > Please respond to
> > "MyFaces Discussion" <users@myfaces.apache.org >
> >
> >
> > To "MyFaces Discussion" <users@myfaces.apache.org >
> >
> > cc
> >
> >
> > Subject Re: JSF can handle GET requests *just as easily* as other
> frameworks
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On 4/14/06, Adam Brod < ABrod@intralinks.com> wrote:
> >
> > If you wanted a GET to execute an action (and pass parameters), why not
> adapt Shale's url convention
> /[managedBeanName]/[actionMethod] (for example:
> /documentController/documentID?id=1234)?
> >
> > This capability was specifically designed for being the back end of AJAX
> style requests, but it works quite nicely for bookmarkable URLs too.
> However ...
> >
> > That would enable GET requests to go through the NavigationHandler and
> have even more of the JSF framework goodness.
> >
> > You don't get this out of the box with the current implementation in
> Shale. That's because, from a JSF lifecycle point of view, Shale's phase
> listener fires after Restore View -- and it will do this:
> >
> > * Determine that the URL matches one of the patterns it is configured
> > to watch for (/dynamic/* by default)
> >
> > * Execute the corresponding method via a programmatic method
> > binding call. As a side effect, this might trigger managed bean
> > creation of the bean instance containing this method.
> >
> > * Expect that the method has created the entire response, so it
> > calls FaceContext.responseComplete() and returns.
> >
> > As you can see, we never actually entered Invoke Application phase, we
> never pay attention to anything that the invoked method returns (indeed, the
> expected method signature is "public void methodname()"), and we never
> invoke the navigation handler.
> >
> > That's not saying you couldn't configure a Processor that does that sort
> of thing -- its just that the default one doesn't.
> >
> > For a use case like a bookmarkable URL, I tend to take a different
> approach, because of what JSF's lifecycle will do for you anyway -- if
> Restore View detects that there is no view state to restore, it jumps
> immediately to Render Response phase. If you can interpose some processing
> logic that happens right before rendering, and hav that logic pull out the
> request parameters you need (or let JSF inject them via the managed
> properties stuff), then it is very straightforward to process GET requests.
> Shale even gives you a very easy place to put this kind of logic, if your
> backing bean implements ViewController -- stick it in the prerender()
> method. This approach certainly isn't harder than doing the same sort of
> thing in Struts 1.x.
> >
> > Regarding conversion of request parameters to model data types, Section
> 5.3.1.2 of the JSF 1.1 spec discusses using managed properties to inject
> values into managed beans as they get created. It requires the same
> implicit conversions that JSP provides for the <jsp:setProperty> tag, so
> you're covered for things like Java primitives, but not for custom data
> types. That means you could use a value expression like "#{ param.personId}
> to pull out the personId request parameter, and assign it to a bean property
> of type int or long. However, dealing with conversion errors on unedited
> request parameters (it'll likely throw an exception) is probably not as user
> friendly as it really ought to be. I would tend to use string properties
> for that reason.
> >
> > Adam Brod
> > Product Development Team
> >
> >
> > Craig
> >
> >
> >
>
>
Re: JSF can handle GET requests *just as easily* as other frameworks
Posted by Craig McClanahan <cr...@apache.org>.
On 4/14/06, Adam Brod <AB...@intralinks.com> wrote:
>
>
> But in your example, personId is a primitive. What I really want is to
> pass my own model objects from the List to the Detail page (without
> post-backs). Would your example work if personId were a PersonIdentifier
> object?
>
No. As I mentioned earlier, the set of conversions supported is the same as
those for <jsp:setProperty>, which basically means you get the primitives
for free, but need to convert other things yourself.
What about other custom properties such as Enums, EmailAddresses, etc? If
> so, then how? Does it invoke converters at ManagedBean creation time?
>
JSF 1.1 (and 1.2) don't currently do this for you, but you certainly could
do it yourself if you've registered your own JSF converters for these
types. You'd code the properties like personId as strings, and then in the
logic that deals with them, do something like this:
FacesContext context = FacesContext.getCurrentInstance();
Converter converter = context.getApplication
().getConverter("PersonIdentifierConverter");
PersonIdentifier pi = (PersonIdentifier) converter.getAsObject(context,
null, getPersonId());
* Adam Brod**
> Product Development Team*
>
Craig
*"Craig McClanahan" <cr...@apache.org>*
> Sent by: craigmcc@gmail.com
>
> 04/14/2006 06:31 PM
> Please respond to
> "MyFaces Discussion" <us...@myfaces.apache.org>
>
> To
> "MyFaces Discussion" <us...@myfaces.apache.org> cc
>
> Subject
> Re: JSF can handle GET requests *just as easily* as other frameworks
>
>
>
>
>
>
>
>
> On 4/14/06, *Adam Brod* <*ABrod@intralinks.com* <AB...@intralinks.com>>
> wrote:
>
> Craig-
>
> Thanks for your response. I understand that the existing Shale remoting
> code wouldn't work, but as you wrote - the same principle could be applied.
>
>
> "*However, dealing with conversion errors on unedited request
> parameters (it'll likely throw an exception) is probably not as user
> friendly as it really ought to be*. "
>
> Back to parameter mapping: since we are talking about request URLs, we
> don't generally need to be concerned about user-friendly errors. A
> malformed URL is a developer error in this case. In most cases, we'd
> probably be "passing" the id from the person list to the person detail page.
> (To be clear, I'm talking about using action-style urls just for
> navigation, not for form submissions where we *expect* conversion errors.
> I find that navigating from a list page to a detail page is too
> heavy-weight using post-backs with potentially large datasets.)
>
> As an added benefit, you can get bookmarkable URLs out of the deal too.
>
> If the framework didn't do this and I were to use longs and Strings in my
> managed bean properties, then I'd have to write code that creates the model
> objects. In the exceptional case that the primitive managed properties
> couldn't be converted, I would probably just throw an exception. Exceptions
> are generally okay for developer errors that can be fixed at development
> time. I'd rather the framework do this basic conversion for me since it
> works great 90+% of the time. If I have a special case that needs special
> error handling, I'll hand-code those few cases (or use post-backs).
>
> Does that make sense?
>
> Yep, that makes sense. Indeed, JSF today does what you want already.
> Here's a pattern I've used that makes life pretty easy:
>
> <managed-bean>
> <managed-bean-name>backing</managed-bean-name>
> <managed-bean-class>com.foo.BackingBean</managed-bean-class>
> <managed-property>
> <property-name>personId</property-name>
> <value>#{param.personId}</value>
> </managed-property>
> </managed-bean>
>
> with a backing bean like this:
>
> public class BackingBean implements ViewController {
>
> private int personId;
> public int getPersonId() { return this.personId; }
> public void setPersonId(int personId) { this.personId = personId; }
>
> ...
>
> public void prerender() {
> // By the time you get here, personId has aready
> // been converted and injected, so use it to go look
> // up the relevant information
> }
>
> }
>
> No muss ... no fuss ... if you're willing to have the exception thrown on
> a conversion error.
>
>
> *Adam Brod**
> Product Development Team*
>
> Craig
>
> *"Craig McClanahan" <**craigmcc@apache.org* <cr...@apache.org>*>*
> Sent by: *craigmcc@gmail.com* <cr...@gmail.com>
>
> 04/14/2006 05:42 PM
>
>
> Please respond to
> "MyFaces Discussion" <*u...@myfaces.apache.org>
> >
>
> To
> "MyFaces Discussion" <*u...@myfaces.apache.org>
> > cc
>
> Subject
> Re: JSF can handle GET requests *just as easily* as other frameworks
>
>
>
>
>
>
>
>
>
>
> On 4/14/06, *Adam Brod* <* ABrod@intralinks.com* <AB...@intralinks.com>>
> wrote:
>
> If you wanted a GET to execute an action (and pass parameters), why not
> adapt Shale's url convention /[managedBeanName]/[actionMethod] (for example:
> /documentController/documentID?id=1234)?
>
> This capability was specifically designed for being the back end of AJAX
> style requests, but it works quite nicely for bookmarkable URLs too.
> However ...
>
> That would enable GET requests to go through the NavigationHandler and
> have even more of the JSF framework goodness.
>
> You don't get this out of the box with the current implementation in
> Shale. That's because, from a JSF lifecycle point of view, Shale's phase
> listener fires after Restore View -- and it will do this:
>
> * Determine that the URL matches one of the patterns it is configured
> to watch for (/dynamic/* by default)
>
> * Execute the corresponding method via a programmatic method
> binding call. As a side effect, this might trigger managed bean
> creation of the bean instance containing this method.
>
> * Expect that the method has created the entire response, so it
> calls FaceContext.responseComplete() and returns.
>
> As you can see, we never actually entered Invoke Application phase, we
> never pay attention to anything that the invoked method returns (indeed, the
> expected method signature is "public void methodname()"), and we never
> invoke the navigation handler.
>
> That's not saying you couldn't configure a Processor that does that sort
> of thing -- its just that the default one doesn't.
>
> For a use case like a bookmarkable URL, I tend to take a different
> approach, because of what JSF's lifecycle will do for you anyway -- if
> Restore View detects that there is no view state to restore, it jumps
> immediately to Render Response phase. If you can interpose some processing
> logic that happens right before rendering, and hav that logic pull out the
> request parameters you need (or let JSF inject them via the managed
> properties stuff), then it is very straightforward to process GET requests.
> Shale even gives you a very easy place to put this kind of logic, if your
> backing bean implements ViewController -- stick it in the prerender()
> method. This approach certainly isn't harder than doing the same sort of
> thing in Struts 1.x.
>
> Regarding conversion of request parameters to model data types, Section *
> 5.3.1.2* <http://5.3.1.2/> of the JSF 1.1 spec discusses using managed
> properties to inject values into managed beans as they get created. It
> requires the same implicit conversions that JSP provides for the
> <jsp:setProperty> tag, so you're covered for things like Java primitives,
> but not for custom data types. That means you could use a value expression
> like "#{ param.personId} to pull out the personId request parameter, and
> assign it to a bean property of type int or long. However, dealing with
> conversion errors on unedited request parameters (it'll likely throw an
> exception) is probably not as user friendly as it really ought to be. I
> would tend to use string properties for that reason.
> *
> Adam Brod**
> Product Development Team*
>
>
> Craig
>
>
>
Re: JSF can handle GET requests *just as easily* as other frameworks
Posted by Adam Brod <AB...@intralinks.com>.
But in your example, personId is a primitive. What I really want is to
pass my own model objects from the List to the Detail page (without
post-backs). Would your example work if personId were a PersonIdentifier
object? What about other custom properties such as Enums,
EmailAddresses, etc? If so, then how? Does it invoke converters at
ManagedBean creation time?
Adam Brod
Product Development Team
"Craig McClanahan" <cr...@apache.org>
Sent by: craigmcc@gmail.com
04/14/2006 06:31 PM
Please respond to
"MyFaces Discussion" <us...@myfaces.apache.org>
To
"MyFaces Discussion" <us...@myfaces.apache.org>
cc
Subject
Re: JSF can handle GET requests *just as easily* as other frameworks
On 4/14/06, Adam Brod <AB...@intralinks.com> wrote:
Craig-
Thanks for your response. I understand that the existing Shale remoting
code wouldn't work, but as you wrote - the same principle could be
applied.
"However, dealing with conversion errors on unedited request
parameters (it'll likely throw an exception) is probably not as user
friendly as it really ought to be. "
Back to parameter mapping: since we are talking about request URLs, we
don't generally need to be concerned about user-friendly errors. A
malformed URL is a developer error in this case. In most cases, we'd
probably be "passing" the id from the person list to the person detail
page. (To be clear, I'm talking about using action-style urls just for
navigation, not for form submissions where we expect conversion errors. I
find that navigating from a list page to a detail page is too heavy-weight
using post-backs with potentially large datasets.)
As an added benefit, you can get bookmarkable URLs out of the deal too.
If the framework didn't do this and I were to use longs and Strings in my
managed bean properties, then I'd have to write code that creates the
model objects. In the exceptional case that the primitive managed
properties couldn't be converted, I would probably just throw an
exception. Exceptions are generally okay for developer errors that can be
fixed at development time. I'd rather the framework do this basic
conversion for me since it works great 90+% of the time. If I have a
special case that needs special error handling, I'll hand-code those few
cases (or use post-backs).
Does that make sense?
Yep, that makes sense. Indeed, JSF today does what you want already.
Here's a pattern I've used that makes life pretty easy:
<managed-bean>
<managed-bean-name>backing</managed-bean-name>
<managed-bean-class>com.foo.BackingBean</managed-bean-class>
<managed-property>
<property-name>personId</property-name>
<value>#{param.personId}</value>
</managed-property>
</managed-bean>
with a backing bean like this:
public class BackingBean implements ViewController {
private int personId;
public int getPersonId() { return this.personId; }
public void setPersonId(int personId) { this.personId = personId;
}
...
public void prerender() {
// By the time you get here, personId has aready
// been converted and injected, so use it to go look
// up the relevant information
}
}
No muss ... no fuss ... if you're willing to have the exception thrown on
a conversion error.
Adam Brod
Product Development Team
Craig
"Craig McClanahan" <cr...@apache.org>
Sent by: craigmcc@gmail.com
04/14/2006 05:42 PM
Please respond to
"MyFaces Discussion" <us...@myfaces.apache.org>
To
"MyFaces Discussion" <us...@myfaces.apache.org>
cc
Subject
Re: JSF can handle GET requests *just as easily* as other frameworks
On 4/14/06, Adam Brod < ABrod@intralinks.com> wrote:
If you wanted a GET to execute an action (and pass parameters), why not
adapt Shale's url convention /[managedBeanName]/[actionMethod] (for
example: /documentController/documentID?id=1234)?
This capability was specifically designed for being the back end of AJAX
style requests, but it works quite nicely for bookmarkable URLs too.
However ...
That would enable GET requests to go through the NavigationHandler and
have even more of the JSF framework goodness.
You don't get this out of the box with the current implementation in
Shale. That's because, from a JSF lifecycle point of view, Shale's phase
listener fires after Restore View -- and it will do this:
* Determine that the URL matches one of the patterns it is configured
to watch for (/dynamic/* by default)
* Execute the corresponding method via a programmatic method
binding call. As a side effect, this might trigger managed bean
creation of the bean instance containing this method.
* Expect that the method has created the entire response, so it
calls FaceContext.responseComplete() and returns.
As you can see, we never actually entered Invoke Application phase, we
never pay attention to anything that the invoked method returns (indeed,
the expected method signature is "public void methodname()"), and we never
invoke the navigation handler.
That's not saying you couldn't configure a Processor that does that sort
of thing -- its just that the default one doesn't.
For a use case like a bookmarkable URL, I tend to take a different
approach, because of what JSF's lifecycle will do for you anyway -- if
Restore View detects that there is no view state to restore, it jumps
immediately to Render Response phase. If you can interpose some
processing logic that happens right before rendering, and hav that logic
pull out the request parameters you need (or let JSF inject them via the
managed properties stuff), then it is very straightforward to process GET
requests. Shale even gives you a very easy place to put this kind of
logic, if your backing bean implements ViewController -- stick it in the
prerender() method. This approach certainly isn't harder than doing the
same sort of thing in Struts 1.x.
Regarding conversion of request parameters to model data types, Section
5.3.1.2 of the JSF 1.1 spec discusses using managed properties to inject
values into managed beans as they get created. It requires the same
implicit conversions that JSP provides for the <jsp:setProperty> tag, so
you're covered for things like Java primitives, but not for custom data
types. That means you could use a value expression like "#{
param.personId} to pull out the personId request parameter, and assign it
to a bean property of type int or long. However, dealing with conversion
errors on unedited request parameters (it'll likely throw an exception) is
probably not as user friendly as it really ought to be. I would tend to
use string properties for that reason.
Adam Brod
Product Development Team
Craig
Re: JSF can handle GET requests *just as easily* as other frameworks
Posted by Craig McClanahan <cr...@apache.org>.
On 4/14/06, Adam Brod <AB...@intralinks.com> wrote:
>
>
> Craig-
>
> Thanks for your response. I understand that the existing Shale remoting
> code wouldn't work, but as you wrote - the same principle could be applied.
>
>
> "*However, dealing with conversion errors on unedited request
> parameters (it'll likely throw an exception) is probably not as user
> friendly as it really ought to be*. "
>
> Back to parameter mapping: since we are talking about request URLs, we
> don't generally need to be concerned about user-friendly errors. A
> malformed URL is a developer error in this case. In most cases, we'd
> probably be "passing" the id from the person list to the person detail page.
> (To be clear, I'm talking about using action-style urls just for
> navigation, not for form submissions where we *expect* conversion errors.
> I find that navigating from a list page to a detail page is too
> heavy-weight using post-backs with potentially large datasets.)
>
As an added benefit, you can get bookmarkable URLs out of the deal too.
If the framework didn't do this and I were to use longs and Strings in my
> managed bean properties, then I'd have to write code that creates the model
> objects. In the exceptional case that the primitive managed properties
> couldn't be converted, I would probably just throw an exception. Exceptions
> are generally okay for developer errors that can be fixed at development
> time. I'd rather the framework do this basic conversion for me since it
> works great 90+% of the time. If I have a special case that needs special
> error handling, I'll hand-code those few cases (or use post-backs).
>
> Does that make sense?
>
Yep, that makes sense. Indeed, JSF today does what you want already.
Here's a pattern I've used that makes life pretty easy:
<managed-bean>
<managed-bean-name>backing</managed-bean-name>
<managed-bean-class>com.foo.BackingBean</managed-bean-class>
<managed-property>
<property-name>personId</property-name>
<value>#{param.personId}</value>
</managed-property>
</managed-bean>
with a backing bean like this:
public class BackingBean implements ViewController {
private int personId;
public int getPersonId() { return this.personId; }
public void setPersonId(int personId) { this.personId = personId; }
...
public void prerender() {
// By the time you get here, personId has aready
// been converted and injected, so use it to go look
// up the relevant information
}
}
No muss ... no fuss ... if you're willing to have the exception thrown on a
conversion error.
* Adam Brod**
> Product Development Team*
>
Craig
*"Craig McClanahan" <cr...@apache.org>*
> Sent by: craigmcc@gmail.com
>
> 04/14/2006 05:42 PM
> Please respond to
> "MyFaces Discussion" <us...@myfaces.apache.org>
>
> To
> "MyFaces Discussion" <us...@myfaces.apache.org> cc
>
> Subject
> Re: JSF can handle GET requests *just as easily* as other frameworks
>
>
>
>
>
>
>
>
> On 4/14/06, *Adam Brod* <*ABrod@intralinks.com* <AB...@intralinks.com>>
> wrote:
>
> If you wanted a GET to execute an action (and pass parameters), why not
> adapt Shale's url convention /[managedBeanName]/[actionMethod] (for example:
> /documentController/documentID?id=1234)?
>
> This capability was specifically designed for being the back end of AJAX
> style requests, but it works quite nicely for bookmarkable URLs too.
> However ...
>
> That would enable GET requests to go through the NavigationHandler and
> have even more of the JSF framework goodness.
>
> You don't get this out of the box with the current implementation in
> Shale. That's because, from a JSF lifecycle point of view, Shale's phase
> listener fires after Restore View -- and it will do this:
>
> * Determine that the URL matches one of the patterns it is configured
> to watch for (/dynamic/* by default)
>
> * Execute the corresponding method via a programmatic method
> binding call. As a side effect, this might trigger managed bean
> creation of the bean instance containing this method.
>
> * Expect that the method has created the entire response, so it
> calls FaceContext.responseComplete() and returns.
>
> As you can see, we never actually entered Invoke Application phase, we
> never pay attention to anything that the invoked method returns (indeed, the
> expected method signature is "public void methodname()"), and we never
> invoke the navigation handler.
>
> That's not saying you couldn't configure a Processor that does that sort
> of thing -- its just that the default one doesn't.
>
> For a use case like a bookmarkable URL, I tend to take a different
> approach, because of what JSF's lifecycle will do for you anyway -- if
> Restore View detects that there is no view state to restore, it jumps
> immediately to Render Response phase. If you can interpose some processing
> logic that happens right before rendering, and hav that logic pull out the
> request parameters you need (or let JSF inject them via the managed
> properties stuff), then it is very straightforward to process GET requests.
> Shale even gives you a very easy place to put this kind of logic, if your
> backing bean implements ViewController -- stick it in the prerender()
> method. This approach certainly isn't harder than doing the same sort of
> thing in Struts 1.x.
>
> Regarding conversion of request parameters to model data types, Section *
> 5.3.1.2* <http://5.3.1.2/> of the JSF 1.1 spec discusses using managed
> properties to inject values into managed beans as they get created. It
> requires the same implicit conversions that JSP provides for the
> <jsp:setProperty> tag, so you're covered for things like Java primitives,
> but not for custom data types. That means you could use a value expression
> like "#{ param.personId} to pull out the personId request parameter, and
> assign it to a bean property of type int or long. However, dealing with
> conversion errors on unedited request parameters (it'll likely throw an
> exception) is probably not as user friendly as it really ought to be. I
> would tend to use string properties for that reason.
>
> *Adam Brod**
> Product Development Team*
>
>
> Craig
>
>
Re: JSF can handle GET requests *just as easily* as other frameworks
Posted by Adam Brod <AB...@intralinks.com>.
Craig-
Thanks for your response. I understand that the existing Shale remoting
code wouldn't work, but as you wrote - the same principle could be
applied.
"However, dealing with conversion errors on unedited request
parameters (it'll likely throw an exception) is probably not as user
friendly as it really ought to be. "
Back to parameter mapping: since we are talking about request URLs, we
don't generally need to be concerned about user-friendly errors. A
malformed URL is a developer error in this case. In most cases, we'd
probably be "passing" the id from the person list to the person detail
page. (To be clear, I'm talking about using action-style urls just for
navigation, not for form submissions where we expect conversion errors. I
find that navigating from a list page to a detail page is too heavy-weight
using post-backs with potentially large datasets.)
If the framework didn't do this and I were to use longs and Strings in my
managed bean properties, then I'd have to write code that creates the
model objects. In the exceptional case that the primitive managed
properties couldn't be converted, I would probably just throw an
exception. Exceptions are generally okay for developer errors that can be
fixed at development time. I'd rather the framework do this basic
conversion for me since it works great 90+% of the time. If I have a
special case that needs special error handling, I'll hand-code those few
cases (or use post-backs).
Does that make sense?
Adam Brod
Product Development Team
"Craig McClanahan" <cr...@apache.org>
Sent by: craigmcc@gmail.com
04/14/2006 05:42 PM
Please respond to
"MyFaces Discussion" <us...@myfaces.apache.org>
To
"MyFaces Discussion" <us...@myfaces.apache.org>
cc
Subject
Re: JSF can handle GET requests *just as easily* as other frameworks
On 4/14/06, Adam Brod <AB...@intralinks.com> wrote:
If you wanted a GET to execute an action (and pass parameters), why not
adapt Shale's url convention /[managedBeanName]/[actionMethod] (for
example: /documentController/documentID?id=1234)?
This capability was specifically designed for being the back end of AJAX
style requests, but it works quite nicely for bookmarkable URLs too.
However ...
That would enable GET requests to go through the NavigationHandler and
have even more of the JSF framework goodness.
You don't get this out of the box with the current implementation in
Shale. That's because, from a JSF lifecycle point of view, Shale's phase
listener fires after Restore View -- and it will do this:
* Determine that the URL matches one of the patterns it is configured
to watch for (/dynamic/* by default)
* Execute the corresponding method via a programmatic method
binding call. As a side effect, this might trigger managed bean
creation of the bean instance containing this method.
* Expect that the method has created the entire response, so it
calls FaceContext.responseComplete() and returns.
As you can see, we never actually entered Invoke Application phase, we
never pay attention to anything that the invoked method returns (indeed,
the expected method signature is "public void methodname()"), and we never
invoke the navigation handler.
That's not saying you couldn't configure a Processor that does that sort
of thing -- its just that the default one doesn't.
For a use case like a bookmarkable URL, I tend to take a different
approach, because of what JSF's lifecycle will do for you anyway -- if
Restore View detects that there is no view state to restore, it jumps
immediately to Render Response phase. If you can interpose some
processing logic that happens right before rendering, and hav that logic
pull out the request parameters you need (or let JSF inject them via the
managed properties stuff), then it is very straightforward to process GET
requests. Shale even gives you a very easy place to put this kind of
logic, if your backing bean implements ViewController -- stick it in the
prerender() method. This approach certainly isn't harder than doing the
same sort of thing in Struts 1.x.
Regarding conversion of request parameters to model data types, Section
5.3.1.2 of the JSF 1.1 spec discusses using managed properties to inject
values into managed beans as they get created. It requires the same
implicit conversions that JSP provides for the <jsp:setProperty> tag, so
you're covered for things like Java primitives, but not for custom data
types. That means you could use a value expression like "#{
param.personId} to pull out the personId request parameter, and assign it
to a bean property of type int or long. However, dealing with conversion
errors on unedited request parameters (it'll likely throw an exception) is
probably not as user friendly as it really ought to be. I would tend to
use string properties for that reason.
Adam Brod
Product Development Team
Craig
Re: JSF can handle GET requests *just as easily* as other frameworks
Posted by Craig McClanahan <cr...@apache.org>.
On 4/14/06, Adam Brod <AB...@intralinks.com> wrote:
>
>
> If you wanted a GET to execute an action (and pass parameters), why not
> adapt Shale's url convention /[managedBeanName]/[actionMethod] (for example:
> /documentController/documentID?id=1234)?
>
This capability was specifically designed for being the back end of AJAX
style requests, but it works quite nicely for bookmarkable URLs too.
However ...
That would enable GET requests to go through the NavigationHandler and have
> even more of the JSF framework goodness.
>
You don't get this out of the box with the current implementation in Shale.
That's because, from a JSF lifecycle point of view, Shale's phase listener
fires after Restore View -- and it will do this:
* Determine that the URL matches one of the patterns it is configured
to watch for (/dynamic/* by default)
* Execute the corresponding method via a programmatic method
binding call. As a side effect, this might trigger managed bean
creation of the bean instance containing this method.
* Expect that the method has created the entire response, so it
calls FaceContext.responseComplete() and returns.
As you can see, we never actually entered Invoke Application phase, we never
pay attention to anything that the invoked method returns (indeed, the
expected method signature is "public void methodname()"), and we never
invoke the navigation handler.
That's not saying you couldn't configure a Processor that does that sort of
thing -- its just that the default one doesn't.
For a use case like a bookmarkable URL, I tend to take a different approach,
because of what JSF's lifecycle will do for you anyway -- if Restore View
detects that there is no view state to restore, it jumps immediately to
Render Response phase. If you can interpose some processing logic that
happens right before rendering, and hav that logic pull out the request
parameters you need (or let JSF inject them via the managed properties
stuff), then it is very straightforward to process GET requests. Shale even
gives you a very easy place to put this kind of logic, if your backing bean
implements ViewController -- stick it in the prerender() method. This
approach certainly isn't harder than doing the same sort of thing in Struts
1.x.
Regarding conversion of request parameters to model data types, Section
5.3.1.2 of the JSF 1.1 spec discusses using managed properties to inject
values into managed beans as they get created. It requires the same
implicit conversions that JSP provides for the <jsp:setProperty> tag, so
you're covered for things like Java primitives, but not for custom data
types. That means you could use a value expression like "#{param.personId}
to pull out the personId request parameter, and assign it to a bean property
of type int or long. However, dealing with conversion errors on unedited
request parameters (it'll likely throw an exception) is probably not as user
friendly as it really ought to be. I would tend to use string properties
for that reason.
* Adam Brod**
> Product Development Team*
>
Craig
Re: JSF can handle GET requests *just as easily* as other frameworks
Posted by Adam Brod <AB...@intralinks.com>.
Hubert-
Sorry I didn't clarify my idea better. It was a general idea for a JSF
extension, not something that will help you in the near-term.
Using GET requests you can't get 100% of the JSF framework goodness. Adam
W. pointed out that you don't get to use the Navigation framework if your
URL hard-codes the destination page. So my proposal would enable GET
requests to use the navigation framework. But it would require some
effort to implement.
Adam Brod
Product Development Team
"Hubert Rabago" <hr...@gmail.com>
04/14/2006 05:00 PM
Please respond to
"MyFaces Discussion" <us...@myfaces.apache.org>
To
"MyFaces Discussion" <us...@myfaces.apache.org>
cc
Subject
Re: JSF can handle GET requests *just as easily* as other frameworks
Adam,
Was this for me? I'm sorry, I can never tell because there's no
context. If it is, then yes, I know about the NonFacesRequestServlet
[1], and Shale's remoting support [2]. Both of those of course build
on the framework. I posed the question based on Jacob's statement
that seem to imply that such functionality is already supported by
JSF, and the perception that it isn't is a myth. I actually worked on
something that builds on NFRS and I thought of offering it to Craig
for Shale but I don't think the way I implemented it jives with his
vision for Shale or his vision of how JSF should be utilized. IOW,
the way I did it might not be The JSF Way, so I'm just keeping it to
myself for now.
Hubert
[1] http://wiki.apache.org/myfaces/InvokingJsfPagesWithStandardUrls
[2]
http://struts.apache.org/struts-shale/shale-remoting/apidocs/org/apache/shale/remoting/package-summary.html#package_description
On 4/14/06, Adam Brod <AB...@intralinks.com> wrote:
>
> If you wanted a GET to execute an action (and pass parameters), why not
> adapt Shale's url convention
> /[managedBeanName]/[actionMethod] (for example:
> /documentController/documentID?id=1234)? That would enable
> GET requests to go through the NavigationHandler and have even more of
the
> JSF framework goodness.
>
>
> Adam Brod
> Product Development Team
>
Re: JSF can handle GET requests *just as easily* as other frameworks
Posted by Hubert Rabago <hr...@gmail.com>.
Adam,
Was this for me? I'm sorry, I can never tell because there's no
context. If it is, then yes, I know about the NonFacesRequestServlet
[1], and Shale's remoting support [2]. Both of those of course build
on the framework. I posed the question based on Jacob's statement
that seem to imply that such functionality is already supported by
JSF, and the perception that it isn't is a myth. I actually worked on
something that builds on NFRS and I thought of offering it to Craig
for Shale but I don't think the way I implemented it jives with his
vision for Shale or his vision of how JSF should be utilized. IOW,
the way I did it might not be The JSF Way, so I'm just keeping it to
myself for now.
Hubert
[1] http://wiki.apache.org/myfaces/InvokingJsfPagesWithStandardUrls
[2] http://struts.apache.org/struts-shale/shale-remoting/apidocs/org/apache/shale/remoting/package-summary.html#package_description
On 4/14/06, Adam Brod <AB...@intralinks.com> wrote:
>
> If you wanted a GET to execute an action (and pass parameters), why not
> adapt Shale's url convention
> /[managedBeanName]/[actionMethod] (for example:
> /documentController/documentID?id=1234)? That would enable
> GET requests to go through the NavigationHandler and have even more of the
> JSF framework goodness.
>
>
> Adam Brod
> Product Development Team
>
Re: JSF can handle GET requests *just as easily* as other frameworks
Posted by Adam Brod <AB...@intralinks.com>.
If you wanted a GET to execute an action (and pass parameters), why not
adapt Shale's url convention /[managedBeanName]/[actionMethod] (for
example: /documentController/documentID?id=1234)? That would enable GET
requests to go through the NavigationHandler and have even more of the JSF
framework goodness.
Adam Brod
Product Development Team
Re: JSF can handle GET requests *just as easily* as other frameworks
Posted by Andrew Robinson <an...@gmail.com>.
The large difference I saw with using get requests for JSF and using
the "InvokingJsfPagesWithStandardUrls" is the fact that the WIKI
example actually executes an action. If you don't want an action to
execute, then there is no reason to have to do anything special for a
GET request. In fact, if you use my onload component from jsf-comp,
you can have an action executed on load of a page using a GET request
without any special servlet.
With Seam in fact, there is a @RequestParameter annotation that will
help with this, automatically injecting a request parameter string
value into a string member variable in a backing-bean. Then, to
support both GET and POST operations, you can use a parameter on your
command:
<t:commandLink>
<f:param name="documentId" value="#{mybean.documentid}" />
</t:commandLink>
then, in your bean, have:
@Name("mybean")
@Scope(ScopeType.EVENT)
public class MyBean {
@RequestParameter
private String documentid;
public String onload()
{
// load your document here from the ID
}
Then in your onload-config.xml, have #{mybean.onload} fired when you
page that needs the document is loaded.
-Andrew
On 4/14/06, Adam Winer <aw...@gmail.com> wrote:
> Adam,
>
> That's solved straightforwardly with indirection, so that
> you have, say, a DocumentProviderBean with get/setId() and
> getDocument() on it, and getDocument() has the code to handle
> converting the ID into an appropriate object - presumably with a
> trivial call to your DAO layer. The request parameter goes
> to the DocumentProviderBean, and your page gets the document
> out of the document provider.
>
> Do other frameworks make this pattern significantly simpler?
> If so, how?
>
> -- Adam
>
>
>
>
>
> On 4/14/06, Adam Brod <AB...@intralinks.com> wrote:
> >
> > Hey Adam-
> >
> > The most common type of GET requests I've had trouble with in JSF is binding
> > request parameters to complex managed bean parameters.
> >
> > For (a simple) example, say I have a link
> > /faces/vewDocument.xhtml?documentID=1234.
> > viewDocument.xhtml has a backing bean ("documentController") with a managed
> > property named "documentID" and value "#{params.documentID}".
> > DocumentController.setDocumentID() takes a
> > DocumentIdentifier object, not a primitive.
> >
> > Can JSF convert the request parameter to an object even though the request
> > goes directly to the render phase? Will a Converter work or will JSF
> > auto-wire this since it can see that the target setDocumentID(...) method
> > takes a parameter of type DocumentIdentifier?
> >
> > Thanks for your input.
> >
> > Adam Brod
> > Product Development Team
> >
>
Re: JSF can handle GET requests *just as easily* as other frameworks
Posted by Adam Brod <AB...@intralinks.com>.
Adam-
I don't think your response is quite what I was getting at. In Struts
world, I have lots of ugly code sprinkled everywhere that converts request
params to very low-level custom objects in our system (for example, Enums
for statuses, types, and flags as well as other objects like Identifiers,
Credit Card Numbers, EmailAddresses, etc.), When using JSF post-backs, we
can use Converters to handle all that boiler-plate request param -> object
mapping. If using JSF with GET requests, we cannot use converters, can
we?
If my understanding is correct, that is a definitely limitation of using
GET with JSF.
Adam Brod
Product Development Team
"Adam Winer" <aw...@gmail.com>
04/14/2006 04:23 PM
Please respond to
"MyFaces Discussion" <us...@myfaces.apache.org>
To
"MyFaces Discussion" <us...@myfaces.apache.org>
cc
Subject
Re: JSF can handle GET requests *just as easily* as other frameworks
Adam,
That's solved straightforwardly with indirection, so that
you have, say, a DocumentProviderBean with get/setId() and
getDocument() on it, and getDocument() has the code to handle
converting the ID into an appropriate object - presumably with a
trivial call to your DAO layer. The request parameter goes
to the DocumentProviderBean, and your page gets the document
out of the document provider.
Do other frameworks make this pattern significantly simpler?
If so, how?
-- Adam
On 4/14/06, Adam Brod <AB...@intralinks.com> wrote:
>
> Hey Adam-
>
> The most common type of GET requests I've had trouble with in JSF is
binding
> request parameters to complex managed bean parameters.
>
> For (a simple) example, say I have a link
> /faces/vewDocument.xhtml?documentID=1234.
> viewDocument.xhtml has a backing bean ("documentController") with a
managed
> property named "documentID" and value "#{params.documentID}".
> DocumentController.setDocumentID() takes a
> DocumentIdentifier object, not a primitive.
>
> Can JSF convert the request parameter to an object even though the
request
> goes directly to the render phase? Will a Converter work or will JSF
> auto-wire this since it can see that the target setDocumentID(...)
method
> takes a parameter of type DocumentIdentifier?
>
> Thanks for your input.
>
> Adam Brod
> Product Development Team
>
Re: JSF can handle GET requests *just as easily* as other frameworks
Posted by Adam Winer <aw...@gmail.com>.
Adam,
That's solved straightforwardly with indirection, so that
you have, say, a DocumentProviderBean with get/setId() and
getDocument() on it, and getDocument() has the code to handle
converting the ID into an appropriate object - presumably with a
trivial call to your DAO layer. The request parameter goes
to the DocumentProviderBean, and your page gets the document
out of the document provider.
Do other frameworks make this pattern significantly simpler?
If so, how?
-- Adam
On 4/14/06, Adam Brod <AB...@intralinks.com> wrote:
>
> Hey Adam-
>
> The most common type of GET requests I've had trouble with in JSF is binding
> request parameters to complex managed bean parameters.
>
> For (a simple) example, say I have a link
> /faces/vewDocument.xhtml?documentID=1234.
> viewDocument.xhtml has a backing bean ("documentController") with a managed
> property named "documentID" and value "#{params.documentID}".
> DocumentController.setDocumentID() takes a
> DocumentIdentifier object, not a primitive.
>
> Can JSF convert the request parameter to an object even though the request
> goes directly to the render phase? Will a Converter work or will JSF
> auto-wire this since it can see that the target setDocumentID(...) method
> takes a parameter of type DocumentIdentifier?
>
> Thanks for your input.
>
> Adam Brod
> Product Development Team
>
Re: JSF can handle GET requests *just as easily* as other frameworks
Posted by Adam Brod <AB...@intralinks.com>.
Hey Adam-
The most common type of GET requests I've had trouble with in JSF is
binding request parameters to complex managed bean parameters.
For (a simple) example, say I have a link
/faces/vewDocument.xhtml?documentID=1234. viewDocument.xhtml has a
backing bean ("documentController") with a managed property named
"documentID" and value "#{params.documentID}".
DocumentController.setDocumentID() takes a DocumentIdentifier object, not
a primitive.
Can JSF convert the request parameter to an object even though the request
goes directly to the render phase? Will a Converter work or will JSF
auto-wire this since it can see that the target setDocumentID(...) method
takes a parameter of type DocumentIdentifier?
Thanks for your input.
Adam Brod
Product Development Team
Re: JSF can handle GET requests *just as easily* as other frameworks
Posted by Adam Winer <aw...@gmail.com>.
Mike,
What do you mean by "not supported in the core"?
A GET request turns into an initial render request - no
phases other than Render Response - but Jacob's entirely
correct that JSF *does* support GET, and you can funnel
request parameters directly into your managed beans.
This is definitely supported by the core, required by the
spec, etc. No theory here.
I guess my question is - what else do you want out of a GET
request? What specifically is supported "in theory", but not
in practice? I can imagine things, but I'm curious what you're
after.
-- Adam
On 4/13/06, Mike Kienenberger <mk...@gmail.com> wrote:
> On 4/13/06, Hubert Rabago <hr...@gmail.com> wrote:
> > Jacob Hookom, in discussing JSF myths [1], claims that:
> >
> > "Also, JSF can handle GET requests just as easily as other frameworks.
> >
> > Is there any truth to this? I thought the reason we had extensions
> > like NonFacesRequestServlet [2] was because this wasn't supported by
> > the core functionality?
> >
> > [1] http://virtuas.com/articles/webframework-sweetspots.html
> > [2] http://wiki.apache.org/myfaces/InvokingJsfPagesWithStandardUrls
>
> Depends on your definition of "just as easily". It's not supported
> by default in core. Probably you should read it as "just as easily
> in theory".
>
Re: JSF can handle GET requests *just as easily* as other frameworks
Posted by Mike Kienenberger <mk...@gmail.com>.
On 4/13/06, Hubert Rabago <hr...@gmail.com> wrote:
> Jacob Hookom, in discussing JSF myths [1], claims that:
>
> "Also, JSF can handle GET requests just as easily as other frameworks.
>
> Is there any truth to this? I thought the reason we had extensions
> like NonFacesRequestServlet [2] was because this wasn't supported by
> the core functionality?
>
> [1] http://virtuas.com/articles/webframework-sweetspots.html
> [2] http://wiki.apache.org/myfaces/InvokingJsfPagesWithStandardUrls
Depends on your definition of "just as easily". It's not supported
by default in core. Probably you should read it as "just as easily
in theory".