I would be very interested in a copy of this taglib. Perhaps you could
do what you do and add what Martin likes?
Mike
Martin Cooper wrote:
On Thu, 30 Dec 2004, Brendan Burns wrote:
Hello,
I'd like to contribute a tag lib for downloading and displaying
current weather information gathered from public sources.
It can be obtained at: http://wso.williams.edu/~bburns/weather.tgz
Information:
1) Motivation
The tag is useful because it simplifies the task of obtaining and
displaying current weather information for a region (currently the
United States)
This seems a bit too special-purpose for Jakarta Taglibs, in my
opinion. But then I'm just one voice here, and others may have
different ideas.
2) Overview
The tag(s) are currently simple to use.
There are three tags:
<weather:stations state=CDATA/> displays an HTML select list
of weather stations for a particular state, for example:
"<weather:stations state="WA"/>" displays stations for Washington state
Gathering the information in a tag is fine, but doing the rendering in
the tag makes it very inflexible. For example, what if I want to use a
custom JavaScript widget instead of a regular HTML select? What if I
want more control over the CSS styles used in rendering the list? What
if I don't want HTML at all?
It would make more sense to me to have the tag construct a list (or
other suitable collection) of the information gathered, so that a user
could use JSTL to iterate over the array and generate whatever
rendering is appropriate for them.
Perhaps the following would make more sense:
<weather:stationList var="list" scope="request" />
<weather:load station=CDATA/> loads weather information for a
particular station and stores a WeatherReport object in the pageContext
I would think you would want to use JSTL-like attributes like 'var'
and 'scope' to specify where to put the information.
Perhaps:
<weather:stationInfo station="CA" var="info" scope="request" />
<weather:print value=CDATA/> is a convenience method for
printing information in the WeatherReport object. A user may also
choose to interact with the object directly.
Not sure what you mean by "print". If this is another rendering tag,
then the same comments I made for <weather:load> would apply.
3) Requirements
None beyond apache taglibs, servlet 1.2 and a SAX compliant xml parser
So presumably the actual data is obtained through a regular URL, and
not web services?
4) Commitment
I am willing to be the maintainer for this library.
That's good, but I'm afraid that's not the way the ASF works. There
needs to be a community around any project for it to be acceptable
here. If a project doesn't have an existing community (and often even
if it does), then it first needs to go through the ASF incubation
process. See the following site for more information:
http://incubator.apache.org
I don't mean to sound negative, but the ASF isn't SourceForge, and we
have a community-oriented approach that can be more demanding of new
projects. On the other hand, I believe the ASF approach tends to lead
to a much higher average success rate for projects than SF. No pain,
no gain, as they say. ;-)
--
Martin Cooper
Thanks for your time!
--brendan burns
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
