Mr Chung,
I agree completely with your proposed change. Two arrays is all right
for me.
On Fri, 17 May 2002, Kin-Man Chung wrote:
> This way, the size of the stack is the maximum number of nesting of the
> tags, which should much smaller than the number of tags in the page.
> Such information is easy to collect in Jasper 2, which can be
> done either in Validator.java, or we have a separate pass whose sole
> purpose is to collect info such as this.
Now, about the level of nesting, shouldn't the information be available
through the PageInfo object? After all, the purpose of this class is
"A repository for various info about the page under compilation". And
Generator currently has access to an instance of it. So, if PageInfo
had something like a "public int getTagElementsMaxNestingLevel()" method,
Generator could use it to allocate the arrays.
We have two changes on the table:
1. Get the information about the level of the nesting with Visitor, or a
separate pass;
2. Remove the "finallies" and replace it with the "two state arrays";
For #2, I'm confident that I could do it without problem. For the #1, well,
I've taken a quick look at Visitor, but the change seems to me far less
obvious.
The way I see it, in the constructor we initialize the nesting to zero.
Each time:
"public void visit(Node.CustomTag n) throws JasperException"
is called we increment the nesting, and right after the call "visitBody(n);",
just before the method terminate we decrement the nesting count.
Obviously, we must keep track of the maximum depth level. The information
is ready to be used at the end of the:
"public static void validate(Compiler compiler, ..."
method, this is the one that initiates the visit(XXX) calls, right?.
Would you like me to propose a patch for #1? For #2? And what about having
the maximum CustomTag nesting depth level available through PageInfo?
Thanks!
--
Denis Benoit
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
