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 Henri Yandell <ba...@generationjava.com> on 2003/02/06 08:58:50 UTC
[unstandard] jstl extension
Thought I'd push out the list I'm compiling of additions to the JSTL
standard in a vague library I'm calling 'unstandard' at the moment.
====================================================================
<un:catch type="java.sql.SQLException"/>
<un:instanceOf type="java.lang.Integer"/> [IfSupport I assume]
<un:collection type="java.util.ArrayList">
<un:element value="${someVar}"/>
<un:collection/>
<un:map var="foo" type="java.util.HashMap">
<un:pair key="Bob" value="${someOtherVar}"/>
</un:map>
<un:map+ var="foo">
<un:pair key="Alice" value="2282828"/>
</un:map+>
<un:map- var="foo">
<un:pair key="Alice"/>
<un:pair value="92"/>
<un:pair key="Bob" value="9191"/>
</un:map->
[Also, map+ and map- for collection. I assume map+ is illegal, my wrists
are acting up. These are an estimate of the tags that Martin Cooper
described]
<un:invoke method="foo">
<un:arg value="${el.string}"/>
</un:invoke>
[With optional var="el.string2"]
<un:invoke attribute="Person.URL"/>
[With optional var. In fact, all should have 'var' if possible]
<un:equalsIgnoreCase var="foo" lhs="${bob}" rhs="${alice}"/>
[although as this is string only, it may end up in the string taglib]
<un:finishPage/>
That's all I can think of so far. Anyone got any others?
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
Re: [unstandard] jstl extension
Posted by Dan Shields <da...@shields.org>.
I'm not exactly sure where my extension should fit into the JSTL taglib
taxonomy. They are to be considered more experiemental than most because
they rely upon and build interfaces to actively developed projects (also
Apache).
One extension is an interface to the XIndice project, including (so far)
the following two features:
1) query an XIndice server and treat the result as a Java
collection of XML documents. e.g.,
<xidc:query
var="aTerm" scope="page"
collection="xmldb:xindice:///db/fragments"
select="/Vocabulary/term[@id='${param.term}']"
/>
2) Submits an XMLDB XUpdate fragment to the XIndice server, e.g:
<xidc:update
collection="xmldb:xindice:///db/fragments" resultVar="numElems">
<xupdate:modifications
version="1.0" xmlns:xupdate="http://www.xmldb.org/xupdate">
<xupdate:append select="/Vocabulary">
<xupdate:element name="term">
<xupdate:attribute
name="id">${param.term}</xupdate:attribute>
${param.def}
</xupdate:element>
</xupdate:append>
</xupdate:modifications>
</xidc:update>
<!-- note: EL transformations are applied to the BodyContent -->
Roadmap anyone?
Cheers,
Dan.
On Thu, 6 Feb 2003, Henri Yandell wrote:
>
> Thought I'd push out the list I'm compiling of additions to the JSTL
> standard in a vague library I'm calling 'unstandard' at the moment.
> ====================================================================
>
> <un:catch type="java.sql.SQLException"/>
> <un:instanceOf type="java.lang.Integer"/> [IfSupport I assume]
> <un:collection type="java.util.ArrayList">
> <un:element value="${someVar}"/>
> <un:collection/>
> <un:map var="foo" type="java.util.HashMap">
> <un:pair key="Bob" value="${someOtherVar}"/>
> </un:map>
> <un:map+ var="foo">
> <un:pair key="Alice" value="2282828"/>
> </un:map+>
> <un:map- var="foo">
> <un:pair key="Alice"/>
> <un:pair value="92"/>
> <un:pair key="Bob" value="9191"/>
> </un:map->
>
> [Also, map+ and map- for collection. I assume map+ is illegal, my wrists
> are acting up. These are an estimate of the tags that Martin Cooper
> described]
>
> <un:invoke method="foo">
> <un:arg value="${el.string}"/>
> </un:invoke>
>
> [With optional var="el.string2"]
>
> <un:invoke attribute="Person.URL"/>
>
> [With optional var. In fact, all should have 'var' if possible]
>
> <un:equalsIgnoreCase var="foo" lhs="${bob}" rhs="${alice}"/>
> [although as this is string only, it may end up in the string taglib]
>
> <un:finishPage/>
>
>
> That's all I can think of so far. Anyone got any others?
>
> Hen
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
Re: [unstandard] jstl extension
Posted by Morgan Delagrange <md...@yahoo.com>.
--- Pierre Delisle <pi...@sun.com> wrote:
>
>
> Looks like you have lots of great ideas and it would
> be
> great to have you start a new taglib in the sandbox
> to scratch
> these itches you (and probably many others) have.
>
> +1.
>
> -- Pierre
Could you call it "nonstandard" tho? :) Just
kidding.
- Morgan
=====
Morgan Delagrange
http://jakarta.apache.org/taglibs
http://jakarta.apache.org/commons
http://axion.tigris.org
http://jakarta.apache.org/watchdog
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
Re: [unstandard] jstl extension
Posted by Pierre Delisle <pi...@sun.com>.
Hen wrote:
> > > > Thought I'd push out the list I'm compiling of additions to
> > > > the JSTL standard in a vague library I'm calling 'unstandard'
> > > > at the moment.
>
> Just to make sure I'm not being rude here, this is in no way anything to
> do with the JSTL people. By additions I mean extra tags that are not
> provided by JSTL, rather than code that I believe should go in JSTL.
We've created the sandbox to make sure we had a mechanism to
experiment with new ideas and see how useful they could be
for the community.
Looks like you have lots of great ideas and it would be
great to have you start a new taglib in the sandbox to scratch
these itches you (and probably many others) have.
+1.
-- Pierre
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
RE: [unstandard] jstl extension
Posted by Henri Yandell <ba...@generationjava.com>.
> > > -----Original Message-----
> > > From: Henri Yandell [mailto:bayard@generationjava.com]
> > > Sent: Thursday, February 06, 2003 1:59 AM
> > > To: Tag Libraries Developers List
> > > Subject: [unstandard] jstl extension
> > >
> > >
> > >
> > > Thought I'd push out the list I'm compiling of additions to
> > > the JSTL standard in a vague library I'm calling 'unstandard'
> > > at the moment.
Just to make sure I'm not being rude here, this is in no way anything to
do with the JSTL people. By additions I mean extra tags that are not
provided by JSTL, rather than code that I believe should go in JSTL.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
RE: [unstandard] EqualsTag
Posted by Henri Yandell <ba...@generationjava.com>.
On Mon, 10 Feb 2003, O'brien, Tim wrote:
> > One aspect of your implementation [from what I understand] is
> > that it'll need the standard.jar, even after 2.0 becomes the norm.
>
> This is true primarily because it uses the class
> org.apache.taglibs.standard.lang.support.ExpressionEvaluatorManager.
>
> Is there another way to accomplish this without requiring standard.jar? In
> J2EE 1.4 it appears that those facilities could be handled by
> javax.servlet.jsp.el.ExpressionEvaluator.
Ahh. Sounds good :) I'm half-expecting that unstandard will be 2.0 rather
than 1.2 dependent. Just in terms of the ease of management.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
RE: [unstandard] EqualsTag
Posted by "O'brien, Tim" <to...@transolutions.net>.
> It's probably hacky, but the ignoresCase could be considered
> 'equivalent to'. For a Float, the equivalent-to functionality
> might be to use a default error-value. Dunno.
"Tag which accepts EL attributes, and programmitically creates an EL
expression in order to piggyback off of existing code in the EL Parser".
I'm sure it's a litle confusing, but I'm unsure if this is a hack yet. I'm
sure that it is less of a hack than directly manipulating the EL engine.
> One aspect of your implementation [from what I understand] is
> that it'll need the standard.jar, even after 2.0 becomes the norm.
This is true primarily because it uses the class
org.apache.taglibs.standard.lang.support.ExpressionEvaluatorManager.
Is there another way to accomplish this without requiring standard.jar? In
J2EE 1.4 it appears that those facilities could be handled by
javax.servlet.jsp.el.ExpressionEvaluator.
--------
Tim O'Brien
> -----Original Message-----
> From: Henri Yandell [mailto:bayard@generationjava.com]
> Sent: Monday, February 10, 2003 10:17 AM
> To: Tag Libraries Developers List
> Subject: Re: [unstandard] EqualsTag
>
>
>
>
> On Mon, 10 Feb 2003, O'brien, Tim wrote:
>
> > The only reason for the class to exist is to provide a ignoreCase
> > option for string comparison. This may seem to be a small thing at
> > first, but if you need to make an equals ignore case comparison you
> > either have to implement a separate tag, customize EL by
> adding a new
> > operator, or put some Java in your JSP. I'm religious about not
> > having Java in JSP, and EL in JSTL 1.0 should remain
> untouched. The
> > only solution is to create a tag.
>
> It's probably hacky, but the ignoresCase could be considered
> 'equivalent to'. For a Float, the equivalent-to functionality
> might be to use a default error-value. Dunno.
>
> One aspect of your implementation [from what I understand] is
> that it'll need the standard.jar, even after 2.0 becomes the norm.
>
> Hen
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
Re: [unstandard] EqualsTag
Posted by Henri Yandell <ba...@generationjava.com>.
On Mon, 10 Feb 2003, O'brien, Tim wrote:
> The only reason for the class to exist is to provide a ignoreCase option for
> string comparison. This may seem to be a small thing at first, but if you
> need to make an equals ignore case comparison you either have to implement a
> separate tag, customize EL by adding a new operator, or put some Java in
> your JSP. I'm religious about not having Java in JSP, and EL in JSTL 1.0
> should remain untouched. The only solution is to create a tag.
It's probably hacky, but the ignoresCase could be considered 'equivalent
to'. For a Float, the equivalent-to functionality might be to use a
default error-value. Dunno.
One aspect of your implementation [from what I understand] is that it'll
need the standard.jar, even after 2.0 becomes the norm.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
[unstandard] EqualsTag
Posted by "O'brien, Tim" <to...@transolutions.net>.
The only reason for the class to exist is to provide a ignoreCase option for
string comparison. This may seem to be a small thing at first, but if you
need to make an equals ignore case comparison you either have to implement a
separate tag, customize EL by adding a new operator, or put some Java in
your JSP. I'm religious about not having Java in JSP, and EL in JSTL 1.0
should remain untouched. The only solution is to create a tag.
EqualsTag should "do the right thing" for non-String objects - we can't
predict what kind of objects might be passed to rhs and lhs. EL performs
some heavy lifting in
org.apache.commons.el.Coercions.applyEqualityOperator() to support equality
comparisons - coercing objects from one type to another, etc... I wanted to
be able to fallback to *that* logic if both of the arguments were not
Strings.
What may be controversial is that way I've invoked the ELParser via the
ExpressionEvaluatorManager in doStartTag - I set temp attributes on the
pageContext, and construct an EL expression. I thought that getting to the
Coercions logic via an EL expression would be preferable to having the
EqualsTag get into the details of the org.apache.commons.el package.
Keeping in mind that I didn't want to recreate the wheel in the process of
implementing what is essentially an EqualityOperator.
--------
Tim O'Brien
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
Re: [unstandard] jstl extension
Posted by Henri Yandell <ba...@generationjava.com>.
On Fri, 7 Feb 2003, Glenn Nielsen wrote:
> jakarta-taglibs-sandbox should be ready for use now. Just add a new taglib
> like you would in jakarta-taglibs (see the addtaglib.html page). I am already
> doing nightly builds of the sandbox. Once you are ready for the new taglib in
> the sandbox to be made available via the nightly build let me know.
Thanks Glenn. Seems to work fine.
I've added in the new taglib, though there's nothing there yet to build.
If anyone wants to commit or submit any tags, please go ahead.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
Re: [unstandard] jstl extension
Posted by Glenn Nielsen <gl...@mail.more.net>.
Henri Yandell wrote:
>
> On Fri, 7 Feb 2003, O'brien, Tim wrote:
>
>
>>+1 more than willing to help execute that plan.
>>
>>Also, a taglibs-sandbox would allow for the development a few different
>>versions of just this one tag and see what version generates the most
>>interest - also there is precedent for project specific sandboxes (i.e.
>>log4j-sandbox). Mayube the existence of these taglibs would help get more
>>community input into the JCP standards process.
>
>
> I'm aiming to get Glenn's [I think he created it] build system copied from
> the main taglib repository to the sandbox over the weekend. Setup the
> unstandard taglib in it. Probably try and implement the catch tag to show
> it working and invite everyone else to cram their bits in. :)
>
jakarta-taglibs-sandbox should be ready for use now. Just add a new taglib
like you would in jakarta-taglibs (see the addtaglib.html page). I am already
doing nightly builds of the sandbox. Once you are ready for the new taglib in
the sandbox to be made available via the nightly build let me know.
Regards,
Glenn
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
RE: [unstandard] jstl extension
Posted by Henri Yandell <ba...@generationjava.com>.
On Fri, 7 Feb 2003, O'brien, Tim wrote:
> +1 more than willing to help execute that plan.
>
> Also, a taglibs-sandbox would allow for the development a few different
> versions of just this one tag and see what version generates the most
> interest - also there is precedent for project specific sandboxes (i.e.
> log4j-sandbox). Mayube the existence of these taglibs would help get more
> community input into the JCP standards process.
I'm aiming to get Glenn's [I think he created it] build system copied from
the main taglib repository to the sandbox over the weekend. Setup the
unstandard taglib in it. Probably try and implement the catch tag to show
it working and invite everyone else to cram their bits in. :)
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
RE: [unstandard] jstl extension
Posted by "O'brien, Tim" <to...@transolutions.net>.
> Sorting was considered, but the EG decided to wait for a
> future release to make sure it was really needed by page
> authors and to reflect more on how we could make it easy for
> them. Would be great to have something cooked up in the sandbox.
>
> -- Pierre
+1 more than willing to help execute that plan.
Also, a taglibs-sandbox would allow for the development a few different
versions of just this one tag and see what version generates the most
interest - also there is precedent for project specific sandboxes (i.e.
log4j-sandbox). Mayube the existence of these taglibs would help get more
community input into the JCP standards process.
--------
Tim O'Brien
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
Re: [unstandard] jstl extension
Posted by Pierre Delisle <pi...@sun.com>.
Henri Yandell wrote:
...
> On Thu, 6 Feb 2003, O'brien, Tim wrote:
...
> > Also, even though commons-collections Bag class violates the collection
> > contract, I can see that being very useful in terms of a scoreboard. I'd
> > like to see a collections tag libraries dependent on commons-collections and
> > the Java 2 collections framework as a separate JSTL tag library - I find it
> > strange that Sun included a whole sql tag library, but overlooked things
> > like sorting.
One important clarification:
It is the "JSR-052 Expert Group" and not "Sun" that makes the calls
in the JSTL JSR.
> I've no clue why, but one thing about the JCP is that it's a
> committee based decision process, much like here. It could just be that no
> common-ground could be found on the implementation of the Collections
> taglib, or it could just be that it wasn't thought of, possibly because
> many collections tags are not really JSP Designer scoped things.
Sorting was considered, but the EG decided to wait for a future
release to make sure it was really needed by page authors
and to reflect more on how we could make it easy for them.
Would be great to have something cooked up in the sandbox.
-- Pierre
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
RE: [unstandard] jstl extension
Posted by Henri Yandell <ba...@generationjava.com>.
On Thu, 6 Feb 2003, O'brien, Tim wrote:
> > -----Original Message-----
> > From: Henri Yandell [mailto:bayard@generationjava.com]
> > > > <un:instanceOf type="java.lang.Integer"/> [IfSupport I assume]
>
> Unclear as to what this tag does. Did you mean
>
> <un:instanceOf type="java.lang.Integer" value="${someObject}">
> // Then conditionally execute this tag body
> </un:instanceOf>
Yeah. I missed the values on a couple of them I think.
> Seem like this should be implemented in EL:
>
> <c:if test="${variable instanceof java.lang.String}">
> // Sound the alarm
> </c:if>
>
> I checked this out and JSTL 1.0 spec, section A.4 reserves instanceof, but I
> don't see it being used. If it isn't (and excuse my ignorance, maybe this
> is something that jakarta-commons/el can take up.
That gets us into the scary land of specifications I think. EL being a JSP
2.0 specification subject.
> * map+ and map- are probably valid XML, but I find that a little confusing,
> how about mapPut and mapGet
Whatever :) I have random explosions of needs to feel like I'm coding
perl. [Did you know $myName is a legal Java variable? :) ]
> I'd say that there is almost a need for a separate collections tag library -
> if you've got a map tag, why not a set or a list tag? I could see an
> interesting use for tags that allow for unions and intersections of setsm
> access to TreeSet - subSet and tailSet.
I suspect so too. If such a new 'unstandard' library was to be created, I
would lay good odds on the collections tags escaping out. Then again,
Standard has shown that a Taglib may contain more than one TLD, so there
could just be a collections taglib inside the overall unstandard TL.
I've always felt the best way to deal with this kind of thing is to
develop it as one blob in as open a group as possible, and then before
releases to split things off as and when they're big enough and ugly
enough.
I'm generally against trying to predict sub-projects until the code has
been accumulated and a good feel may be had. I argue for the same thing
with Commons Lang, though not always with success.
> Also, even though commons-collections Bag class violates the collection
> contract, I can see that being very useful in terms of a scoreboard. I'd
> like to see a collections tag libraries dependent on commons-collections and
> the Java 2 collections framework as a separate JSTL tag library - I find it
> strange that Sun included a whole sql tag library, but overlooked things
> like sorting.
I've no clue why, but one thing about the JCP is that it's a
committee based decision process, much like here. It could just be that no
common-ground could be found on the implementation of the Collections
taglib, or it could just be that it wasn't thought of, possibly because
many collections tags are not really JSP Designer scoped things.
> > > > <un:equalsIgnoreCase var="foo" lhs="${bob}" rhs="${alice}"/>
> > > > [although as this is string only, it may end up in the string
> > > > taglib]
>
> I think that this should be moved into a string taglib, and the collection
> specific tags should be in a collections taglib.
I'm unsure if this would even be needed. The equalsIgnoreCase. It's
possible that it could be dealt with by a more generic: <un:invoke..> tag.
I don't mind it in String taglib, though I'm aiming to freeze development
changes to that for a release at the moment.
> > > > <un:finishPage/>
>
> Would this flush the buffer?
Do you want it to? :) Most of the ideas on that list came from the list
and not from me, I just tried to match them into a common naming scheme to
get a feel for what was accumulating.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
RE: [unstandard] jstl extension
Posted by Henri Yandell <ba...@generationjava.com>.
A slightly different question. JSTL has effectively end-of-the-lined many
of the Jakarta Taglibs. It may be worth looking at the ones which are in a
form of death and seeing if they have features that JSTL/[standard] do
not.
These could also be used as input into [unstandard].
Anyone heavily against that?
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
RE: [unstandard] jstl extension
Posted by Henri Yandell <ba...@generationjava.com>.
A couple of questions for [unstandard]:
JSP 1.2? JSP 2.0?
I think creating a JSP 1.1 taglib is probably not worth it. A release date
would be at least 6 months down the line, and 1.1 will be archaic then.
Create it in the sandbox or in the main taglibs repository?
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
RE: [unstandard] jstl extension
Posted by "O'brien, Tim" <to...@transolutions.net>.
> -----Original Message-----
> From: Henri Yandell [mailto:bayard@generationjava.com]
> > > <un:instanceOf type="java.lang.Integer"/> [IfSupport I assume]
Unclear as to what this tag does. Did you mean
<un:instanceOf type="java.lang.Integer" value="${someObject}">
// Then conditionally execute this tag body
</un:instanceOf>
Seem like this should be implemented in EL:
<c:if test="${variable instanceof java.lang.String}">
// Sound the alarm
</c:if>
I checked this out and JSTL 1.0 spec, section A.4 reserves instanceof, but I
don't see it being used. If it isn't (and excuse my ignorance, maybe this
is something that jakarta-commons/el can take up.
> > > <un:collection type="java.util.ArrayList">
> > > <un:element value="${someVar}"/>
> > > <un:collection/>
> > > <un:map var="foo" type="java.util.HashMap">
> > > <un:pair key="Bob" value="${someOtherVar}"/>
> > > </un:map>
> > > <un:map+ var="foo">
> > > <un:pair key="Alice" value="2282828"/>
> > > </un:map+>
> > > <un:map- var="foo">
> > > <un:pair key="Alice"/>
> > > <un:pair value="92"/>
> > > <un:pair key="Bob" value="9191"/>
> > > </un:map->
> > >
> > > [Also, map+ and map- for collection. I assume map+ is illegal, my
> > > wrists are acting up. These are an estimate of the tags that Martin
> > > Cooper described]
* map+ and map- are probably valid XML, but I find that a little confusing,
how about mapPut and mapGet
I'd say that there is almost a need for a separate collections tag library -
if you've got a map tag, why not a set or a list tag? I could see an
interesting use for tags that allow for unions and intersections of setsm
access to TreeSet - subSet and tailSet.
Also, even though commons-collections Bag class violates the collection
contract, I can see that being very useful in terms of a scoreboard. I'd
like to see a collections tag libraries dependent on commons-collections and
the Java 2 collections framework as a separate JSTL tag library - I find it
strange that Sun included a whole sql tag library, but overlooked things
like sorting.
> > > <un:equalsIgnoreCase var="foo" lhs="${bob}" rhs="${alice}"/>
> > > [although as this is string only, it may end up in the string
> > > taglib]
I think that this should be moved into a string taglib, and the collection
specific tags should be in a collections taglib.
> > >
> > > <un:finishPage/>
Would this flush the buffer?
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
RE: [unstandard] jstl extension
Posted by Henri Yandell <ba...@generationjava.com>.
Cool. Sorry I forgot it in my list.
Hen
On Thu, 6 Feb 2003, O'brien, Tim wrote:
> Again, I'll offer collection sorting as a definite need. And the code is
> attached to a previous message:
>
> <un:sort items="${anArrayOrCollection}" [property="someProperty"]
> [order="ascending"]/>
>
> --------
> Tim O'Brien
>
>
> > -----Original Message-----
> > From: Henri Yandell [mailto:bayard@generationjava.com]
> > Sent: Thursday, February 06, 2003 1:59 AM
> > To: Tag Libraries Developers List
> > Subject: [unstandard] jstl extension
> >
> >
> >
> > Thought I'd push out the list I'm compiling of additions to
> > the JSTL standard in a vague library I'm calling 'unstandard'
> > at the moment.
> > ====================================================================
> >
> > <un:catch type="java.sql.SQLException"/>
> > <un:instanceOf type="java.lang.Integer"/> [IfSupport I assume]
> > <un:collection type="java.util.ArrayList">
> > <un:element value="${someVar}"/>
> > <un:collection/>
> > <un:map var="foo" type="java.util.HashMap">
> > <un:pair key="Bob" value="${someOtherVar}"/>
> > </un:map>
> > <un:map+ var="foo">
> > <un:pair key="Alice" value="2282828"/>
> > </un:map+>
> > <un:map- var="foo">
> > <un:pair key="Alice"/>
> > <un:pair value="92"/>
> > <un:pair key="Bob" value="9191"/>
> > </un:map->
> >
> > [Also, map+ and map- for collection. I assume map+ is
> > illegal, my wrists are acting up. These are an estimate of
> > the tags that Martin Cooper described]
> >
> > <un:invoke method="foo">
> > <un:arg value="${el.string}"/>
> > </un:invoke>
> >
> > [With optional var="el.string2"]
> >
> > <un:invoke attribute="Person.URL"/>
> >
> > [With optional var. In fact, all should have 'var' if possible]
> >
> > <un:equalsIgnoreCase var="foo" lhs="${bob}" rhs="${alice}"/>
> > [although as this is string only, it may end up in the string taglib]
> >
> > <un:finishPage/>
> >
> >
> > That's all I can think of so far. Anyone got any others?
> >
> > Hen
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
RE: [unstandard] jstl extension
Posted by "O'brien, Tim" <to...@transolutions.net>.
Again, I'll offer collection sorting as a definite need. And the code is
attached to a previous message:
<un:sort items="${anArrayOrCollection}" [property="someProperty"]
[order="ascending"]/>
--------
Tim O'Brien
> -----Original Message-----
> From: Henri Yandell [mailto:bayard@generationjava.com]
> Sent: Thursday, February 06, 2003 1:59 AM
> To: Tag Libraries Developers List
> Subject: [unstandard] jstl extension
>
>
>
> Thought I'd push out the list I'm compiling of additions to
> the JSTL standard in a vague library I'm calling 'unstandard'
> at the moment.
> ====================================================================
>
> <un:catch type="java.sql.SQLException"/>
> <un:instanceOf type="java.lang.Integer"/> [IfSupport I assume]
> <un:collection type="java.util.ArrayList">
> <un:element value="${someVar}"/>
> <un:collection/>
> <un:map var="foo" type="java.util.HashMap">
> <un:pair key="Bob" value="${someOtherVar}"/>
> </un:map>
> <un:map+ var="foo">
> <un:pair key="Alice" value="2282828"/>
> </un:map+>
> <un:map- var="foo">
> <un:pair key="Alice"/>
> <un:pair value="92"/>
> <un:pair key="Bob" value="9191"/>
> </un:map->
>
> [Also, map+ and map- for collection. I assume map+ is
> illegal, my wrists are acting up. These are an estimate of
> the tags that Martin Cooper described]
>
> <un:invoke method="foo">
> <un:arg value="${el.string}"/>
> </un:invoke>
>
> [With optional var="el.string2"]
>
> <un:invoke attribute="Person.URL"/>
>
> [With optional var. In fact, all should have 'var' if possible]
>
> <un:equalsIgnoreCase var="foo" lhs="${bob}" rhs="${alice}"/>
> [although as this is string only, it may end up in the string taglib]
>
> <un:finishPage/>
>
>
> That's all I can think of so far. Anyone got any others?
>
> Hen
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org