|
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"
"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"
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.
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
|
