You can make this much easier by setting up a TypeConverter and Formatter
for your Role type. Whenever possible, allow Stripes to deal directly with
the entities instead of their IDs because when you deal with IDs it is on
you to do the translation from ID to entity and vice versa. You end up doing
all the rigamarole you're trying to avoid here. As an example, I just did
this very thing recently with Users and Roles. The TypeConveter and
Formatter I'm using are provided by Stripersist. Relevant code below.
### In my ActionBean. (Note that I don't have to explicitly assign the
selected roles to the user.)
...
public List<Role> getRoles() {
if (roles == null) {
roles = getContext().getRoleDAO().list();
}
return roles;
}
...
protected void doSave() {
UserDAO dao = getContext().getUserDAO();
dao.save(getUser());
dao.commit();
}
### In my JSP. (Note that I do not use the checked= attribute at all.)
<c:forEach var="role" items="${actionBean.roles}">
<label title="${role.comment}"><s:checkbox name="user.roles" value="${role}"
/> ${role.name}</label><br>
</c:forEach>
###
So I'm iterating over each role that exists in the system and letting
Stripes render it in the checkbox's value= attribute via the Formatter,
which just spits out its ID. It determines whether or not the checkbox is
checked by looking in the user.roles property, which is a List of Roles
assigned to the user. If the current role is in the list, then the checkbox
is checked; otherwise it is not. When the form submits, Stripes constructs a
new List of Roles from the selected role IDs and calls
actionBean.getUser().setRoles(theList) with it. Then all I have to do myself
is call the DAO's save and commit methods.
A couple of notes: I'm using JPA with Stipersist, which provides a built-in
TypeConverter and Formatter for my entities. I can't recommend it enough.
Also, in the form I have <s:hidden name="user" /> so the ActionBean knows
which user I'm updating. That is populated and bound via the Formatter and
TypeConverter as well.
-Ben
On Thu, Feb 19, 2009 at 4:00 PM, Ross Sargant <[email protected]> wrote:
> Thanks John. From reading the API doc, it sounds like this changes the tags
> to favor
> the action bean parameter over the request parameter.
>
> It does not sound like it will change the priority of the "checked"
> attribute. I'm trying to avoid writing code to populate roleId[] in a
> preaction. My preaction loads the entity objects I need, but writing code to
> populate roIeIds[] based on my entity objects is redundant and tedious
> (certainly not a pattern I want to repeat over and over again) . I thought I
> could avoid it by using the "checked" attribute, but there seems to be this
> conflict between the "checked" attribute the population strategies that I
> can't wrap my head around.
>
> I will give it a try though.
>
> On Thu, Feb 19, 2009 at 3:14 PM, Newman, John W <[email protected]> wrote:
>
>> Try BeanFirstPopulationStrategy instead of the default, request first.
>> I struggled with the checkboxes and radio button values a while ago, we
>> switched to bean first which makes sense if you are using preactions to pull
>> data. Since we made that switch stripes just works more like I'd expect.
>> Some will argue bean first should be default, especially now since
>> preactions are widely encouraged as a best practice.
>>
>>
>>
>> Can someone clear up why request first is the default?
>>
>>
>>
>>
>>
>> *From:* Ross Sargant [mailto:[email protected]]
>> *Sent:* Thursday, February 19, 2009 2:16 PM
>> *To:* Stripes Users List
>> *Subject:* [Stripes-users] srtripes:checkbox checked attribute
>>
>>
>>
>> Hi,
>> Can someone give me a quick explanation on the intended usage pattern
>> for the stripes:checkbox checked attribute.
>> I feel like I'm fighting stripes somewhat when I use it so I might be
>> missing something.
>>
>> I'm generating a list of checkboxes to manage a many to many relationship
>> in my db. I use the checked attribute to pre-check the checkboxes
>> indicating the current relationships when the page first loads. A preaction
>> rounds up the necessary data.
>>
>> <table class="sortableResults">
>> <tr>
>> <th></th>
>> <th>Name</th>
>> <th>Enabled</th>
>> </tr>
>> <c:forEach var="role" items="${actionBean.allRoles}">
>> <tr>
>> <td><stripes:checkbox name="roleIds" value="${role}"
>> checked="${actionBean.systemReport.roles}"/></td>
>> <td>${role.name}</td>
>> <td>${role.enabled}</td>
>> </tr>
>> </c:forEach>
>> </table>
>>
>>
>> This works fine, but if my action bean (to which this form submits) has a
>> getter for "roleIds" the checked attribute is ignored (as described in the
>> pre-population priority rules).
>>
>> Problem:
>>
>> 1) I don't want to write code in my action bean to copy
>> ${actionBean.systemReport.roles} into my roleIds array so I don't have a
>> getter for roleIds. This makes the checked attribute work.
>>
>> 2) Without the getter present. When no checkboxes are checked, stripes
>> nulls out the roleIds field in my action bean using the setter. By
>> default, I initialize it to an empty array. I want to work with the empty
>> array and not a null array if no checkboxes are checked.
>>
>> I can obviously work-around either of these issues but the workarounds are
>> kludgy. I thought there might be something fundamentally wrong with the
>> approach I'm taking here..
>>
>> --
>> Ross Sargant
>>
>> TVR Communications LLC
>> Software Engineer
>> 3275 W Hillsboro Blvd,Suite 300,Deerfield Beach, Florida,33442
>>
>> http://www.tvrc.com
>>
>> p: 954-571-2017 x2108
>>
>> email: [email protected]
>>
>>
>> ------------------------------------------------------------------------------
>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco,
>> CA
>> -OSBC tackles the biggest issue in open source: Open Sourcing the
>> Enterprise
>> -Strategies to boost innovation and cut costs with open source
>> participation
>> -Receive a $600 discount off the registration fee with the source code:
>> SFAD
>> http://p.sf.net/sfu/XcvMzF8H
>> _______________________________________________
>> Stripes-users mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/stripes-users
>>
>>
>
>
> --
> Ross Sargant
>
> TVR Communications LLC
> Software Engineer
> 3275 W Hillsboro Blvd,Suite 300,Deerfield Beach, Florida,33442
>
> http://www.tvrc.com
>
> p: 954-571-2017 x2108
>
> email: [email protected]
>
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco,
> CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the
> Enterprise
> -Strategies to boost innovation and cut costs with open source
> participation
> -Receive a $600 discount off the registration fee with the source code:
> SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> Stripes-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>
>
------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Stripes-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-users
