I have been pondering this very issue myself recently. For
example, I would like to be able to display the results of a
query in an HTML table. I don't want to have to create a
Javabean to hold the attributes for the result set, because
every time I want to tweak the result set, I have to
1. Add/remove/change getters and setters for the JavaBean to
conform to the new result set
2. Change the code that takes the data from the result set
and puts it in the JavaBean
3. Update the jsp to reflect the changes
In your dynamic Javabean = hashmap approach, I could easily
write a generic routine that takes a result set and converts
it into a collection of dynamic Javabeans. Then, when I
tweak the result set, the only thing I have to do is #3.
I think I've read somewhere on the list about an effort to
improve the scenario I just described, but there are a lot
of other scenarios where "dynamic JavaBeans" would come in
handy, and I hope it is officially addressed.
Stephen Schaub
----- Original Message -----
From: "Iraklis Kourtidis" <[EMAIL PROTECTED]>
Sent: Wednesday, April 25, 2001 12:27 PM
Subject: (architectural issue/feature request) JavaBeans in
Struts aren't flexible enough
Hi all,
I was wondering what your views on the following are:
JavaBeans seem to only allow fixed properties (say "foo" and
"bar), and the tags that operate on them (e.g. <bean:write>)
essentially call getters "getFoo()" and "getBar()". However,
this means that any time we're in
the action class and we want to package some information to
send to the JSP, we need to write a Java class with the
appropriate properties and getters. This
quickly becomes tiresome and causes code bloating; if I want
to avoid scriptlets in my JSP, I have to use Javabeans, so
for pretty much every Action class I need to add such a new
Java class.
A better way would be for Javabeans to be (essentially) some
sort of subclass of java.util.Map, so that I can add
properties at runtime. Here's some sample code:
GenericJavabean jb = new GenericJavabean();
jb.addProperty("foo", "value of foo");
jb.addProperty("bar", "value of bar");
Then, there could be some other tag, say <bean:write2> whose
"property" attribute will not correspond to a getter
function, but will instead call (internally)
bean.getProperty("foo").
In short, Javabeans, the current mechanism of passing
information to the JSP for display purposes, are limiting
because they have to be defined at *compile* time. It is not
practical (in terms of efficiency and complexity)
to add getter functions to a class at runtime (we've
considered that), so we need to essentially create new
Javabean classes.
Am I the only one who gets bothered by this? I was wondering
what the rest of you do. Do you just resign to creating new
Java classes every time you want to put something on the
request and send it to the JSP?
thanks for your input,
Iraklis
