Berin Loritsch a écrit :
>
> Sylvain Wallez wrote:
>
> >
> > There's a CPU/memory eater in ServerPagesGenerator : each startElement
> > is stored in a stack in order to properly close all opened elements in
> > case of premature end of the XSP (return statement or exception). Cocoon
> > 1 didn't have this because of the use of DOM : even if partially
> > generated, the DOM is always a valid XML document.
> >
> > This stack is a LinkedList to which EventData objects are appended. This
> > means for each element, 2 objects are allocated : the EventData object,
> > and a LinkedList node. We can change this stuff to use a single
> > ArrayStack (from excalibur.collections) and no EventData object, which
> > should significantly reduce CPU consumption.
> >
> > But the real question is : can an XSP be considered valid if it contains
> > a "return" statement ? I personnaly never saw such XSPs. Also, this
> > stuff is only a half protection against bogus code in the XSP : it will
> > take care of having as much closed elements as opened ones, but doesn't
> > check proper balancing nor do anything for constructs like a "break" in
> > a loop inside an XML element.
> >
> > So my opinion is remove this costly stuff and forbid return statements
> > in xsp:logic. This will make a speedy XSP engine.
> >
> > Your thoughts ?
>
> Before you throw out the baby with the bath water, we have to consider the
> creation of methods in XSP. If a method is created by the <xsp:logic>
> section outside of the root element, then you must allow a return statement.
Poor baby ;)
> for example:
>
> <xsp:page>
> <xsp:logic>
> /** should be legal */
> private int getUserId() {
> return ((Integer) request.getSession().getAttribute("userid")).intValue();
> }
> </xsp:logic>
>
> <mypage>
> <xsp:logic>
> int userid = getUserId();
> return; // should be Illegal
> </xsp:logic>
> </mypage>
> </xsl:page>
>
> Do you notice the key distinction?
>
Sure, and I was aware of that : by "forbid return statements", I was
meaning an XSP writing guideline (coding standard) saying not to use a
return statement to break the normal control flow, and not a rule
enforced by the engine : this would be difficult to implement, since it
would require a Java parser. The return statement at the end of a method
doesn't break the flow and is thus perfectly legal.
Sylvain
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
