Hi Iraklis
I did alot of experimenting with this approach on my previous project about
four months ago i.e. a generic JavaBean that was an extension of the HashMap
object with generic getProperty/setProperty methods.
I hit upon the idea of storing the properties and meta data for the
"JavaBeans" in XML files, with an instance of the generic JavaBean being
created from a given XML file. So I got the advantages of:
* being able to modify properties at deploy time by modifying the XML files
* programmers knowing what was in the Maps by looking at the XML files
* not needing to create explicit get/set methods
I also wanted the XML files to doubled as property-to-RDBMS column mappings
so I could construct SQL queries from them and populate the JavaBean that
way, but I couldn't get that part to work generically enough.
It mostly worked but I stopped after a few runs because of the really bad
performance problems I was experiencing (especially in an iterate situation)
compared to normal JavaBeans.
I never did completely figure out why, but I thought it might have had to do
with the amount of Object creations that were going on because you can only
store objects in HashMaps, whereas you can use primitive types in normal
JavaBeans, and there also seemed to be some sort of built-in optimization
possible with normal JavaBeans, especially with the JSP Engine I was using
anyway (WebLogic 5.1).
I also realized how much work would be involved in changing the Struts tag
libs to make the generic JavaBean work. I did end up creating some custom
tags but that didn't help with the performance, even though the code was
significantly simpler than the Struts version. It was really mysterious. So
I've gone back to using normal JavaBeans.
Your welcome to some of my code if you want to do your own experimenting.
I hope this helps
Jason
-----Original Message-----
From: Brugge, John
To: '[EMAIL PROTECTED]'
Sent: 04/26/2001 10:29 AM
Subject: RE: (architectural issue/feature request) JavaBeans in Struts are
n't flexible enough
How you feel about type safety and having a/the compiler help you out
will
also play into your choice here. For all of the pain that creating
JavaBean
classes causes, they do create a well-defined interface that developers
of
JSPs can use to rely on to know what data is available. If all you're
passing back is a Hashmap, then there needs to be an agreement between
the
JSP develper and the Action developer as to what that Hashmap will
contain.
If those developers happen to be the same person, that's usually not a
problem (unless you tend to forget what you tell yourself ;-) If they
are
different people, then you might want the agreement to be more than just
a
verbal agreement during a hallway meeting. Which leads to documenting
what
the Hashmap will contain, which leads to having to maintain the
documentation...
Having JavaBeans as the format of your data also means that the JSP
compiler
can tell you when you try to refer to a property that isn't there, or is
misspelled. The compiler can be your friend here. However, if your JSP
refers to an entry in a Hashmap and gets it wrong, it's harder to track
down
the problem. Is the field on the form blank because there isn't any data
there, or because you asked for the wrong entry name?
There's definite flexibility advantages to using dynamic collections of
data, but realize that it comes at a certain cost.
John
> -----Original Message-----
> From: Stephen Schaub [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, April 26, 2001 6:52 AM
> To: [EMAIL PROTECTED]
> Subject: Re: (architectural issue/feature request) JavaBeans in
> Struts aren't flexible enough
>
> 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
>
>
