jakarta-taglibs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joseph B. Ottinger" <j...@suninternet.com>
Subject RE: taglib roadmap and practices
Date Thu, 21 Dec 2000 19:02:01 GMT
On Thu, 21 Dec 2000, Scott Stirling wrote:

> In re to best practices, I agree totally.  Declaring some of the general
> principles underlying good tag language programming is a must for JSR-052.
> 
> For your particular example, I have some thoughts.  Compare this mail tag
> with the one below it:

I'm going to pick up the conversation here, leaving the rest of it intact
at the bottom for reference. I don't have the jsr-052 list address handy,
or I'd send it there too.

I agree as far as the coding target - the attributes are familiar, they're
easier, they're shorter, they're far less likely to alienate those who are
only HTML programmers and yet don't use tools to generate
everything. However... I don't think an additional variable addressing
scheme is good for JSP (<mail:send to="$recipient">..</mail:send>),
although that *does* address one aspect of the need.

The most direct solution is to relax the ability to use tags inside
attributes where rtexprvalue is true; to wit: 

<mail:send
  to="<jsp:getProperty name="recipient" property="email" />"
  ...
>
  ...
</mail:send>

The next solution is the one that we have in front of us, without
modifying the spec: we aim for those most likely to use JSP, the ones who
won't necessarily balk at using subsidiary tags. There is no doubt that
attributes are easier, but we also have to consider what we're trying to
fix.

> 
> <%-- Mail tag: take 1 --%>
> <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>
> 
> <%-- Mail tag: take 2 --%>
> <mail:send>
>   <mail:server><DEFANGED_application attribute="smtpserver" /></mail:server>
>   <mail:user>joeo</mail:user> 
>   <mail:password>joeo</mail:password> 
>   <mail:to>taglibs-dev@jakarta.apache.org</mail:to>
>   <mail:subject>woohoo!</mail:subject>
>   This is a test.
> </mail:send>
> 
> Take 1 is going to be a lot easier for anyone to code by hand.  It also
> follows the idioms of HTML more closely (which I think is a good thing; even
> with XHTML, the nice thing is that HTML doesn't need name-space prefixes).
> Take 2 is much more XML oriented, and would be a nightmare to code with
> anything other than a tool that did it all via a wizard of some sort.  So
> one question I have is whether an approach like this will alienate or
> handicap the users who code this stuff "by hand" in an editor.
> 
> The way most HTML coders and JavaScript/ASP scripters work (those who get
> their hands dirty and don't use Frontpage's or Homesite's WYSIWYG feature),
> is by modifying the code in pages themselves, and using tricks like CSS and
> SSI to enable reuse of templates and abstraction of custom presentation
> information.  They're accustomed to modifying pages and ripping other
> people's pages off (thanks to "view source") and tailoring them for their
> own uses, etc.  So while keeping attributes and expressions off the page and
> thereby pleasing Java programmers who are concerned about clean design, we
> might upset the HTML/JSP coder/scripter who is more comfortable with
> expressions and attributes on the page where he can see them and change them
> in place.
> 
> If custom scripting variables could be used as attribute values without
> having to use them as expressions, that would give us another cleaner
> alternative.  A standard prefix would work, or even a prefix specified at
> the taglib level.  For example, take 2 instead of take 1 below:
> 
> <%-- take 1: old way --%>
> <mail:send 
> 	smtp-server="<%= smtpServer %>"
> .....
> 
> 
> <%-- take 2: proposed way --%>
> <mail:send 
> 	smtp-server="$smtpServer"
> .....
> 
> This would require the JSP parser to recognize the "$" as a scripting
> variable defined for the taglib corresponding to the mail name-space, and
> process it as an expression.
> 
> Scott Stirling
> Allaire Corporation
> 
> 
> > -----Original Message-----
> > From: Joseph B. Ottinger [mailto:joeo@suninternet.com]
> > Sent: Thursday, December 21, 2000 11:09 AM
> > To: taglibs-dev@jakarta.apache.org
> > Subject: taglib roadmap and practices
> > 
> > 
> > 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:
> > 
> > <DEFANGED_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><DEFANGED_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.
> > 
> > -----------------------------------------------------------
> > Joseph B. Ottinger                           joeo@epesh.com
> > http://epesh.com/                             IT Consultant
> > 
> 

-----------------------------------------------------------
Joseph B. Ottinger                           joeo@epesh.com
http://epesh.com/                             IT Consultant


Mime
View raw message