In the SpringMVC documentation I see this for AbstractView:
Direct Known Subclasses:
AbstractExcelView, AbstractFeedView,
AbstractJackson2View, AbstractJExcelView,
AbstractPdfView, AbstractUrlBasedView,
AbstractXlsView, MarshallingView
Which implementation handles regular JSP Views?
The reason for my question is that I want to extend SpringMVC's JSP View, to support a Read-Only mode for a form. The regular view would be the normal JSP, but a Read-Only View would be an extension of the JSP where all fields are converted to labels, i.e. they can't be modified.
Any advice on this approach appreciated.
What I understand is you need to get a JSF component root, iterate over all elements, find input fields and replace them with non-input - labels instead?
JSP does not 'like' modifying it's components at runtime. In JSF I could suggest you implement a TagHandler to modify the component tree based on some parameter returned in the View Model.
In your case - a simple solution would be to either disable inputs based on parameter value
<h:inputText value="${inputValue}" disabled="${formDisabled}" />
or render different inputs based on parameter value
<c:if test="${formDisabled}">
<div><h:outputText value="${inputValue}" />
</c:if>
<c:if test="${!formDisabled}">
<h:inputText value="${inputValue}" />
</c:if>
Related
I'm currently working on a Spring MVC project where we are migrating all our jsp files to thymeleaf. I'm aware that the spring form tag has an htmlEscape attribute that will escape user input when rendering, such as when the user submits an invalid form and the user input is rendered bound to the form. An example of this:
<form:form method="post" id="someForm" modelAttribute="${commandName}" htmlEscape="true" autocomplete="off">
<div class="form-group">
<input type="text" id="username" value="<c:out value='${inputValue}'/>"/>
<input type="password" id="password" />
<input type="submit" class="btn btn-lg btn-block-sm" value="<spring:message code="header.content.close"/>" tabindex="0" />
<input type="hidden" name="_eventId" value="continue"/>
</div>
</form:form>
This fits under the umbrella of output-escaping, which is something that happens on the server side when processing a template to render.
An example of an xss attack this prevents is if the user entered
<script>alert("gotcha");</script> for the username, and some arbitrary value for the password. The form will rerender with the entered username bound to the form. The htmlEscape="true" attribute in the form tag will cause this output to be escaped to mitigate xss. So the username field will contain <script>alert("gotcha");</script> when the bound form rerenders with the error, instead of the actually entered valid html
Is there a standard way to achieve this same functionality in thymeleaf?
A few possibilities I see:
This is already built into thymeleaf.
I'm aware that the spring thymeleaf package uses unbescape to perform output escaping on some attributes, for example SpringValueTagProcessor which I believe escapes output on th:value attributes. However, I'm not sure this is equivalent, and fear there may be security holes left unfilled if this was done in a way that only partially mitigates what the spring form htmlEscape fully mitigates.
If so, please explain how this covers the same cases that htmlEscape does.
There is an existing Spring / Spring MVC solution that is flexible enough to not rely on jsp.
If so, what?
There is a common solution to this for thymeleaf which involves some modification of the template parsing engine.
If so, please explain.
Here is a brief article to give you an idea of what I mean regarding the spring form behavior. Regarding this article, it appears that setting the defaultHtmlEscape to false globally in the web.xml only overrides the default value of HtmlEscapeTag, which appears to only work for spring tags. Thus I don't think the solution can be applied to thymeleaf.
I would appreciate any direction here.
Escaping of output text is done automatically if you use th:text. In rare cases, you can use th:utext if you want to use unescaped text, but you have to be aware of the security implications. See Process thymeleaf variable as html code and not text for some more info.
I ended up getting an answer on the GitHub discussions for the Thymeleaf project here, which I will summarize and clarify:
HTML escaping is built into Thymeleaf form elements by default.
This is evidenced by th:input processor source code. Note the use of getDisplayString which performs html output escaping via org.springframework.web.util.HtmlUtils
I went through and manually checked all the uses of getDisplayString where htmlEscape is false and can verify that in these cases, the output is HTML escaped before displaying (in the case of SpringErrorTagProcessor and SpringUErrorsTagProcessor), they don't output any content to escape (SpringSelectedValueComparator returns a boolean), or the expression is a bound object (SPELVariableExpressionEvaluator).
See GitHub issue thymeleaf/thymeleaf-docs#84 for information regarding the docs being updated accordingly.
Is there a way to ajax-update a specific component such as a <h:form> in backing bean?
I tried the following using RequestContext#execute(),
RequestContext context = RequestContext.getCurrentInstance();
context.execute("monitorVehicleForm.update()");
however that didn't seem to have any effect.
The RequestContext#execute() only executes arbitrary JavaScript code which is been passed-in as argument. It does not ajax-update the client representation of the components.
You need RequestContext#update() instead wherein you just pass the client ID of the to-be-updated component.
context.update("monitorVehicleForm");
This has exactly the same effect as <p:commandXxx ... update="monitorVehicleForm">. This works provided you've a
<h:form id="monitorVehicleForm">
without any NamingContainer parent and thus have a
<form id="monitorVehicleForm" name="monitorVehicleForm" ...>
in the generated HTML.
See also:
How to find out client ID of component for ajax update/render? Cannot find component with expression "foo" referenced from "bar"
Is it possible to update any html fragment using Primefaces selectors - PFS?
Consider this:
<h:outputText id="test" value="#{testBean.date}"/>
<span id="test2"><h:outputText value="#{testBean.date}"/></span>
<p:commandButton value="test" process="#none" update="#(#test)"/>
<p:commandButton value="test2" process="#none" update="#(#test2)"/>
Only first button is refreshing.
It's trival example - my real need is to update some parts of datatable, without refreshing whole component.
No, that's not possible. The update target must not only in client side be obtainable in HTML DOM tree by document.getElementById(), but also in server side by UIViewRoot#findComponent(), so that JSF can regenerate the desired HTML output which ultimately get applied during the ajax update.
If you supply JSF the ID of a plain HTML element, then it won't find anything in the component tree to regenerate the desired new HTML output for. Just replace the plain HTML element by a JSF component.
The PrimeFaces selectors get ultimately converted to HTML element IDs. PrimeFaces will loop over the elements found by the jQuery selector and extract their id attributes before passing to JSF. This is thus essentially the same problem as already answered here: Is it possible to update non-JSF components (plain HTML) with JSF ajax?.
I'm using com.sun.faces version 2.1.18. In my application I have a dynamic list of questions. I use <ui:repeat> to render each question. Depending on the type of question I render a type of input component and validation. In case of a number range question I use <h:inputText> with <f:validateLongRange>.
The problem I run into is that the minimum and maximum attributes on the <f:validateLongRange> are always set to the first question's minimum and maximum value. So, when you use the validator on any other then the first question it fails. Is that supposed to happen? Is there a way to get validation working on dynamically generated components? I hope it can be solved without switching to <c:forEach>.
Code snippet:
<ui:repeat value="#{questionnaire.questionsCollection}"
var="question">
..
<h:inputText value="..">
<f:validateLongRange minimum="#{question.minimumValue}"
maximum="#{question.maximumValue}"/>
</h:inputText>
..
</ui:repeat>
I've outputted #{question.minimumValue} and #{question.maximumValue}, and they have the correct values for my question.
This is indeed specified/expected behavior. The attributes of taghandlers like <f:validateXxx> are evaluated during view build time. So they can't refer a variable which is only available during view render time like the currently iterated variable of <ui:repeat>. It would indeed work when you use an iterator which runs during view build time like JSTL <c:forEach>. A more elaborate explanation about view build time versus view render time is given here: JSTL in JSF2 Facelets... makes sense?
You have basically the same problem as explained in detail here: How to set converter properties for each row of a datatable? It outlines various solutions in detail. One of the solutions in your particular case would be using OmniFaces <o:validator> which enables render-time evaluation of all attributes, so that you can just replace
<f:validateLongRange minimum="#{question.minimumValue}"
maximum="#{question.maximumValue}" />
by
<o:validator validatorId="javax.faces.LongRange"
minimum="#{question.minimumValue}"
maximum="#{question.maximumValue}" />
in order to get it to work as desired.
See also:
Setting a validator attribute using EL based on ui:repeat var
I have a question about the idea behind the fact, that only UIForm got the attribute prependId. Why is the attribute not specified in the NamingContainer interface? You will now probably say that's because of backward compability but I would preferre breaking the compability and let users which implement that interface, also implement methods for the prependId thing.
The main problem from my perspective about the prependId in the UIForm component is, that it will break findComponent()
I would expect that if I use prependId, then the NamingContainer behaviour would change, not only related to rendering but also when wanting to search for components in the component tree.
Here a simple example:
<h:form id="test" prependId="false">
<h:panelGroup id="group"/>
</h:form>
Now when i want to get the panelGroup component I would expect to pass the string "group" to the method findComponent(), but it won't find anything, I have to use "test:group" instead.
The concrete problem with that is, when using ajax with prependId="false". The ajax tag expects in the attributes update and process, that the values care of naming containers. It's a bit strange that when I use prependId="false" that I have to specify the full id or path, but okay.
<h:form id="test" prependId="false">
<h:panelGroup id="group"/>
</h:form>
<h:form id="test1" prependId="false">
<h:commandButton value="go">
<f:ajax render="test:group"/>
</h:commandButton>
</h:form>
Well this code will render without problems but it won't update the panelGroup because it cannot find it. The PartialViewContext will contain only the id "group" as element of the renderIds. I don't know if this is expected, probably it is but I don't know the code. Now we come to the point where the method findComponent() can not find the component because the expression passed as parameter is "group" where the method would expect "test:group" to find the component.
One solution is to write your own findComponent() which is the way I chose to deal with this problem. In this method i handle a component which is a NamingContainer and has the property prependId set to false like a normal UIComponent. I will have to do that for every UIComponent which offers a prependId attribute and that is bad. Reflection will help to get around the static definition of types but it's still not a really clean solution.
The other way would be introducing the prependId attribute in the NamingContainer interface and change the behaviour of findComponent() to work like described above.
The last proposed solution would be changing the behaviour of the ajax tag to pass the whole id, but this would only solve the ajax issue and not the programmatic issues behind the findComponent() implementation.
What do you think about that and why the hell is it implemented like that? I can't be the first having this problem, but I wasn't able to find related topics?!
Indeed, UIComponent#findComponent() as done by <f:ajax render> fails when using <h:form prependId="false">. This problem is known and is a "Won't fix": JSF spec issue 573.
In my humble opinion, they should never have added the prependId attribute to the UIForm during the JSF 1.2 ages. It was merely done to keep j_security_check users happy who would like to use a JSF form with JSF input components for that (j_security_check requires exact input field names j_username and j_password which couldn't be modified by configuration). But they didn't exactly realize that during JSF 1.2 another improvement was introduced which enables you to just keep using <form> for that instead of sticking to <h:form>. And then CSS/jQuery purists start abusing prependId="false" to avoid escaping the separator character : in their poorly chosen CSS selectors.
Just don't use prependId="false", ever.
For j_security_check, just use <form> or the new Servlet 3.0 HttpServletRequest#login(). See also Performing user authentication in Java EE / JSF using j_security_check.
For CSS selectors, in case you absolutely need an ID selector (and thus not a more reusable class selector), simply wrap the component of interest in a plain HTML <div> or <span>.
See also:
How to select JSF components using jQuery?
How to use JSF generated HTML element ID with colon ":" in CSS selectors?
By default, JSF generates unusable ids, which are incompatible with css part of web standards