You are viewing a plain text version of this content. The canonical link for it is here.
Posted to taglibs-user@tomcat.apache.org by Matt Raible <ma...@raibledesigns.com> on 2002/04/25 19:41:17 UTC
doesn't seem to work w/ beta 2
With the beta 2 release, the following doesn't work:
<c:out value="${request.myAttribute}"/>
However, this does:
<c:out value="${myAttribute}"/>
Is this "as designed" and if so, is this an efficient way - I'd rather
search the specific scope, probably more efficient.
Thanks,
Matt
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: why jstl???
Posted by Henri Yandell <ba...@generationjava.com>.
I think you have hit on the crux of the matter. There are some new
features in JSTL, such as the whole expression language thing, but
generally JSTL seems to be a merging together of various taglibs with
varying levels of similarity.
So why is it there?
Think of it as there being an acceptance that some of the Jakarta taglibs
are a good thing. This being so, a JSR to standardise these so that you
can always expect them to exist and to raise their importance in the whole
JSP architecture of J2EE is what I believe has happened.
The JSTL is a specification of a taglib that I imagine every web container
will support at one time or another. At some point, I would expect Tomcat
to come bundled with the JSTL you are currently using. Websphere may write
their own, or just reuse the Jakarta one.
There are many other taglibs out there which are similar to the Jakarta
ones, so part of it is also to provide a nice standard so that programmers
and designers can work with them more easily.
The questions tend to focus on two areas.
1) Expression language issues. This is a new thing and people often have
problems with this.
2) Differences between JSTL and an existing Jakarta taglib. The sql tags
seem to be the most common.
I think it will be interesting to see what happens with the 1.1 taglibs
that do the same thing as the JSTL. When we're all on 1.2 containers, will
these taglibs deprecate or stay. Are their authors pushing to get
functional compatibility with JSTL? [I believe so], that is, make the JSTL
spec as good as their taglib.
Users of JSTL? Is this easy to tell? When a designer is using a JSP, do
they tend to do so without having a developer handling the setting up of
it and any posts to the mailing list.
I might be being unfair, but my definition of designer does not include
someone who installs and admins Tomcat, and there are few web companies
using JSP on a small scale through a hosting company. So I would think
that even if designers are using JSP, we'lll mainly see developers here.
The best things about JSTL to me is that it provides a standard way to
write a taglib. I hope that all Jakarta taglibs will follow its lead in
clearly defining TagSupport extensions and offering a 'var' attribute in
every tag.
Hen
[I'm not linked with the JSTL by the way, these are independent, from the
sidelines views]
On Thu, 25 Apr 2002 keesj@framfab.nl wrote:
> Hi,
>
> I am just wondering. since the jstl was anounnced
> more and more question are asked about session/array/object/result
> sets,iterrator etc..
>
> who is using jstl? (programers or web-designers)?
> and why?
> I understand struts(MVC). but I realy have no clue why to use something
> like jstl and why it's on the list. isn't jstl a remake of moost of the
> jakarta taglibs and should thoose questions belong on this list?
> can somebody help me understand please?
>
> greets
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
why jstl???
Posted by ke...@framfab.nl.
Hi,
I am just wondering. since the jstl was anounnced
more and more question are asked about session/array/object/result
sets,iterrator etc..
who is using jstl? (programers or web-designers)?
and why?
I understand struts(MVC). but I realy have no clue why to use something
like jstl and why it's on the list. isn't jstl a remake of moost of the
jakarta taglibs and should thoose questions belong on this list?
can somebody help me understand please?
greets
On Thu, 25 Apr 2002, Shawn Bayern wrote:
> On Thu, 25 Apr 2002, Matt Raible wrote:
>
> > With the beta 2 release, the following doesn't work:
> >
> > <c:out value="${request.myAttribute}"/>
looks like c++ to me :)
--
Kees Jongenburger.
Perfection is achieved not when you have nothing more to add,
but when you have nothing left to take away.
-- Antoine de Saint-Exupery
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: doesn't seem to work w/ beta 2
Posted by Shawn Bayern <ba...@essentially.net>.
On Thu, 25 Apr 2002, Matt Raible wrote:
> So what you're saying is that <c:out value="${myAttribute}"/> is the
> recommended syntax. I can live with this, but is <c:out
> value="${requestScope.myAttribute}"/> more efficient?
It depends on the container; on Tomcat, it very well might be more
efficient.
--
Shawn Bayern
"JSP Standard Tag Library" http://www.jstlbook.com
(coming this summer from Manning Publications)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: doesn't seem to work w/ beta 2
Posted by Matt Raible <ma...@raibledesigns.com>.
So what you're saying is that <c:out value="${myAttribute}"/> is the
recommended syntax. I can live with this, but is <c:out
value="${requestScope.myAttribute}"/> more efficient?
Thanks,
Matt
P.S. Loving JSTL ;)
> -----Original Message-----
> From: Shawn Bayern [mailto:bayern@essentially.net]
> Sent: Thursday, April 25, 2002 11:47 AM
> To: Tag Libraries Users List; matt@raibledesigns.com
> Subject: Re: <c:out value="${scope.value}"/> doesn't seem to
> work w/ beta 2
>
>
> On Thu, 25 Apr 2002, Matt Raible wrote:
>
> > With the beta 2 release, the following doesn't work:
> >
> > <c:out value="${request.myAttribute}"/>
> >
> > However, this does:
> >
> > <c:out value="${myAttribute}"/>
> >
> > Is this "as designed" and if so, is this an efficient way -
> I'd rather
> > search the specific scope, probably more efficient.
>
> The short answer is "request was changed to requestScope".
>
> The longer answer is that you really should, in most cases,
> treat all scopes as a single namespace. But there are
> situations where you only want to retrieve a value if it
> comes from a specific scope -- hence the top-level objects.
> They've been renamed to pageScope, requestScope,
> sessionScope, and applicationScope, as described in the PFD spec.
>
> --
> Shawn Bayern
> "JSP Standard Tag Library" http://www.jstlbook.com
> (coming this summer from Manning Publications)
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: doesn't seem to work w/ beta 2
Posted by Shawn Bayern <ba...@essentially.net>.
On Thu, 25 Apr 2002, Matt Raible wrote:
> With the beta 2 release, the following doesn't work:
>
> <c:out value="${request.myAttribute}"/>
>
> However, this does:
>
> <c:out value="${myAttribute}"/>
>
> Is this "as designed" and if so, is this an efficient way - I'd rather
> search the specific scope, probably more efficient.
The short answer is "request was changed to requestScope".
The longer answer is that you really should, in most cases, treat all
scopes as a single namespace. But there are situations where you only
want to retrieve a value if it comes from a specific scope -- hence the
top-level objects. They've been renamed to pageScope, requestScope,
sessionScope, and applicationScope, as described in the PFD spec.
--
Shawn Bayern
"JSP Standard Tag Library" http://www.jstlbook.com
(coming this summer from Manning Publications)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>