I've been trying to solve this, and have been getting stuck, so I thought I'd ask.
Imagine two ActionBeans, A and B.
A.jsp has this section in it:
...
<jsp:include page="/B.action">
<jsp:param name="ponies" value="on"/>
</jsp:include>
<jsp:include page="/B.action">
<jsp:param name="ponies" value="off"/>
</jsp:include>
...
Take it as read that the B ActionBean does some terribly interesting stuff depending on whether the "ponies" parameter is set to either on or off.
The parameter string "ponies=on" is visible when you debug into the request, but it's not what's getting bound into the B ActionBean. Instead what's getting bound are the parameters to the original A.action.
Is there some way of getting the behaviour I want, or have I missed something fundamental?
So are you saying that in each case ${ponies} on your JSP page prints out "on"?
Because it sounds like you are confusing JSP parameters with Stripes action beans. Setting a JSP parameter simply sets a parameter on that JSP page, that you can reference as shown above, it doesn't actually set anything on the stripes action bean.
The reason that this wasn't working was because of massaging done by our implementation of HttpServletRequest.
It works fine with the "normal" implementation.
Related
We just started to migrate an older jsf 1 project to jsf version 2.3 with new requirements. Currently I am working on pages that use viewparams. what would be the right way to silently ignore wrong parameter-types?
for example with this definition for page searchResults.xhtml:
<f:metadata>
<f:viewParam name="lastPrice"
value="#{ReportAgentBean.lastPrice}" converter="javax.faces.Double"/>
<f:viewParam name="currentPrice"
value="#{ReportAgentBean.currentPrice}" converter="javax.faces.Double"/>
<f:viewParam name="listPrice"
value="#{ReportAgentBean.listPrice}" converter="javax.faces.Double"/>
</f:metadata>
what would be the best approach to ignore invalid parameters or just handle them as null if someone fires a request like:
http://www.ourapp.com/reports/searchResults?lastPrice=undefined?currentPrice=INVALIDSTRING
which ideally would result in:
http://www.ourapp.com/reports/searchResults
thanks for any hint.
As far as I know, the default faces converters you use cannot accept/ignore invalid values passed to it and ignore them.
For this to work, you need to create your own custom converters, do the casting to the right type in there and if the casting is successful, return the cast value and if it fails, return some default.
This is what you'd normally do for more complex param/converter combinations where just the presence of an id would read a full complex object from somewhere
This whole concept is also used in the OmniFaces #Param annotation which might be an interesting solution to. They set the fields to null if conversion fails. See the demo on that page too.
I'm using Primefaces and I know that p:panelGrid extends h:panelGrid as it's clearly stated in the documentation.
However I can't see the exact difference between them. What extra functionalities does p:panelGrid provide? In which cases should I prefer using the Primefaces version over the HTML Basic one?
Although p:panelGrid extends h:panelGrid, it actually lacks many of the attributes that h:panelGrid contains. Which ultimately got me confused.
I can't speak for PrimeFaces' actual intention (I'm no PrimeFaces developer), but based on my observations so far, I can only conclude that they omitted attributes which only invite bad practices in HTML perspective (mainly HTML-deprecated attributes — use CSS instead) or makes no sense otherwise (and are better at its place in a parent or child component). I can only say that it's a Good Thing.
Upon further inspection in the source code I can also confirm that it doesn't technically extend from <h:panelGrid> (HtmlPanelGrid class), but from the UIPanel superclass (which is also used by a.o. <h:panelGroup>). This design decision is most likely done to have more flexibility in the rendered output as shown in the showcase.
Generally, you should only prefer an enhanced component whenever you start to actually need the enhanced/new feature. This usually only happens once you figure out you actually need such one feature and discover that it is missing in the standard component. You'd then usually already know the keywords you're looking for and simply start exploring the component libraries using those keywords if they haven't already implemented it.
I am working on something like this:
A JSF template has a side-navigation bar which contains links(either anchor or h:outputLink), and there are cases where two options lead to the same link(page), but with a different value in view parameter, and thus rendering different data being displayed on the page.
Is there a way to do this? Using commandLink or commandButton does not seem like an option to me since it will mess up the styling.
Thanks in advance.
An output link is just a normal HTML link, so a conventional way to do this is with a query parameter, e.g. /contentarea.xhtml?myparam=value.
I don't think you should bind a method to the output link. That would involve a Javascript onclick handler (commandLink), and I don't think that's necessary here. That said, I'm surprised you say commandLink messes with the styling, as it renders a normal HTML link.
See also
http://incepttechnologies.blogspot.ca/p/view-parameters-in-jsf-20.html (see the first technique using f:viewParam)
http://www.mkyong.com/jsf2/jsf-2-link-commandlink-and-outputlink-example/
I am trying to pass arguments to a managed bean.
The bean is configured and works, has two methods "getResponsible" and "setResponsible".
Calling "myLookup.responsible" works.
I cannot pass arguments to my bean, and can't figure out why.
The below code does not work.
<xp:comboBox id="comboBox1">
<xp:selectItems>
<xp:this.value><![CDATA[#{myLookup.setResponsible("Something")}]]>
</xp:this.value>
</xp:selectItems>
</xp:comboBox>
As soon as I type paranthesis ")", "(" or semicolon ";" i get error "Error in EL syntax". I guess I am making some fundamental mistake here.
The version of expression language does not allow parameters to easily be passed. This option may work http://blog.defrog.nl/2012/04/settings-bean-parameterized-method-call.html.
If parameters are required, I usually use SSJS, so:
#{javascript:myLookup.setResponsible("Something");
If the options won't vary during the page's life, you can always compute on page load, so:
${javascript:myLookup.setResponsible("Something");
I think you just made a simple "typo" as Paul stated indirectly in his reply. You wrote Javascript code but did not include the "javascript:" in the beginning of your expression.
If, however, you do want to use arguments with EL then have a look at this very interesting article. I haven't tried it out myself yet (but am going to do shortly) - but the two different examples (have a look at the comments) seem very interesting when you want to use EL. And I prefer EL over SSJS.
/John
I have got some interesting issue for you. I am creating a composite component. I know, that I can use ui:param for storing value and reuse it. But what if I store to this variable some relative value (#{component.namingContainer.clientId}) and want to reuse it as a constant? It is difficult to explain - here you have my code:
<ui:param name="rdfaComp" value="#{component.namingContainer.clientId}"/>
This is in the beginning of the page - I want to store exactly this ID and then use nothing else by this variable. But later if I reuse it inside elements with own IDs, it is bad. It is interesting, what happens - JSF doesn't take the same value, but a relative one. It reads once more #{component.namingContainer.clientId}, not the fixed value.
How to solve this, could you help me, please? THanks a lot.
UPDATED
There is still one important condition: the variable rdfaComp have to be available immediately, because I reuse it in a Javascript function (on the same page). Like this:
<h:commandButton onclick="return selectText('#{rdfaComp}:editor', ...
I am afraid, it is necessarry to use relative ID chains like this: #{component.namingContainer.parent.namingContainer.parent.clientId} etd.
But it is really awful. Is there another solution?
The <ui:param> indeed merely creates an alias and the EL expression is still deferred and evaluated on every access in the very same context as where it's been referenced (and thus not where it's been declared! that explains your concrete problem). Besides, the <ui:param> is designed to be used on <ui:include>, <ui:composition> and <ui:decorate> only.
Use <c:set> instead. It's capable of immediately evaluating an EL expression and storing its result in either request, view, session or application scope via the scope attribute.
<c:set var="rdfaComp" value="#{component.namingContainer.clientId}" scope="request" />
Update: you actually wanted to get the client ID of the composite component itself, here's how you can get it:
<c:set var="rdfaComp" value="#{cc.clientId}" scope="request" />
It is solved - and I must apologise once more :-). I didn't describe correctly the issue - what I really wanted to do. I just wanted to work with the full client ID of the composite component. Finally I found a solution: #{cc.namingContainer.clientId}
Thanks anyway, your answers were very helpful!