Shawn Bayern

When designing JSTL, we wanted to avoid tying it to a particular presentation technology; JSTL is not specific to HTML, WML, etc. Had XForms been more widely understood and solidified, the expert group might have added support for it in some fashion, but the timing wasn't right for JSTL 1.0.
More generally, supporting HTML forms isn't really the job a general-purpose taglib; it's more a function of a particular framework (like Struts) that you might use to develop individual applications.
Shawn

I agree. To add to that, JSTL is analogous not to Struts but to Struts's custom tag libraries. The long-term plan for Struts is for it to simply adopt JSTL's tags and deprecate its custom tags; this meshes nicely with Struts's trend toward focusing on controller operation and not on the details of the view.

Thanks for the recommendation!
The issue here is between scripting variables and scoped attributes, which we call "scoped variables" in JSTL. The JSTL EL doesn't give you access to scripting variables, so if you create a variable in a scriptlet, you need to expose it either with <jsp:useBean> or with code like

<% pageContext.setAttribute("foo", foo); %>
Hope that helps!

Just a quick clarification - JSTL 1.0 supports the 'empty' keyword, so you don't have to wait for JSP 2.0 to use it.
JSP 2.0's major new feature is that it lets you use the EL anywhere -- in template text, custom tags, and so forth.
"HTH"

Originally posted by Axel Janssen:
Hi,
first a 3x thank you for Shawn Bayern:
1. JSTL is very clear and easy to use
2. Your book is very clear and easy to use (I think even for pure dhtml-designers)
3. JSTL really speeds me up

Hi Axel. Thanks for the note - I'm glad you're finding JSTL and JSTL in Action useful.

I have 2 questions:
1. There is no String concenating in JSTL?
When I try something like:
<c:out value="${entry.cat_name + 'something completly different, but a String'}"/>
it seems to expect double values for doing adition of numbers.

Right - there's no reason for that kind of concatenation. Instead, simply use two back-to-back <c:out> tags.

2. Is it possible to escape " or '?
When I tried to dynamize some javaScript calls to build one of those fancy dhtml-navigators, it didn't work first, when I tried something similar to this:
<c:out value="${'addParent(\"a name\")'}"/>
I managed those problems by concenating the Strings I need for the javaScript in the Bean and using the very important escapeXml="false" parameter.

You can escape quotation-mark characters, though it's probably going to be easier simply to use a <c:out> tag only to print your dynamic data -- and simply keep your static data in template text.
Hope that helps; please let me know if you have any followup questions.

Originally posted by Eric Savage:
Two questions.
First, in JSTL, how does one get the size of a map/collection/etc. This seems such a common thing that I'm sure it must be somewhere but I can't find it.

Actually, JSTL 1.0 doesn't provide this; JSTL 1.1 will most likely introduce a function to support it.
In the meantime, you can either (a) provide a wrapper class with methods like getSize() and getArray(), or (b) simply loop over the array and compute its size with <c:forEach>'s 'varStatus' attribute. However, the latter option isn't particularly efficient.

User.getTickets() returns a Hashtable. I also tried extending Hashtable and adding the following:
public int getSize() { return size(); }

A wrapper class will work in general, but an object's nature as a Map occludes its nature as a JavaBean for JSTL's purposes. That is, when an object is a Map, only its Map elements -- not its JavaBean properties -- will be returned.

[/QB]
Second, how does one reference a static property in JSTL. Something like the following:
<a href="sort.jsp?FIELD=<%= MyObject.NAME_FIELD">sort</a> [/QB]

[/QB]
The EL is intended only to refer to instance variables, not static data. You could expose a bean that returns the right values for particular constants, or use context-initialization parameters defined in web.xml.

I agree with Simon -- as did the JSTL expert group. We couldn't come up with a compelling reason to introduce a <c:while> tag.

Originally posted by Sankar B:
[QB]Hi,
What yar. Then u might've provided to declare variable in JSTL and use it without making it as an scoped attribute. Cos, declaring variables are just used for some temporary operations within that page.

I think you're fundamentally misunderstanding the way that JSP works. It is not possible for a tag to read a scripting variable. JSTL could not have done anything in this regard; it's structurally impossible based on the way that JSP compiles pages into Java servlets.
What is wrong with converting a variable into a scoped attribute? It takes a single line of code and incurs an extremely minor runtime cost.

Or, Is there any option to declare variables in JSTL and use it without making it as an Scoped Attribute ?
Ex: int x,y; String myString; like this. But, without making it as a scoped attribute.

You can take care of both at once with a single <jsp:useBean> tag, whether you're using a bean or not; e.g., <jsp:useBean> works with Strings.
You may want to go back to first principles and read the JSP and JSTL standards.

Blanks (" ") are not valid in URLs. You must encode the parameter. If you use the standard <c:out> tag instead of a scripting element, the information will be encoded automatically.

Originally posted by Sankar B:
So, we fear whether we can utilise JSTL or stick with JSP itself or switch over to JSF when its released.

Faces isn't designed to operate in precisely the same space; it doesn't replace either JSTL or scriptlets. JSTL, however, is designed to replace scriptlets (in concert with JSP 2.0's features).

You can also use the standard JSTL <c:import> tag in your JSP pages to import a relative or absolute URL.

Originally posted by Harpartap Singh:
But, I thought another advantage of using <c:import> was that you are not bound to "relative URL" anymore.
So if there was a [B]<c:forward>[B] we could forward requests to another web application's URL without having to go through the circus of getContext, getRequestDispatcher, forward etc.
Isn't convenience a motivation for JSTL?

It's a judgment call. That would be the only motivation for a <c:forward> tag, and cross-context imports and forwards aren't necessarily even supported by all containers. (It's effectively an optional feature.) With the <c:import> tag, we get the benefit of imports from absolute URLs, as well as cross-context inclusions; this wouldn't apply to <c:forward>. Effectively, the decision implies that the JSTL group thinks the combination of <jsp:forward> and <c:redirect> is enough for most people. Still, a <c:forward> tag could always be added in the future (or <jsp:forward> modified) to support cross-context forwards.
Convenience is indeed a motivation, but as with any spec, you have to pick your battles carefully because (a) time is limited and (b) extra features mean more learning for new users.

When one calls a bean in a "session" does this line class="simplebean.lineBean"
create an instance of the bean???

If <jsp:useBean> finds an existing bean, it simply uses it. Otherwise, with the 'class' attribute, it creates a new one.

If I want to use the same bean in another JSP page would I use the same "beanid" and thus the same code line "<jsp:useBean class="simplebean.lineBean" id="bean0" scope="session" />"?

Yes, that's fine.

Yes, your understanding is correct. Specifically:

1. In the included file the RenderTag is instantiated again. It instantiates a NEW RenderTag object. CORRECT?

Yes. Note that this has very little to do with whether there are inclusions, forwards, or anything else. The key concept is that while the JSP specification permits a container to reuse instances of tag-handler implementation classes, the same instance can never be reused while it's currently being called by an invocation. If you had
<a:b>
  <a:b/>
</a:b>
in a single page, this would necessitate two different instances of the handler for <a:b>. The situation you're describing is just a more elaborate version of this same situation, as far as tag-handler lifecycles are concerned.

2. But since this included file is a NEW jsp file, it has its own NEW pageContext

Yes, specifically true.

but calling pageContext.getAttribute(section,REQUEST_SCOPE), should retrieve the ORIGINAL section/content pair that I had stored in the outside files pageContext. I believe this is the case, because the included file did get the SAME request object, and the stored section/content pair of values came with it. CORRECT?

Exactly. "Request scope" travels with (and in fact is identical with and implemented in terms of) the ServletRequest object. Request scope is specifically intended for situations where you want data to traverse multiple pages that are all used to respond to a single web request: that is, inclusions and forwards.
Hope that helped, and thanks for the interesting questions!
[ September 24, 2002: Message edited by: Shawn Bayern ]

You must convert them into scoped attributes by using
<% pageContext.setAttribute(..., ...); %>