We Keep Coding

Struts2 Tags: Fielderrors tag

I am currently using Struts2 tags for my form, and to show its error messages. My question is that the default markup for showing error messages in Struts2 tags is the usage of <ul> tag. is there anyway I can change this? I want the error messages to be displayed as <span> not a list.
How would I achieve this?

Another option is to change the CSS for UL elements.
This approach works only if you specifically care about appearance, not the DOM itself.

You can override template files which are used for rendering errors. Copy actionerror.ftl and fielderror.ftl files from the simple theme from struts2-core jar to your application and modify them not to use ul/li tags.

The tags render according to their theme. The question then changes to: How do you change the theme? You can change it for the tag
(set theme attribute on the tag to simple), page, request, or generally.
http://struts.apache.org/2.2.1/docs/struts-2-themes.html
Personally I like writing html, that is I don't like any "help" from the struts2 default theme. So in my struts.xml I simply use:
<constant name="struts.ui.theme" value="simple" />
Web developers should know html.
Update:
Generally use YUI reset.css so I probably missed this...
If you extend ActionSupport on the action there is a getFieldErrors() method so you could use <s:property value='fieldError["field_name"]'/> that will return the associated error message string of course without any formatting.
It isn't much less readable than the <s:fielderror/> tag... after all we need to use property tags all the time anyways.

I had same issue I used following code to resolve my issue
<s:if test="fieldErrors.get('email').size() > 0">
<s:property value="fieldErrors.get('email').get(0)"/>
</s:if>
Where email is name of my field. This way we don't have to modify CSS.

Here is a tutorial to show the use of the Struts 2′s ActionError and ActionMessage class.
http://www.mkyong.com/struts2/struts-2-actionerror-actionmessage-example/
ActionError – is used to send error feedback message to user – display via < s:actionerror/ >
<s:if test="hasActionErrors()">
<div class="errors">
<s:actionerror/>
</div>
</s:if>
ActionMessage – is used to send information feedback message to user,display via < s:actionmessage/ >
<s:if test="hasActionMessages()">
<div class="welcome">
<s:actionmessage/>
</div>
</s:if>

weird issue : jsf inside jsp not working

I have created web-application using JSF 2.0 & JSP and facing some weird problem.
I have page in JSF where I have included JSP page. code are as below.
<o:resourceInclude path="detailedReports.jsp" />
Where o is omnifaces. xmlns:o="http://omnifaces.org/ui"
Now in JSP (detailedReports.jsp) I have code as below.
<h:form id="myForm" prependId="false">
<h:commandLink value="Take Me To Some Page" action="#{PersonalInformationDataBean.moveToApplicantRegisterPage()}" />
</h:form>
moveToApplicantRegisterPage() have below code
public String moveToApplicantRegisterPage() {
editedData = 1;
return takeMeToAnotherPage("registerForPatentss");
}
When I click on Take Me To Some Page link, I get directed to detailedReports.jsp and not to registerForPatentss.xhtml.
Any reason why this is happening? What should I do to get redirected to registerForPatentss.xhtml.
Note: While redirecting to registerForPatentss.xhtml, I also need to set the data of int editedData to 1.

It might be a rendering problem related to mixing two different view technologies (JSP and facelets).

I don't think there is any solution. So what I did is, take JSP in JSF i.e. I re-wrote JSP content in JSF Format. So now I don't have any JSP page.
All is working perfectly!!!

Spring is eating </textarea> tags

In my web application (my first with Java, Spring, OR Roo), I'm building a form that has nothing to do with any JPA objects, it's just a form. I really don't want to use JSTL to build my forms here, because there's no data backing for them at this point. I'm using tiles to assemble the pages, so the guts of this form comes from a view, but apart from that there's nothing JSPish about it; it's just a form.
Inside that form, I have a text area that I've written:
<textarea id="whatever" name="whatever"></textarea>
When that comes to the screen, the </textarea> tag is gone. Different browsers deal with that differently, up to and including swallowing up the whole rest of the body HTML inside the text area field.
So I tried putting some content inside that textarea. Spaces and line breaks don't change its behavior, but it appears that any non-space character does. If I go
<textarea>.</textarea>
... it respects my close textarea tag. But then of course my text area renders on the screen with a dot in it, which isn't what I want.
Is this a known issue? Am I doing something wrong?
EDIT:
#bozho: Here's a pertinent chunk of my jsp:
<div id="notes" class="detailPanel">
<div class="panelLabel">Notes</div>
<table >
<thead><tr><th>Date</th><th>By</th><th>Note</th></tr></thead>
<tbody id="notesBody"></tbody>
</table>
<textarea id="newNote" rows="5" cols="80" >.</textarea>
<button id="addNewNote" onClick="saveNote();">Add New Note</button>
</div>
Absolutely nothing fancy going on here (I populate the tbody with rows on the client, is why that's empty). Without the dot in the third-to-last line, the closing textarea tag does not come out in the resulting HTML.
EDIT2 (Solution):
This URL became googlable after hearing some key words from people responding here:
http://www.jroller.com/komu/entry/textareas_with_jspx
Turns out that when jspx pages are parsed, empty tags are collapsed into a single self-closing tag, which breaks text areas. The solution is to put an empty jsp:text in the middle:
<textarea><jsp:text /></textarea>
(Which is STAGGERINGLY stupid, but there it is.)

You are using jspx files right?
In general jspx remove something (or in your case it shorten it: check this: I expect that it addes a slash to the former opening tag, so it becomes: <textarea id="whatever" name="whatever"/> ) where it belives that is not needed. What exactly depends ona bit on the implementation.
So put a <jsp:text> tag in the text area tag to prevent it from "closing"
<jsp:text>
<textarea id="whatever" name="whatever"></textarea>
</jsp:text>
<textarea id="whatever" name="whatever"><jsp:text /></textarea>
for an more complex example have a look at this answer: websphere 7 (and Spring Roo) incompatible with javax.el.ELException

JSF2.0 Partial Render with ui:define

I'm using facelet templating and I think I'm running into an issue with ui:define and the JSF lifecycle. My template.xhtml contains a fixed menu in the header, simplified it has links like this:
<h:commandLink value="Click Me">
<f:ajax update="#{myBean.listener}" render="contentpanel"/>
</h:commandLink>
The template.xhtml also contains a ui:insert statement:
<ui:insert name="content">
<h:outputLabel value="content placeholder"/>
</ui:insert>
Now I have a content.xhtml which looks like:
<ui:composition template="template.xhtml">
<ui:define name="content">
<h:panelGroup id="contentpanel"/>
</ui:define>
</ui:composition>
So much for the introduction. When I click the commandlink 'Click Me' I'm calling my listener. This listener sets a reference in a backingbean to dynamically load the content based on the link I clicked.
This rendering is not done the first time I press the commandlink. Well it basically looks like it first does the re-render and then call the listener instead of the other way around. So when I first click, nothing seems to happen. When I click for the second time I see the content that was set for the first click. When I click for the third time I see the content of the second click.
I think it's because the ui:define view is already re-built in the 'Restore View' phase of the JSF lifecycle. Any ideas on how to overcome this?
UPDATE
Seems like my assumption was wrong. The cause of this seems to be something different. The #{myBean.listener} has a #SessionScoped #ManagedProperty which is updated after the CommandLink is clicked. The contentpanel actually loads data via the #{myBean.data} which is #RequestScoped. This #{myBean.data} did not reload the data correctly. I solved it by passing the getData() method directly to the #SessionScoped bean.
Might be a bit confusing. But my conclusion: it does work to partial render a component which is loaded via facelet templating (ui:define / ui:insert)

Seems like my assumption was wrong. The cause of this seems to be something different. The #{myBean.listener} has a #SessionScoped #ManagedProperty which is updated after the CommandLink is clicked. The contentpanel actually loads data via the #{myBean.data} which is #RequestScoped. This #{myBean.data} did not reload the data correctly. I solved it by passing the getData() method directly to the #SessionScoped bean.
Might be a bit confusing. But my conclusion: it does work to partial render a component which is loaded via facelet templating (ui:define / ui:insert)

Can Not Read id on JSF Components

I have a little problem
I am trying to use MartkItUp JQuery rich text editor on JSF textarea component.
My form looks like this:
<h:form id="comment">
<h:inputTextarea id="commentBody" cols="10" rows="10" value="#{postComment.commentBody}" required="true" requiredMessage="Comment Body is reqguired" >
<f:validateLength maximum="500" minimum="2" />
</h:inputTextarea>
<%-- more of the form... %-->
The problem is that on output it gives me the id for textarea like that
id="comment:commentBody"
When I try in JQuery to point to it nothing happens.
$('#comment:commentBody').markItUp(mySettings);
I had a plain textarea before, and there was no problem. Now, I have a lot of them.
How do I point to id in JQuery, thats looks like comment:commentBody
P.S: I know i can point to this text area by $('textarea').markItUp(mySettings); however i am looking for solution to point to specific text area by it's ID.

Try this, $('#comment\\:commentBody'), for JQuery version 1.1.3 or greater.

try this:
$("textarea[id$='commentBody']").markItUp(mySettings);
this will select text area having ID ending with commentBody.
to select control with ID starting with particular string replace $ with ^

You can read about JSF IDs here, but in this case you may also find the h:form prependId attribute useful.