Miguel Almeida

Hi Lydia,

The simple answer to your question is that you can use a library like EasyMock to help you. In simple terms, it works like so:

//Here you set your expectations. In this case, we expect our action to call findById with the id 3 Interface session = EasyMock.createMock(Interface.class); action.setSession(session); EasyMock.expect(session.findById(3)).andReturn(someMockObject); //After "recording our expectations", we put the mock in the replay state EasyMock.replay(session); //We run our action... action.execute(); //We see if our expectations were met EasyMock.verify(session); //checks if findById(3) was actually run assertEquals(3,action.getObject().getId());

This is the general idea of working with mocks.

Now, as it might become apparent, your code needs quite a few expectations. This is because you are doing a lot of db stuff in the action itself that could be refactored somewhere else. For example, you could have a personService with a delete method, where you'd encapsulate your code in, say, a deleteUser(String username). In the the action you would therefore only have to mock one method (the deleteUser one), and you can simulate what you want to happen in your action for an array of situations (what if that method throws an exception? what if the user doesn't exist?): it's just a matter of mocking the expectations.

Another (simpler) way would be to encapsulate that code in a helper method in the action, like:
private void delete(String username){ User user = null; Session session = HibernateUtil.getSessionFactory().openSession(); try { session.beginTransaction(); user = (User) session.load(User.class, userName); session.delete(user); session.getTransaction().commit(); } catch (Exception e) { } finally { session.close(); } } public String execute(){ delete(userName);


You can then test it in your class by overriding that method for testing purposes.


For more on this, I suggest the reading of Lasse Koskela's excellent Test Driven, which explores these strategies in the context of TDD.

The log message isn't very helpful...
Just on a sanity check; do you have your tiles.xml in the WEB-INF directory?

The general idea is (as per https://cwiki.apache.org/WW/how-do-we-repopulate-controls-when-validation-fails.html) to have the following:
1) jsp with a list of items and a "add item" form
2) when validation fails, the list of items should still populate

The method: Add a <s:action name="xxx" executeResult="true"/> to the jsp, that should execute even when the validation fails and sends the action to INPUT
The problem: When helloWorld's validation fails (see below), Action xxx is redirecting to input, and not to SUCCESS, as expected.

Does anyone know why this happen?

A simple /jsp/index.jsp would be (where helloWorld's method is annotated with @RequiredStringValidator):
<s:form action="helloWorld"> <s:textfield label="What is your name?" name="name" /> <s:textfield label="What is the date?" name="dateNow" /> <s:submit /> </s:form> <s:action name="xxx" executeResult="true"/>

The action configuration (I've explicitly defined interceptor-ref here to ensure I'm using the default stack) :
<action name="helloWorld" class="helloWorldAction"> <interceptor-ref name="defaultStack"></interceptor-ref> <result name="input">/jsp/index.jsp</result> <result>/jsp/helloWorld.jsp</result> </action> <action name="xxx" method="loadTrialCentres" class="centreManagementAction"> <interceptor-ref name="defaultStack"></interceptor-ref> <result name="input">/jsp/xxx.jsp</result> <result name="centresLoaded">/jsp/centreList.jsp</result> </action>

Expected: If either the name or date are not filled, the validation fails and sends to input. The contents of centreList.jsp should be shown, however, because that action should be independent. I've even annotated the loadTrialCentres with @SkipValidation
Actual: The contents of xxx.jsp are shown.

Richard Golebiowski wrote:That is odd. I have never seen setting the fieldValue not work. I'll have to give it a try later today and see what happens.

I have found the source of the problem, thanks to your help. It appears there was a jquery action removing all "value" attributes when displaying the form (which is invisible when the page loads).
The fieldValue was, in fact, being applied, but the jquery was removing it just before the form was shown!

Thanks for the help, Richard.

Richard Golebiowski wrote:Try setting the fieldValue attribute:
fieldValue="true"

I have also tried that, but it produced no change - quite odd, as I thought that attribute was precisely for this purpose.

I have a checkbox defined as:
<s:checkbox id="underSurveillance" name="activeSubstance.underSurveillance" />


The action that goes to this page has an activeSubstance object without any properties defined the 1st time we visit it.

With a normal theme (say theme="xhtml"), the html generated is:

<input name="activeSubstance.underSurveillance" value="true" id="uS" type="checkbox"> <input id="__checkbox_uS" name="__checkbox_activeSubstance.underSurveillance" value="true" type="hidden">

With a simple theme, however, we get:
<input name="activeSubstance.underSurveillance" id="uS" type="checkbox"> <input id="__checkbox_uS" name="__checkbox_activeSubstance.underSurveillance" value="true" type="hidden">

Notice how the value="true" attribute disappeared!
This seems to happen when the activeSubstance (which is being injected with Spring) hasn't been defined (ie, the "create new" page). When we've populated an activeSubstance (ie, "edit existing") we have, as expected:

<input type="checkbox" id="underSurveillance" checked="checked" value="true" name="activeSubstance.underSurveillance"/>

The current solution for using the checkbox with the simple theme is some javascript to add the value="true", like:

<script> $(document).ready(function(){ $('#underSurveillance').live('change', function () { $(this).val($(this).attr('checked')); }); }); </script>

Is there any cleaner solution?

David Newton wrote:Honestly, I'd use a JavaScript calendar widget, and use Apache Commons date utility to try a collection of date formats if JavaScript is disabled.

Thanks for the kind words :)

Hey David,

I am already using a javascript calendar widget (jquery's datepicker), but I am stuck with the same problem: I could

<s:textfield id="%{#attr.dateField}" name="%{#attr.dateField}.date" cssClass="calendar %{#attr.dateField}.format" />

So I could set the format based on the css class, but I need the actual evaluation of "x.format".

Eg:
if dateFied=death.date, I'd need the value of death.date.format, ie, something like "MM-yyyy", and not the string "death.date.format".

I've been going in circles for a while with this, but I'm finding it very hard to do something so trivial like this.

The following code works on the JSP. But I can't encapsulate it in a .tag file, which is cumbersome when you re-use it a lot and notice all that is changing is the "death.deathDate" (date object which will hold the .date and .dateFormat) and the label...

<s:date name="%{death.deathDate.date}" var="dd" format="%{death.deathDate.dateFormat}" /> <s:textfield id="deathDate" name="death.deathDate.date" value="%{#dd}" label="Date of Death (dd-MM-yyyy)" cssClass="calendar"/><br> <s:radio label="" labelSeparator="" cssClass="deathDate_DateFormat" name="death.deathDate.dateFormat" key="format" list="#{'dd-MM-yyyy':'day','MM-yyyy':'month','yyyy':'year'}" > </s:radio>

David Newton wrote:You can't double-evaluated OGNL (well, you can, by using OGNL's static eval method, but I seriously don't think it's the best solution).

David, do you have any suggestion regarding the use of a custom .tag in my case?
The idea is to use:
<help:date dateField="death.deathDate" label="Date of Death (dd-MM-yyyy)"/>

which points to a (currently not working due to the above reason) .tag file:

<s:label value="%{#attr.label}" /> <s:date name="%{#attr.dateField}.date" id="dd" format="%{#attr.dateField}.dateFormat" /> <s:textfield id="%{#attr.dateField}" name="%{#attr.dateField}.date" value="%{#dd}" cssClass="calendar" /> <br/> <s:radio label="" labelSeparator="" cssClass="%{#attr.dateField}_DateFormat" name="%{#attr.dateField}.dateFormat" key="format" list="#{'dd-MM-yyyy':'day','MM-yyyy':'month','yyyy':'year'}"/>


By the way, congratulations on your "Apache Struts 2" Packt book. It's a great S2 reference and I've recommended it to everyone starting to learn Struts!

Xolani Nkosi wrote:

Xolani Nkosi wrote:

David Newton wrote:But S2 documentation seems to suggest that we disallow JSP EL due to the security risk. So use OGNL all the way; there's a FAQ entry on this I think.

Right, I can get at the parameters made when calling my tag by using #attr.enabled, #attr.name etc etc.

However, as these are OGNL expressions, I need a way to evaluate them. e.g.

<s:if test="#attr.enabled"> needs to be something like <s:if test="%{#attr.enabled}"> as #attr.enabled itself contains an OGNL expression like "object.enabled" that should be resolved against the value stack. But, surprise surprise, this doesn't work. Nesting %{'s doesn't cause the inner result to get evaluated as if it were an OGNL expression.

So, where's the OGNL eval function?

Right, this thread seems to detail my problem: http://old.nabble.com/Attribute-OGNL-evaluation-issue-on-struts-tag-in-tag-file-td21732140.html

Someone claims to have found the solution at http://forums.opensymphony.com/thread.jspa?messageID=6278131 but it seems the opensymphony forums aren't around any more. Anyone got a lead on where this solution now is?

Hey, I am having a similar issue (posted in http://old.nabble.com/How-can-one-use-OGNL-on-custom-.tag-files--td27880257.html ). Did you manage to find a solution to your problem?