You are viewing a plain text version of this content. The canonical link for it is here.
Posted to taglibs-dev@jakarta.apache.org by Shawn Bayern <ba...@essentially.net> on 2002/04/21 18:16:26 UTC
[PROPOSAL] Collections taglib
I mentioned this once before, but now that I have more time, I'd like to
explore it a little further.
Is there any interest for a taglib that manipulates objects from the Java
Collections API? JSTL's expression language lets users read elements from
collections and iterate over them, but for more specialized operations
(computing the size, reversing the order, and so forth), users are on
their own.
While I was waiting for a session to start at JavaOne, I drafted up a
preliminary interface. Two questions, then --
- Any interest in this, or is it pointless?
- Does the interface (tag set) look reasonable as a starting point?
===
<data:copy var="new" collection="old" />
// copies the collection, which is useful if you suspect it will change
// or if you're going to modify it yourself
<data:size var="size" collection="c" />
// computes and exposes the size of the collection
<data:sort var="new" collection="old"
[order="ascending|descending"]
[comparator="c"]
/>
// sorts the collection
<data:reverse var="new" collection="old" />
// reverses the current order of the collection
<data:max var="max" collection="c" [comparator="c"] />
// exposes the maximal element in the collection
<data:min var="min" collection="c" [comparator="c"] />
// exposes the minimal element in the collection
<data:new collection="list|map|set" [javaType="..."]>
// creates a new List, Map, or Set
// - javaType if specified must be compatible with collection
// - list defaults to ArrayList, map defaults to HashMap,
// set defaults to HashSet
// - no 'collection' defaults to type suggested by subtags
// (key -> Map, no key -> List)
// - empty <data:new> tag defaults to empty ArrayList.
<data:item [value="value"] [key="key"] />
// - no 'value' attribute implies String from body
<data:items collection="c"/>
</data:new>
<data:add collection="c" >
// adds the items from the subtags to the collection
// - subtags must have a key if 'c' is a Map, otherwise must not
<data:item .../>
<data:items ... />
</data:add>
===
Use cases include:
<data:reverse var="backwards" collection="${forwards}"/>
<c:forEach items="${backwards}">
...
</c:forEach>
---
<data:new var="new" scope="session">
<data:items collection="${c1}"/>
<data:items collection="${c2}"/>
</data:new>
// elsewhere in session
<c:forEach items="${new}">
...
</c:forEach>
--
Shawn Bayern
"JSP Standard Tag Library" http://www.jstlbook.com
(coming this summer from Manning Publications)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Collections taglib
Posted by James Strachan <ja...@yahoo.co.uk>.
I guess some folks might find this useful but it does strike me that most of
these seem like simple functions to me; collection.size(),
collection.clone(), Collections.sort() and so forth. I think I'd prefer to
have a special EL that allowed methods to be called ;-)
Though the tags to create collections look very useful. A prefix of 'coll'
or 'collection' would seem more appropriate than 'data' which is a bit
vague.
James
----- Original Message -----
From: "Shawn Bayern" <ba...@essentially.net>
To: <ta...@jakarta.apache.org>
Sent: Sunday, April 21, 2002 5:16 PM
Subject: [PROPOSAL] Collections taglib
> I mentioned this once before, but now that I have more time, I'd like to
> explore it a little further.
>
> Is there any interest for a taglib that manipulates objects from the Java
> Collections API? JSTL's expression language lets users read elements from
> collections and iterate over them, but for more specialized operations
> (computing the size, reversing the order, and so forth), users are on
> their own.
>
> While I was waiting for a session to start at JavaOne, I drafted up a
> preliminary interface. Two questions, then --
>
> - Any interest in this, or is it pointless?
> - Does the interface (tag set) look reasonable as a starting point?
>
> ===
>
> <data:copy var="new" collection="old" />
> // copies the collection, which is useful if you suspect it will change
> // or if you're going to modify it yourself
>
> <data:size var="size" collection="c" />
> // computes and exposes the size of the collection
>
> <data:sort var="new" collection="old"
> [order="ascending|descending"]
> [comparator="c"]
> />
> // sorts the collection
>
> <data:reverse var="new" collection="old" />
> // reverses the current order of the collection
>
> <data:max var="max" collection="c" [comparator="c"] />
> // exposes the maximal element in the collection
>
> <data:min var="min" collection="c" [comparator="c"] />
> // exposes the minimal element in the collection
>
> <data:new collection="list|map|set" [javaType="..."]>
> // creates a new List, Map, or Set
> // - javaType if specified must be compatible with collection
> // - list defaults to ArrayList, map defaults to HashMap,
> // set defaults to HashSet
> // - no 'collection' defaults to type suggested by subtags
> // (key -> Map, no key -> List)
> // - empty <data:new> tag defaults to empty ArrayList.
>
> <data:item [value="value"] [key="key"] />
> // - no 'value' attribute implies String from body
>
> <data:items collection="c"/>
>
> </data:new>
>
> <data:add collection="c" >
> // adds the items from the subtags to the collection
> // - subtags must have a key if 'c' is a Map, otherwise must not
> <data:item .../>
> <data:items ... />
> </data:add>
>
>
> ===
>
> Use cases include:
>
> <data:reverse var="backwards" collection="${forwards}"/>
> <c:forEach items="${backwards}">
> ...
> </c:forEach>
>
> ---
>
> <data:new var="new" scope="session">
> <data:items collection="${c1}"/>
> <data:items collection="${c2}"/>
> </data:new>
>
> // elsewhere in session
> <c:forEach items="${new}">
> ...
> </c:forEach>
>
> --
> Shawn Bayern
> "JSP Standard Tag Library" http://www.jstlbook.com
> (coming this summer from Manning Publications)
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Collections taglib
Posted by Henri Yandell <ba...@generationjava.com>.
On Mon, 22 Apr 2002, Shawn Bayern wrote:
> On Mon, 22 Apr 2002, Henri Yandell wrote:
>
> > Basically, why show the java implementation, why not just offer up
> > features which can be mutually compatabile. Then use Commons
> > Collections to fill in any gaps, SortedMap etc.
>
> This is an excellent idea, I think. The only important point is that the
> real Java implementation has to be consistent (and specified by us) behind
> the scenes in order to ensure interoperability with JSTL. For instance,
> if we switched to a Set without the user's knowledge, then the EL wouldn't
> be able to access numbered properties, even if the Set were logically
> 'ordered'. Perhaps it would best to avoid Set completely, as we did in
> the EL.
Losing Set's seems a pain. I think that the specification could define
'ordered' 'unique' etc so that the actual implementation just has to obey
that, which is should as they'd just be the Collections APIs.
The defaults would be the big thing(?) Laying out that ordered, indexed
list (ArrayList) should be default structure?
> > comparator="Numerical" or some such. Then the parameters in the tld
> > could list the standard comparators. These would again come from
> > Commons, but be addable to by the developers.
>
> Just out of curiosity, what do you mean by "parameters in the TLD"?
>
I was struggling to think of a place where data can be passed in to the
taglibrary. Similar to init-params for a servlet. Am realising now that
this might not exist.
Basically I was driving for some way to have configuration data outside
the taglib files, properties. Is there a standard way to do it?
Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Collections taglib
Posted by Shawn Bayern <ba...@essentially.net>.
On Mon, 22 Apr 2002, Henri Yandell wrote:
> Basically, why show the java implementation, why not just offer up
> features which can be mutually compatabile. Then use Commons
> Collections to fill in any gaps, SortedMap etc.
This is an excellent idea, I think. The only important point is that the
real Java implementation has to be consistent (and specified by us) behind
the scenes in order to ensure interoperability with JSTL. For instance,
if we switched to a Set without the user's knowledge, then the EL wouldn't
be able to access numbered properties, even if the Set were logically
'ordered'. Perhaps it would best to avoid Set completely, as we did in
the EL.
But you're absolutely right that the preliminary interface I proposed
isn't friendly enough for nonprogramming page authors. It's a great
suggestion...
> comparator="Numerical" or some such. Then the parameters in the tld
> could list the standard comparators. These would again come from
> Commons, but be addable to by the developers.
Just out of curiosity, what do you mean by "parameters in the TLD"?
Shawn
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Collections taglib
Posted by Henri Yandell <ba...@generationjava.com>.
Just a few comments that are occuring to me.
Why restrict it to collections? Why not allow it to seamlessly deal with
maps, arrays, iterators, enumerations all at the same time?
You have it specifying 'map|list|set', I've never quite got this one. Why
not:
keyed|ordered|unique
The map/list/set system completely hides the fact that these are mutually
compatible. I might want an ordered keyed collection [SortedMap/ListMap]
or an ordered unique collection [OrderedSet/TreeSet]. I might also want an
attribute with: optimise="read" or optimise="write" to help with the
choosing of the actual implementation.
Basically, why show the java implementation, why not just offer up
features which can be mutually compatabile. Then use Commons Collections
to fill in any gaps, SortedMap etc.
With comparators, it would be nice to be able to say:
comparator="Numerical" or some such. Then the parameters in the tld could
list the standard comparators. These would again come from Commons, but be
addable to by the developers.
Aside from that, I agree with James' remark about the data name. I can
live with the collection name, though I find it a bit painful.
struct!
Just kidding.
By allowing the taglib to be loose with regard to the type of structure
underneath, and by hiding the implementation with feature requests, I
think the taglib would offer up a face that didn't involve having to get
to grips with the nitty gritty, and therefore be a good thing.
Hen
On Sun, 21 Apr 2002, Shawn Bayern wrote:
> <data:copy var="new" collection="old" />
> // copies the collection, which is useful if you suspect it will change
> // or if you're going to modify it yourself
>
> <data:size var="size" collection="c" />
> // computes and exposes the size of the collection
>
> <data:sort var="new" collection="old"
> [order="ascending|descending"]
> [comparator="c"]
> />
> // sorts the collection
>
> <data:reverse var="new" collection="old" />
> // reverses the current order of the collection
>
> <data:max var="max" collection="c" [comparator="c"] />
> // exposes the maximal element in the collection
>
> <data:min var="min" collection="c" [comparator="c"] />
> // exposes the minimal element in the collection
>
> <data:new collection="list|map|set" [javaType="..."]>
> // creates a new List, Map, or Set
> // - javaType if specified must be compatible with collection
> // - list defaults to ArrayList, map defaults to HashMap,
> // set defaults to HashSet
> // - no 'collection' defaults to type suggested by subtags
> // (key -> Map, no key -> List)
> // - empty <data:new> tag defaults to empty ArrayList.
>
> <data:item [value="value"] [key="key"] />
> // - no 'value' attribute implies String from body
>
> <data:items collection="c"/>
>
> </data:new>
>
> <data:add collection="c" >
> // adds the items from the subtags to the collection
> // - subtags must have a key if 'c' is a Map, otherwise must not
> <data:item .../>
> <data:items ... />
> </data:add>
>
>
> ===
>
> Use cases include:
>
> <data:reverse var="backwards" collection="${forwards}"/>
> <c:forEach items="${backwards}">
> ...
> </c:forEach>
>
> ---
>
> <data:new var="new" scope="session">
> <data:items collection="${c1}"/>
> <data:items collection="${c2}"/>
> </data:new>
>
> // elsewhere in session
> <c:forEach items="${new}">
> ...
> </c:forEach>
>
> --
> Shawn Bayern
> "JSP Standard Tag Library" http://www.jstlbook.com
> (coming this summer from Manning Publications)
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>