"Craig R. McClanahan" wrote:
>
> On Sat, 16 Jun 2001, Casey Lucas wrote:
>
> >
> > [EMAIL PROTECTED] wrote:
> > >
> > > On Fri, 15 Jun 2001, Casey Lucas wrote:
> > >
> > > >
> > > > Costin,
> > > >
> > > > sounds good.
> > > >
> > > > btw, when do you think the generator code in 34 will settle down
> > > > a little?
> > >
> > > Soon :-)
> > >
> > > There is only one more change in the generator layout - switching to
> > > a "visitor" pattern, with the tree representation of the page separated
> > > from the actual generator.
> > >
> > > If you are thinking to tagpool changes - please wait until RuntimeLiaison
> > > gets a bit of shape, I would like to provide some hooks for the container
> > > to control the pools. Again, the idea is to allow a "toolkit" model, where
> > > different components can be plugged in.
> >
> > ok. just let me know when you think it's appropriate to
> > start adding some tag optimizations.
> >
> > > Separating tree is very important to allow modules to do various
> > > optimizations ( like replacing common tags with equivalent in-line java
> > > code ) and to do the direct bytecode generation.
> >
> > regarding "replacing common tags with equivalent in-line java code": what
> > exactly did you have in mind?
> >
>
> Jasper already understands what things like <jsp:useBean> do, and it
> generates specialized code to implement the required functionality (rather
> than treating it like a custom tag).
right. i thought he might be refering to custom tags. that's where my
concern was. for the standard stuff, i'm sure we can inline / optimize
plenty.
>
> With the advent of the JSP Standard Tag Library (being designed by the
> expert group on JSR 52), there will be a much larger number of tags that
> are suitable for this type of analysis -- things like conditional and
> iteration tags, where you can generate much more efficient native Java
> code instead of all the overhead of calling a regular custom tag.
>
> > -casey
> >
>
> Craig
