So do I
Sverker Abrahamsson wrote:
HiT
his is now more a conceptual discussion about JSF than specifically
about MyFaces. As I understand it the scope of JSF was to make an
application frontend framework which is not tied to http/html. In many
aspects it does a good work, providing flexibility with it's rich
event model and good separation of business logic and presentation. I
like those parts a lot.
However, it claims to be a framework for building web based
applications, which means using HTTP for transport and HTML/ECMAScript
for presentation (weather it's generated by jsp, xml+xslt or
whatever). These are not perfect protocols, when they were designed
nobody imagined they would have such inpact, but over the years people
have been able to use these tools to make web-based applications with
good usability.
For doing so a number of common use cases or design patterns has
evolved, normally GET is used when "reading" the state from the web
application and POST is used when updating persistant state in the
app. Of course there are variants where POST is used for other
purposes but the most important is to be able to choose the method
most suitable for the use case. I would say that GET requests are used
in 99.99% of the cases (or more).
Some pros about using GET over POST is that the resulting page is
bookmarkable, it is possible to refer to it with an url and in most
cases it's possible to use the browser back and forward buttons to
navigate. Of course the application has to be designed with that in
mind so that going back and forth in the application, or jumping right
into it doesn't break anything but that's not so difficult. The
mechanism for using GET requests in a web application is to encode the
parameters in a query string in the url, it works best for reading the
state of the application but can be used for submitting simple forms
if care is taken that it does not break anything if the user use the
back/forward button. POST is only better to use when submitting bigger
forms or when
Craig asked why people insist on using GET and constructing direct
url's and the simple answer is that it is neccesary to get e.g.
addressability like the the examples below shows:
"Hi, Craig. I found this interesting book on Amazon. Take a look at
it on
http://www.amazon.com/exec/obidos/tg/detail/-/0131463055/qid=1125490932/sr=8-1/ref=pd_bbs_1/102-6998912-0718528?v=glance&s=books&n=507846
<http://www.amazon.com/exec/obidos/tg/detail/-/0131463055/qid=1125490932/sr=8-1/ref=pd_bbs_1/102-6998912-0718528?v=glance&s=books&n=507846>"
"The JCP page for JSF 1.2 can be found at
http://www.jcp.org/en/jsr/detail?id=252";
"You can see the status of your UPS shipment on
http://wwwapps.ups.com/WebTracking/processInputRequest?HTMLVersion=5.0&sort_by=status&tracknums_displayed=5&TypeOfInquiryNumber=T&loc=en_SE&InquiryNumber1=1Z9999999999999999&InquiryNumber2=&InquiryNumber3=&InquiryNumber4=&InquiryNumber5=&AgreeToTermsAndConditions=yes&track.x=33&track.y=9
<http://wwwapps.ups.com/WebTracking/processInputRequest?HTMLVersion=5.0&sort_by=status&tracknums_displayed=5&TypeOfInquiryNumber=T&loc=en_SE&InquiryNumber1=1Z9999999999999999&InquiryNumber2=&InquiryNumber3=&InquiryNumber4=&InquiryNumber5=&AgreeToTermsAndConditions=yes&track.x=33&track.y=9>"
These are just some examples, it's not possible to accomplish the same
with POST. I can't refer to the result of a POST request with an URL.
When designing a web-based application, the most important aspects are
usability, scalability and maintainability. Usability definitly comes
first, if it is poor nobody will use it (especially not if some
competitor can provide the same functionality with better usability).
There are tons of examples where projects have failed because of poor
usability.
That is the reality for people developing real applications for the
real world. From time to time it appears academic work which in teory
seams very nice but lack the connection to reality. Take e.g. the EJB
spec as example, 1.x entity beans was not really usable, 2.x
was better but not good. There was ideas about components which was
assambled into applications, I don't know about anybody who used that
functionality. Instead people started using xdoclets to generate those
descriptor xml files. In parallell Hibernate emerged which was much
better in sync with reality. We see the result now, EJB is essencially
adopting to Hibernate model for persistence.
Another example from a compleatly other domain; Voice over IP. When
SIP and RTP was designed for VoIP it was not taken into account the
use case where many users are behind NAT firewalls. I read the
discussions and a big reason was that the authors thought NAT is bad
and ugly (and that it was difficult to solve the problem). That
resulted in that it took many years for VoIP to take off, it wasn't
until some way for SIP telephony to get through the NAT firewall was
developed that it became usable for the common user. Skype took
another way, from the beginning it was able to get through the NAT
firewalls and it took off skyrocket wise because it was so much easier
to use it.
When the JSF spec say that only HTTP POST I say it is out of sync with
reality since it does not support the common usecases. I think that
the error in thinking is that every form submission updates persistent
state in the server which doesn't neccesarily have to be true. The
form submission can just as well be for submitting a query, like e.g.
at Google. I don't change any persistent state when I submit their
search form.
W3C has a quite good text of when to use GET and when to use POST at
http://www.w3.org/2001/tag/doc/whenToUseGet.html, which is not
followed by JSF.
In my humble opinion JSF is seriously flawed when not being able to
support the common usecases. When developing an application I would
need to combine it with Struts or Spring for the queries and only be
able to use JSF for a few components where POST is appropriate.
A framework for building web-based applications must be able to cover
all common design patterns for web application, the limitation must
not be in the framework. That people have to make hacks to get around
limitations (like Mirek Novak's example, nice one Mirek) is a clear
sign that something is broken.
Additionally, I don't see any conflict on having JSF support for GET
as well as post. There is no need to "throw away nearly the entire JSF
lifecycle", just pick up the form fields from the query string and
carry on. Applications are able to keep the state today by using the
HttpSession and there is no reason why JSF couldn't do the same. Then
of course the application developer must choose carefully which method
is most suitable to use for the different use cases in his application
but it is point is that he must be free to do so. The framework should
not put limitations which are not neccesary.
JSF should be able to support GET forms, it should contain some tag
for constructing url's something like the navigation tag Mirek
suggested and the url's should be as nice as possibly. I'm considering
to make a proof-of-concept based on MyFaces to prove that it is
possible and works fine without violating anything fundamental of the
JSF idea, if there is anyone else on the list who thinks it's a good
idea. Otherwise I'll just go back to using Struts or Spring but I
don't think JSF will be successful without support for HTTP GET.
Keeping the state as hidden fields on the client side is a bit strange
for me, especially since it can easily be a lot of data in some apps,
but since it's not mandatory I don't object to it. Flexibility is
good, there might be some use cases where it's better to keep the
state on client side. What I would like to see however is something
which is between Request and Session scope, like that I could define a
group of pages/actions which keep state as long as I remain on one of
them but loose it when I navigate away from them. That is to avoid to
have to keep a lot of obsolete data in the Session just because I
needed it on more than one page. Should be fairly simple to implement.
Anyway, the only motivation I've seen for only supporting HTTP POST
seams to be religious, that HTTP GET is ugly, wrong and stupid and
that people who design such applications will grow hair on their palms.
As always, choose the right tools and protocols to solve the problem.
When choise is limited (e.g. we have to live with the limitations of
HTTP/HTML/ECMAScript at least until an alternative shows up) then make
best use of the possibilities. Don't make artificial limitations but
be flexible.
At least the spec should clearly state that if you want to use JSF to
implement the most common design patterns for web based applications
then this is not the tool to use. It took me quite some time to figure
this out as it's not clearly stated anyware and I couldn't believe
there was such a stupid limitation when the idea and the rest of the
design is so beautiful. I must say that I got very dissapointed.
/Sverker
----- Original Message -----
*From:* Craig McClanahan <mailto:[EMAIL PROTECTED]>
*To:* MyFaces Discussion <mailto:[email protected]>
*Sent:* Tuesday, August 30, 2005 9:05 PM
*Subject:* Re: url query string parameters as input to JSF action
- not possible??
On 8/30/05, *Rick Reumann* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
On 8/30/05, Mirek Novak <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
>
> We were quite satisfied with this solution. But in
situations where you
> have two or more parameters you would like to initialize
your bean
> explicitly after all the parameters have been set.
>
> So, we have:
> <s:parameters bindTo="#{itemBean}"
> clear="#{itemBean.clear}"
> init="#{ itemBean.init}">
> <s:parameter name="itemName"/>
> <s:parameter name="itemCategory"/>
> </s:parameters>
>
> We examinate (in encodeBegin) requestMap if it contains
"itemName" or
> "itemCategory". If this is the case, we will put this
parameters into a map
> and call: clear(); init(parameters);
But why doesn't JSF have an easy way to support this by default?
Why, out of curiousity, do you insist on getting your hands dirty
with low level HTTP protocol details like dynamically constructing
URL patterns? Why, out of curiousity, do you insist on using GET
queries (and thereby throw away nearly the entire JSF lifecycle)?
Let the application deal with application level things like
components (hidden or not as need be), not implementation
details. Like any other technology, JSF will be intuitive if you
use it the way it's intended -- and it won't be if you don't.
Rick Hightower in article claims that JSF is more intutive
than Struts
and, granted I'm new to JSF and experienced with Struts, but
yet I
still claim that is a false statement. I'll post more on my
findings
in another thread.
Isn't "more intuitive" semantically meaningless, if we all can't
even agree on what "intuitive" means? :-)
--
Rick
Craig
