RE: (architectural issue/feature request) JavaBeans in Struts aren'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. )
> 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 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
>
>
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. )
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 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
RE: (architectural issue/feature request) JavaBeans in Struts aren't flexible enough
Thanks for the response.
Whether we use XML and access elements through XPath, or use a Hashmap of
Hashmaps,
the idea is still the same: Javabeans are not flexible enough to allow you
to
codify display information - which is an irony considering that's what
Javabeans
were created for. What we'll end up doing is creating a Hashmap of Hashmaps
and then
ditching the tag (which operates on a Javabean) and either
(a) write our own tags that operate on our own objects, or
(b) using scriptlets to perform the loops.
If the developers of Struts were to add this as a standard feature, then
different
groups would not need to implement the same idea in a non-standard way...
Just a thought.
Iraklis
-Original Message-
From: Rajan Gupta [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, April 25, 2001 2:33 PM
To: [EMAIL PROTECTED]
Subject: Re: (architectural issue/feature request) JavaBeans in Struts
aren't flexible enough
Have u thought of using XML for passing generic data around. A Tag using
XPath can be used to access the data from this generic XML document.
--- Iraklis Kourtidis <[EMAIL PROTECTED]> wrote:
> 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. ) 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 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
>
__
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/
Re: (architectural issue/feature request) JavaBeans in Struts aren't flexible enough
Have u thought of using XML for passing generic data around. A Tag using
XPath can be used to access the data from this generic XML document.
--- Iraklis Kourtidis <[EMAIL PROTECTED]> wrote:
> 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. ) 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 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
>
__
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/
RE: (architectural issue/feature request) JavaBeans in Struts aren't flexible enough
I agree 100%. We do the same thing. Most of our "DBAccessor" classes fill a HashMap from the DB tables and we use bean.getProperty(name) to access them. This means we do not need to do maitenance on the classes to add new properties. Just add it to the database and use it in the JSP. This is much more extensible and maintainable. Frank Lawlor Athens Group, Inc.
(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. ) 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 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
