Hi,
we've come across the same problem. We have pages where e.g. only one
string parameter ("id") alters their behavior.
We've developed a component requestParameter and the page begins with:
<f:view>
<y:errorHandler errorPage="error.jsp"
cause="#{errorBean.cause}">
<y:requestParameter name="id"
bindTo=#{reportBean.reportId}/>
...
</y:errorHandler>
</f:view>
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);
So, a lot of our pages can be referenced by URIs like
localhost:8080/web/itemDetail.jsp?itemName=FerrariF50&itemCategory=SportCars
We have a philosophic problem now: How to navigate between pages? E.g. I would
like to go from the page that lists all "items" to the detail page.
We used command links:
<h:commandLink action="" >
<h:outputText value="#{item.name}" />
<x:updateActionListener property="#{requestScope.itemName}"
value="#{item.name}" />
<x:updateActionListener property="#{requestScope.itemCategory
value="#{item.category}" />
</h:commandLink>
method itemDetail() on the "listingBean" returned appropriate
navigation result like: "itemDetail" and MyFaces handled the
navigation
Now, we are using simple output links:
<h:outputLink value="detail.jsp">
<f:param name="itemName" value="#{item.name}" />
<f:param name="itemCategory" value="#{item.category}" />
</sh:outputLink>
The problem is that page name "detail.jsp" is mentioned directly in another page. However, this solution makes pages simple and testable - no _javascript_ - simple get request with "human readable" parameters.
MN.
What do you think about this solution?
On 8/28/05, Sverker Abrahamsson <[EMAIL PROTECTED]> wrote:HiI'm new to JSF so this may be a stupid question but I've been reading a lot of tutorials and parts of the spec and come to the conclusion that JSF only support forms with method="post". The only motivation for that I've seen is that its "unpure" to let a HTTP GET request change server state.Strictly follwing that means however that it's not possible to make url's that uses query string to send data directly into an JSF action, something which is very common today. I.e. look at the JCP site which uses url's like this: http://www.jcp.org/en/jsr/detail?id=252 (which leads to JSR 252 which is for JSF 1.2).Let me take another example, I have an application implemented using Struts where I use GET forms e.g. to specify query parameters for statistics. I use GET because 1) no persistent state is changed on the server and 2) I want the resulting page to have a URL I can e.g. send in a mail or bookmark. Most of the interaction in the application use GET forms, or dynamically built url's with form parameters encoded in the query string. POST is only used where persistant state is changed on the server.From what I've seen on the net this is the most common way to build a dynamic web application, just look at Sun's Javasite for lots of examples...Is it true that the JSF spec does not allow building such applications by strictly only allowing post forms? Either they got something wrong in their thinking or I've understood compleatly wrong..However, there seams to be light in the tunnel as when I read MyFaces sourcecode it seams that it treats GET and POST equal, picking up the request parameters in both cases. Also I see that the commandlink tag has a mode where it doesn't use _javascript_ but renders the parameters in a HTTP GET query string.So it should work to use MyFaces. What worries me is if this is an "accidential feature" (aka bug, since I haven't found it in any doc) in MyFaces, it might go away without warning and then my applications will break. If it is a deliberate feature, it breaks compatibility with other JSF implementations if I use it.If it's there to stay in MyFaces I can make an extension of the standard form tag to add a method attribute and it would work as in Struts, but I don't like to have to extend something to get base functionality. Too easy that things break sooner or later.I like JSF a lot for the rest, especially the components, so it would be a pitty if this small flaw would make it useless.I'm grateful for comments on the above, especially if I've misunderstood everything and should read page #4711 in the spec better./Sverker
