jakarta-taglibs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glenn Nielsen <gl...@voyager.apg.more.net>
Subject Re: taglib roadmap and practices
Date Thu, 21 Dec 2000 22:08:10 GMT
"Joseph B. Ottinger" wrote:
> 
> I just put my roadmap back online, after quite some time. It doesn't
> address some critical issues that I've noticed coming up, but I'll do that
> soon. This does NOT cover everything that jakarta does, although I plan to
> skip through the docs of the jakarta taglib as well, pulling out what I
> think is useful; it's also fundamentally light on content. (This will
> change.)
> 
> The primary point here is to kickstart the JSR-052 group and hopefully get
> some real discussion going in terms of "what do we really want to be a
> standard?" instead of a simple needs-response model that we have right
> now. A needs-response model works, no doubt, but it also is limited to
> what peoples' visions are - someone might not think of a given way to use
> something, without a standard providing practices and possibilities (and
> limits.) For example, a JMS taglib would be nice... but how would it
> map? Sending a message makes sense, but setting a JSP page up as a
> subscriber (provided you don't block) doesn't make sense... and, honestly,
> even if you DO block, it doesn't make much sense.
> 
> I'd also like to see a practices model set up, where attributes' use-cases
> are clearly defined (i.e., "Should content be an attribute? Let's all say
> no." "Should configuration be an attribute? Let's say yes... and remember
> that we can't use taglibs to generate configuration information if we DO
> say yes.")
> 
> The previous parenthetical brings up an interesting point, to me: Let's
> pretend we have an SMTP tag, <mail:send />, which allows a resource to be
> used to configure the SMTP server.
> 
> <mail:send
>   smtp-server="mail.epesh.com"
>   user="joeo"
>   password="blankman"
>   to="taglibs-dev@jakarta.apache.org"
>   subject="woohoo!">
> This is a test.
> </mail:test>
> 
> Now, this is all well and good... but it's tightly coupled with MY
> application. If you take a page that uses this tag, you'll have to modify
> the page in order for it to work. Let's make it more generic:
> 
> <mail:test
>   smtp-server="<%= smtpServer %>"
>   ...>
> 
> This is nicer, but the use of <%= %> looks ugly... especially when you
> consider that we MIGHT ALSO have a tag like this:
> 
> <application:attribute name="smtpserver" default="mail.server.com" />
> 
> (As an aside: amazingly, we DO have this tag in jakarta, sans the
> default information.)
> 
> We can't use this, though, because you can't nest tags like this. However,
> if we change the mail tag:
> 
> <mail:send>
>   <mail:server><application attribute="smtpserver" /></mail:server>
>   ...
> </mail:send>
> 
> We have a easily transported set of tags and attributes, and we avoid
> scripting and internal variable extraction... we avoid Java, in other
> words, which isn't such a bad thing.
> 

I agree with the above tag design philosophy for the current JSP spec.  
And this is how I tried to design the taglibs I have written (and why my 
TLD files have each tag configured with <rtexprvalue>false</rtexprvalue>.

If an attribute is something that would be set dynamically in a JSP page 
I feel it should have a corresponding tag that sets the value using the 
tags body content.

The <jsp:setProperty ... /> is too limiting, it doesn't allow you to set
a property dynamically using body content.  This brings up the whole issue
of how to pass data between tags seamlessly. Passing property values using 
a tags body content involves alot of overhead. Other methods require 
introspection and reflection which adds overhead. There doesn't seem to 
be a good solution right now that will allow different tag sets to share
data seamlessly.

----------------------------------------------------------------------
Glenn Nielsen             glenn@more.net | /* Spelin donut madder    |
MOREnet System Programming               |  * if iz ina coment.      |
Missouri Research and Education Network  |  */                       |
----------------------------------------------------------------------

Mime
View raw message