Dean Pullen wrote:
> Ah excellent thats done the trick in a very simple way.

Sorry, yeah, after getting into work (I was still in my PJs pre-coffee
when I first read your question :^) and seeing Tim's excellent post, I do
exactly the same thing where I have a list of items that yu can select
(boolean).

One caveat: the IDs that show up in the mappingIds are are the IDs that
have been checked.  If you also need to know which ones have been turned
OFF, you'll need to know which IDs were displayed but aren't returned on
form submission.

It's slightly more complicated in the case of select lists.  In that case,
I have hidden controls called something like mappingId, with the name set
to the mappingId and the value of each instance set to the ID of the
object.  Then I have the select list controls named something relevant,
e.g. in one case I assign items to particular employees from a list, so
the select list is called employeeId.  The JSP code looks something like
this:

<display:table name="items" uid="item">
  <display:column>
    <input type="hidden" name="itemId" value="${item.itemId}"/>
    <select name="employeeId">
      <option value="0">Unassigned</option>
      <c:forEach items="${assignees}" var="assignee">
        <option value="${assignee.employeeId}"<c:if
test="${item.itemAssignedTo.employeeId == assignee.employeeId}">
selected</c:if>>
          ${assignee.lastName}, ${assignee.firstName}
        </option>
      </c:forEach>
    </select>
  </display:column>
</display:table>

So basically each item has this iterator (c:forEach) that churns out the
list of assignees.  It checks to see if the item is already assigned to
each assignee and, if so, makes that the selected assignee.

Now, what happens when you submit this is that two arrays get submitted,
the itemId array and the employeeId array.  Happily, the array indexes
will always correspond, so if you start at the beginning of the itemId
array, those objects will be in the same order as the employeeId array. 
So you can just take the object indicated by the itemId value at a given
index and assign to the employee indicated by the employeeId value at the
same index (or, you know, do whatever you want with the various IDs).

The Java code to handle this looks like this:

String[] itemIds        = RequestUtils.getStringParameters(request,
"itemId");
String[] employeeIds    = RequestUtils.getStringParameters(request,
"employeeId");

for (int index = 0; index < itemIds; index++)
{
  // Retrieve your object by ID however you do that; we use Hibernate.
  MyPojoBean bean = dao.get(itemId);
  bean.setEmployeeId(employeeIds[index]);
  dao.saveOrUpdate(bean);
}

> For others reading this:
> I just added a String array named selectedIds to the FormBean and was
> able to pull the row's unique ids from that.

The long-winded solution I started to describe is actually extremely
useful in the proper context, just not this one :^)  For example, if you
have a page that displays the properties of an object and one of those
properties is a map or array, you can use the BeanUtils mapping method I
was describing.  I've done that where I used to displaytag to display a
table of attachments to a message, with the attachment ID as the index of
a property assigned to a checkbox for delete operations.

> My problem now is how to get the export util to deal with these
> selected items. Any ideas?

Nope, I use the POI libraries for export.  From my limited experience with
export and more experience with the displaytag lib, I really really doubt
that the displaytag export does anything to deal with checkboxes on
export.  You should maybe look at the POI libraries (on Apache Jakarta),
which will allow you to do pre-processing of the data before the export
operation (I don't know if POI does export to PDF, it's mainly MS Office
formats).

-- 
Rick Herrick
[EMAIL PROTECTED]

I haven't got time for inner peace.

"No reasonable definition of reality could be expected to permit
this."--Albert Einstein, Boris Podolsky and Nathan Rosen in 1935



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
displaytag-user mailing list
displaytag-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/displaytag-user

Reply via email to