Re: url query string parameters as input to JSF action - not possible??

[Patrick Dalla Bernardina <pa...@jfes.trf2.gov.br>]

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 <ma...@gmail.com>
>     *To:* MyFaces Discussion <ma...@myfaces.apache.org>
>     *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* <rick.reumann@gmail.com
>     <ma...@gmail.com>> wrote:
>
>         On 8/30/05, Mirek Novak <miroslav.novak@gmail.com
>         <ma...@gmail.com>> 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
>