> > 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. >
Yes, the information will be available throught PageInfo object, and which is updated in either Validator or Collector (I just make this up). > 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? > I'll implement maximum tag nesting (though PageInfo) and you can work on #1. Deal? > Thanks! > Thanks. > -- > Denis Benoit > [EMAIL PROTECTED] > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
