Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Message-ID: <38066909.3C58363B@eng.sun.com>
Date: Thu, 14 Oct 1999 16:36:41 -0700
From: Eduardo Pelegri-Llopart <pelegri@eng.sun.com>
MIME-Version: 1.0
To: tomcat-dev@jakarta.apache.org
Subject: jsp:includes...
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Talin@brodia.com says...

> jsp:include is a static inclusion. The included text becomes part of the
> same java class as the overall page.

There is an include directive, for which this is true, and an include
action. Include actions act at request-time, take arguments, and, from
my quick scan, are quite close to what you are describing.

Include actions' parameters (jsp:param) are subelements, but you can
write your own tag library that will take the arguments as attributes.

> Of course, we've made a significant departure from the JSP model in
> order to do this. For one thing, the Java classes that components are
> compiled into are not descended from "Servlet", but have their own base
> class. The reason for this is the need to pass arguments into the
> component. 

I'm not sure why you need this, you can pass the "arguments" in several
different ways.

> Another reason is that we buffer the output of the page
> generation before committing it to the socket, so that a component can
> add headers or do redirects, which can't be done if we've already sent
> some content to the client.

JSP 1.0 and JSP 1.1 do buffering for this exact reason.  Unfortunately,
due to scheduling issues, the underlying Serlvet machinery does not
allow portbable transfer of the buffer across a
RequestDispatcher.include(), which means that we have to flush at this
boundary.  This is a major problem and it *will* be fixed for the next
release of the specs.

> ... stuff about the problems encountered in makign true a vision of "components" at the page level

Hear, hear!  There is a fair amount of stuff that needs to be done.  We
are pretty close to making tag libraries real components that can be
shared and build upon, but doing the same for "pages" still needs work
on several issues.  I hope we can address these for the next JSP/Servlet
rev.

=====

> Maybe the prudent thing to do is to protest sun to get this put into the
> next version of the Jsp spec. if it does not already exist.
> 
> -ScottTavares-

I'm all for this, although I'd have used a different verb instead of
"protest" :-).  I believe we have been very receptive to the community
feedback.  We are in an unusual situation: we win when everybody wins. 
Sometimes we cannot keep everybody happy, but we really believe that
there is a lot of wisdom in the community and we try to channel it.

If you are interested in participating, drop me mail
(pelegri@eng.sun.com).  We are starting to pool resources and organize
ourselves for the next batch of specs.  I'd prefer to start collecting
requirements and start outlining the big picture for a while before we
go in earnest on the details.  That matches well with the scheduling
needs of Jakarta and J2EE, so this is good.

Hope this helps,

	- eduard/o