James, what an excellent email!
You've run into a real problem: in the worst case, you're going to have a
problem indeed. Luckily, though, there are many cases where the worst case
simply doesn't happen.
For example, you mention object creation for the tags; if the same tag is
used over and over again in a given page, many JSP containers will simply
reuse previous instances. What's more, object creation isn't nearly as
expensive with HotSpot in JRE 1.3 as it was in previous incarnations of
Java.
You can, in fact, include methods in JSP snippets, but tags don't have
access (normally) to that, and while I believe you could shoehorn something
like that together, the purist in my rebels (and gags) at the thought of how
tightly coupled your JSP and your JSP tags would be. Since JSP tags are a
mechanism for loose coupling, it seems to be an intentional mutation of
purposes.
<paste>
>* <foo:loop> creates a new BodyContext object (ok the new IterationTag can
>avoid this)
This is pretty inexpensive, really.
>* all the whitespace inside the <foo:loop> gets written to the output
>(doesn't it?)
Between each tag, yes. There are ways around this (limit whitespace, use
XML/XSL to trim, etc.) but the basic problem is still there.
>* creates a new Java object for *each* case tag in *each* loop iteration
>* initialise each case tag object, calling setParent, setPageContext and
>other properties etc.
Initialization is a problem, if it's very expensive, yes. (Hint: use simple
initialization...)
>* call the necessary doStartTag() / doEndTag() methods of each tag
See the previous note.
I think your concerns are valid ones, but within the context of JSP there's
not really a great solution without breaking constraints JSP puts into
place. The best approach, IMHO, is simply to try doing it "the standard
way," and if that turns out to be a problem, THEN see if you can work out
ways to address the specific needs for your container.
>From: James Strachan <[EMAIL PROTECTED]>
>Reply-To: A mailing list about Java Server Pages specification and
> reference <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Using JSP in functions or using RunnableTags?
>Date: Fri, 9 Feb 2001 13:27:03 -0000
>
><summary>
>From inside a JSP or inside a JSP custom tag I'd like to be able to
>programmatcially call a 'block' of the JSP file using a standard Java
>function call for efficiency rather than using
>ageContext.include( "something.jsp" ), using BodyTags or hacking together
>an
>anonymous inner class. Does anyone have any ideas?
></summary>
>
><background>
>You can mix and match scriptlets (<% ... %>) and JSP code but not functions
>which seems an unnecessary limitation.
>The only way of 'calling' a block of JSP code from within a JSP file (or
>JSP
>custom tag) appears to be via the pageContext include mechanism. e.g.
>
> // in a Tag...
> // do something
> if ( someValue.equals( "'foo" ) {
> pageContext.include( "foo.jsp" );
> }
> else
>
> pageContext.include( "bar.jsp" );
> }
>
>This is a heavyweight mechanism and shouldn't be used inside large loops
>for
>efficiency reasons. Rather than just having a simple function in your
>servlet you need to move what would be in the function into a seperate JSP
>page and use a heavyweight way of calling the function
>(pageContext.include("uri")) which each time its called, must map the URI
>to
>some servlet class name using a name matching mechanism, then find an
>instance in the pool etc.
>
>Is there any way of putting a piece of JSP inside a function in the *same*
>servlet object instance, that is callable from within a JSP tag or the same
>JSP file? I'm aware of the inner class hack though I'm concerned as to how
>portable that would be across containers - making all of the implicit
>variables available in the new inner class should be something the JSP
>compiler does for you rather than a JSP / Tag author as its fiddly and a
>JSP
>compiler may generate extra variables which it requires.
>
>I'm aware of BodyTags and what they can do - a body tag is capable of
>repeatedly evaluating its body, though that can be much more inefficient
>than just calling the right bit of JSP directly. Being able to have JSP
>blocks as callable functions would be much nicer and much more efficent.
></background>
>
><example>
>Lets assume that we've got a custom tag, <foo:loop> that is some kind of
>loop that navigates some data structure and we wish to do a kind of switch
>statement on each object it finds...
>
><foo:loop>
> <foo:case value="1">
> this is value 1
> </foo:case>
> <foo:case value="2">
> this is value 2
> </foo:case>
> ...
> <foo:case value="N">
> this is value N
> </foo:case>
></foo:loop>
>
>You could say why not just do this in Java code? Well it would be nice to
>do
>it in JSP as the body of the case tags can then be JSP code and get to
>resuse the whole of JSP, using JSP custom tags etc.
>
>Now the <foo:loop> body tag could keep looping its body executing all of
>the
><foo:case> tags until one of them evaluates the right body. However this
>seems an inefficient way of doing things. For example, each iteration
>through the loop we get the following happening:-
>
>* <foo:loop> creates a new BodyContext object (ok the new IterationTag can
>avoid this)
>* all the whitespace inside the <foo:loop> gets written to the output
>(doesn't it?)
>* creates a new Java object for *each* case tag in *each* loop iteration
>* initialise each case tag object, calling setParent, setPageContext and
>other properties etc.
>* call the necessary doStartTag() / doEndTag() methods of each tag
>
>Thats a lot of work. For 1000 iterations with 10 cases in the switch
>statement, the small simple loop would construct 10,000 case tag objects -
>each of which is initalised 1000 times - per request!.
>
>It would be nice if the <foo:loop> tag could evaluate its body once putting
>the values to compare against and the case tags into some data structure
>and
>then just call the correct case tag whenever the loop tag wishes.
>
>Then each case tag just gets created and initialised once and the loop can
>iterate to its hearts content, calling case tags whenever it wishes using a
>nice, simple, efficient Java funciton call. No multiple JSP files, multiple
>servlets or unnecessary tag object constructions.
></example>
>
>
>Before I go into any more detail (sorry, this is already quite a long
>email)
>has anyone else come across this limitation and figured out a nice way
>around it?
>
>I guess what I'm getting around to is proposing a new kind of JSP tag, a
>RunnableTag whose body not executed by default but is runnable on demand by
>other tags as many times as they wish and the JSP compiler generates all
>the
>magic Java glue to make it happen for us.
>
>Any comments?
>
><James/>
>
>
>James Strachan
>=============
>email: [EMAIL PROTECTED]
>web: http://www.metastuff.com
>__________________________________________________________________
>
>If you are not the addressee of this confidential e-mail and any
>attachments, please delete it and inform the sender; unauthorised
>redistribution or publication is prohibited.
>Views expressed are those of the author and do not necessarily
>represent those of Citria Limited.
>__________________________________________________________________
>
>===========================================================================
>To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
>JSP-INTEREST".
>For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST
>DIGEST".
>Some relevant FAQs on JSP/Servlets can be found at:
>
> http://java.sun.com/products/jsp/faq.html
> http://www.esperanto.org.nz/jsp/jspfaq.html
> http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
> http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
