Return-Path: <glenn@voyager.apg.more.net>
Mailing-List: contact taglibs-dev-help@jakarta.apache.org; run by ezmlm
Delivered-To: mailing list taglibs-dev@jakarta.apache.org
Received: (qmail 54999 invoked from network); 21 Dec 2000 22:07:47 -0000
Received: from galen.earthdome.org (HELO zathras.earthdome.org)
 (206.152.117.245)
  by locus.apache.org with SMTP; 21 Dec 2000 22:07:47 -0000
Received: from voyager.apg.more.net (localhost [127.0.0.1])
	by zathras.earthdome.org (8.9.3/8.9.2) with ESMTP id QAA36621
	for <taglibs-dev@jakarta.apache.org>; Thu, 21 Dec 2000 16:08:10 -0600 (CST)
	(envelope-from glenn@voyager.apg.more.net)
Sender: glenn@zathras.earthdome.org
Message-ID: <3A427F4A.111621D9@voyager.apg.more.net>
Date: Thu, 21 Dec 2000 16:08:10 -0600
From: Glenn Nielsen <glenn@voyager.apg.more.net>
X-Mailer: Mozilla 4.74 [en] (X11; U; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: taglibs-dev@jakarta.apache.org
Subject: Re: taglib roadmap and practices
References: <Pine.LNX.4.21.0012211051140.32472-100000@cupid.suninternet.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N

"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  |  */                       |
----------------------------------------------------------------------