jakarta-taglibs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <james_strac...@yahoo.co.uk>
Subject Re: XSL TagLib
Date Thu, 06 Dec 2001 06:01:30 GMT
From: <crazybob@crazybob.org>
> My intention was not to be harsh, just truthful. If the existing tag
libraries had fit my needs as a developer, I would have used them rather
than write my own.I think that's the spirit of OS. I apologize if I hit a

No problem.

> > Remember JSPTL is a common standard - it doesn't attempt to do
> > for every use case - so some issues such as caching of output or of
> > transformers have not been addressed yet, but can be plugged in using
> > tags or beans.
> I'm trying to propose a more "standard-esque" api. I consider the target
audience to be a typical JSP developer. I didn't find the JSPTL's api to be
intuitive from a JSP developer's perspective.
> First, the "id" param creator and "name" param accessor (as you see in the
useBean tag) seems to have become a pretty standard convention. Is there a
reason that the JSPTL uses this "var" param? I found it confusing at first.

I think the 'var' param just defines a page scope attribute - it doesn't
create a scriptlet variable.

> > > Unlike the JSPTL, my library hides the details of Transformer caching
> > > reuse.
> >
> > This can be viewed as a good and bad thing.
> This is nothing but a good thing.

There are other ways of caching. e.g. the Maverick project has a controller
that looks after all the Transformer objects. There could be other ways of
doing it, such as using an i18n mechanism to find the corrent Transformer.
So JSTL allows any kind of Transformer caching to be used.

Though I take your point that its nice having an integrated caching
mechanism so page authors don't have to worry about this stuff.

> There is no reason a JSP developer should ever have to worry about
Transformer caching. If you want to plug in a different implementation, you
should configure it in the the web.xml or somewhere else equally

I agree - I'd like some kind of Transformer caching mechanism in JSTL.
Though there's a bunch of other stuff I'd like in JSTL too; its more a
question of time & priorities.

> > Your Transformer caching could complement the JSTL very nicely indeed.
> > are various ways in which a Transformer could be cached. You've
> > one way which is great. There are other ways to do it - e.g. the
> > servlet might take care of that.
> This logic does not belong in a controller servlet either.

Why not? What if the Transformer is chosen based on the user, the
user-agent, the Locale of the browser etc. So a controller servlet could
have found the correct Transformer and made it available as a page/request
scope attribute. Take a look at Cocoon or Maverick, they do similar things.

> > If you were to wrap up your transformer caching logic into a tag it
could be
> > reused with the JSTL tags.
> Why not just access my factory, specify the stylesheet URL as a param, and
not worry about caching at all? There's no need to cache Transformers in the
pageContext, nor pollute other tags with unnecisary logic.

I agree some default caching mechanism would be nice.

> I had a look at OSCache. OSCache provides a variety of other tools,
however the taglib is comparable. Their tag interface is a little more
invloved, but you get the same amount of functionality. In regard to
performance, there's not much you could do to best my implementation.
> I do agree that the cache tag would be better served in a separate

Agreed. I'd be nice if we could have some kind of caching tags in
jakarta-taglibs (and ultimately in JSTL).

I'm hoping the JCache API (JSR 107) completes soon (though Oracle seem to be
stalling it a bit) then all the caching ideas & tags could use this same
single API to implement caches - then management & monitoring tools can be
developed to monitor & control the cache sizes etc.


Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

To unsubscribe, e-mail:   <mailto:taglibs-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:taglibs-dev-help@jakarta.apache.org>

View raw message