Using Beans from Collection

[Baruch Sadogursky]

Dear friends!
I'd like to use beans to build a table from their properties. The beans come in Collection, which is passed in HTTPServletRequest. So far so good.
Now I run a loop on the collection to get the references to the beans:

<jsp:useBean id=?????? class="myPackage.MyBean" scope="request">

The bean instance doesn't have a name, since it's resides in the Collection. How can I reffer to it?

[Winston Smith]

You may not want to use each class as a Bean in itself. You can have one single Bean to act as a Manager, and this Manager maintains the Collection. Therefore, the Manager will be used to create an Iterator for your Collection and use the Iterator to reference each object in the collection.
[ April 13, 2004: Message edited by: Winston Smith ]

[Baruch Sadogursky]

That means - discard the beans idea and work in scriptlet, which is undesirable in JSP, as I know. Maybe there is a way to minimize the Java code?

[Bear Bibeault]

You can avoid scriptlets on the page via the JSTL, which is collection-aware.
Backing up a bit... if the collection is not the best way for your page to be dealing with your beans, why is your controller setting things up that way? The controller should arrange the data in the manner best-suited for the page.

[Baruch Sadogursky]

How esle can I pass a set of beans, which is build dinamically from the model domain?

[Bear Bibeault]

How are they used on the page? Individually? As an ordered set?
If they are individual, a collection may not be the best manner.
If they are indeed a set, then passing them across as a collection and iterating over them (with the <c:forEach> JSTL tag if you want to avoid scriptlets) makes perfect sense.

[Baruch Sadogursky]

The page iterates over the set, and displays the beans as rows in table.
Your sollution seems the one I look for
10x!
One little problem - I don't know JSTL Good reason to learn!

[Bear Bibeault]

I don't know JSTL Good reason to learn!

I concur. Even though it seems like a small thing -- after all, it's simply notation -- I find pages using the JSTL rather than scriptlets to be incredibly easier to read and maintain.

[Winston Smith]

You may not want to use each class as a Bean in itself.

What I mean here is, every class you create need not function as a Bean. Certainly you do not want to create classes in your JSP. For instance, on a recent project, I have a WebEntity Bean which models a supervisor/upper management. Now this supervisor will have numerous employees under his/her supervision. Each employee is modeled by the Employee class. Now, the Employee class is not meant to work as a Bean, however, the WebEntity class maintains a HashMap of Employee objects, so, in the web environment, you will have access to and may iterate through, the Collection of Employee objects, even though they are not Beans.
I use the above model often, as many classes need not function explicitly in the web environment, while others (the Beans), are made to work in the web environment.

[Bear Bibeault]

many classes need not function explicitly in the web environment

The problem with that approach is that since the various JSP mechanisms (such as the built-in JSP actions, as well as the JSTL and the expression language) are meant to be used with bean-patterned classes. Exposing non-bean classes to the page forces the use of scriptlets and scriptlet expressions to access the methods of the class.
In order to make best use of the built-in JSP mechanisms (highly recommended by this bartender), you should write your page-exposed classes to follow the bean pattern. Where that is not possible, you could wrap your non-bean classes in bean-patterned wrapper classes for use on the page, or utilize bean-patterned delegates to allow easy access without resorting to on-page Java.

[Baruch Sadogursky]

I'd like to use beans for convinient output of the properties using

<jsp:getProperty>

.