struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carlos Pita" <cp...@tycdigital.com>
Subject Some proposals
Date Wed, 07 Mar 2001 03:14:19 GMT
Hi!

   I'm writing to this list for the first time. I have recently been using
struts 1.0 b1 for a commercial development and I feel that some important
functionality is missing (at least in the tag libraries). So I would like to
help coding these tags or functionality if you agree with me; really, I
would not write a line of code (well, perhaps I'd write one) for my project
if I feel that I'm going to far from Struts' way or Struts next release and
also I'd like to callaborate with you.

   So, here are the proposals:

    1) The define tag, in the beans tag library is ok, but sometimes I'd
like to assign a new value to an already defined "variable". Perhaps this is
a too programmatic feature that we should avoid in JSP pages, what do you
think? But then we could have a tag that defines some kind of scope inside
which defined beans are accessible. The reason for suggesting this was that
I had to write a page where some large collections of items were generated
(and returned by getter methods in beans) and showed, and reassigning them
or putting them out of scope after use, in order to let them be
garbage-collected, would be the right thing to do (they were an important
number of really large collections).

    2) Some functionallity is missing from the iterate tag in the logic tag
library. For example, iterating over an Enumeration (well, I'm not sure this
is not currently possible, but documentation says that the tag iterates over
Collections). This would be useful because a lot of Java APIs returns
Enumerations instead of Collections. Another good thing (although
dangerous... you have the last word about this) that this pretty tag could
do for us is to iterate over ResultSets; this would be very handy if
moderately used (sometimes -often- we are in a hurry).

    3) For the options tags in the html library a good suggestion is: giving
the tag a name and a property, it should be able of iterating over the
collection/array/enumeration/?resultset? returned by this property; I mean,
sometimes beans don't have a property with a collection of values and a
property with a collection of labels but a property with a collection of
beans with 2 different properties for values and labels instead. I know the
tag offers the collection attribute, but this would be a little cumbersome
to use in the explained case. Also, from the utilities currently offered by
the tag, the proposed one seems to be someway logically missing.

    4) The conditional tags in the logic library are too coarse. They need
some kind of alternative-clause, like an else or cases. Most of the code
that I was able to get with the current conditional logic facilities is very
inefficient and hard to read; this is an almost free addon to the inherent
inefficience and code mess appearing in the normal process of writing HTML
pages.

    5) The errors tag should be more capable of controlling the presentation
of its output. I think it's a very dirty solution to write html in the
application resources file. The examples someway hide this, showing property
values like: "<li>Invalid format for From Address</li>", but real
applications would have an important percentage of html (or some kind of
presentational information) embedded in the resources file. This is not
easily mantenible and internationalization support would be very cumbersome
to achieve in this scenario (having to update several files and lot of items
in these files with duplicated information about  presentation). I suggest
that the errors tag should let the programmer to specify some kind of
formatting content, preferently as the content of the tag and inside
sections like
<start-of-item>,<end-of-item>,<start-of-list>,<end-of-list>,<no-errors>,
etc. (by the way, this would be very useful with any iterator tag; perhaps
we should have to subclass from some basic iterator tag class, or to have
some kind of hierarchy here, but I've not seen the current code so I could
not say any more about this).

    Well, I think this is all for now. I've thought some solutions for each
of the enumerated problems, but I would like to hear your oppinion about
these being real problems before explaining or discussing them.

See you,
    Carlos

Ah... sorry if my English is not the best



Mime
View raw message