I used to use that approach, until I had a page with this giant form with 30+
select lists on it. It wasn't practical to have 30 different List<X> fields in
the bean with getters and setters, and then all the population code in a
@Before method. I could have made one pojo to encapsulate all of that, but
still the same code essentially.
What I did was create a method in the bean that the page calls to pull the list
out. Example with freemarker since you can write method calls the correct way
[EMAIL PROTECTED] name="x"]
[EMAIL PROTECTED]"options-collection"] value="id" label="name"
collection=ab.list("com.test.SomeClass")][/@]
[/@]
class ActionBean {
public <E extends Entity<? Extends Serialziable>> List<E> list(String
className) {
return entityManager.findAll(classTypeConverter.<E> convert(className));
}
}
Obviously there is a lot more to this, the freemarker macro and methods we have
support sorting, filtering, named queries w/ var arg params, etc.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Asleson, Ryan
Sent: Friday, May 09, 2008 8:27 AM
To: Stripes Users List
Subject: Re: [Stripes-users] Repopulating Drop-Downs after Validation Error
That helps a lot. Thank you Ben!!!
________________________________
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ben Gunter
Sent: Friday, May 09, 2008 7:16 AM
To: Stripes Users List
Subject: Re: [Stripes-users] Repopulating Drop-Downs after Validation Error
What you're doing is just fine. You just need to move your list population code
somewhere else so that it will always fire, even if validation fails. You can
do that in one of two ways that I know of.
1. Lazy initialization in your getter. E.g.:
2. private List<Thing> things;
3. public List<Thing> getThings() {
4. if (things == null) {
5. things = loadThings();
6. }
7. return things;
}
1. Use a @Before method to populate the list before validation runs. The
advantage to this approach is that if you have certain events that fire that do
not need to populate the list, then you can disable list population for those
events easily. E.g.:
9. private List<Thing> things;
10.public List<Thing> getThings() { return things; }
11.
[EMAIL PROTECTED](stages=LifecycleStage.BindingAndValidation, on={"!cancel"})
13.public void loadThings() {
14. // do whatever you need to do
}
The first option is more straightforward (IHMO), and the second is more
flexible. Either one should fix your problem.
-Ben
Asleson, Ryan wrote:
Hello,
I'm using Stripes 1.5 Beta on Java 6.
The general pattern I've been following in the application is that every
ActionBean has a view() method which is annotated with the @DefaultHandler
annotation, and the view() method is responsible for populating the ActionBean
with anything needed to display the page. Usually the view() method has to
grab some data from the database for the page to be displayed.
This has worked well so far but I've run into a problem. I have a page that
has a few text boxes and a drop-down select box. The List that populates the
select box is retrieved from the database by the view() method. When a
@Validation fails, the text boxes are populated correctly (with the
information, right or wrong, that the user entered) but the select box is empty
and has no options -- obviously the view() method did not have chance to
repopulate the list on the ActionBean.
How do I get around this? In the old Struts 1.x world (blah), a Tiles
controller backed every JSP and was responsible for populating the page with
info from a database.
Is my pattern of having every ActionBean with a view() method a poor pattern?
I'm wondering if the <stripes:useActionBean> tag is what I need to use, but I'm
not sure how I should fit everything together.
Thanks!!
-Ryan
This e-mail message is being sent solely for use by the intended recipient(s)
and may contain confidential information. Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the intended
recipient, please contact the sender by phone or reply by e-mail, delete the
original message and destroy all copies. Thank you.
________________________________
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
________________________________
_______________________________________________
Stripes-users mailing list
[email protected]<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/stripes-users
This e-mail message is being sent solely for use by the intended recipient(s)
and may contain confidential information. Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the intended
recipient, please contact the sender by phone or reply by e-mail, delete the
original message and destroy all copies. Thank you.
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Stripes-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-users
