Donald Ball wrote:
> thanks to the patches from dims and sylvain, two huge problems with the
> xsp engine have been resolved - xsp compilation errors now show the actual
> error in the source code on the error page (whee!) and the extraneous
> calls to startPrefixMapping and endPrefixMapping have been resolved. now
> we just have to figure a way to deal with figuring out when to apply
> logicsheets. i'm beginning to think that we should not rely on namespace
> declarations, but rather have the xsp page authors indicate manually which
> logicsheets should be applied, and their order. if we do go that route,
> we'll need some way to indicate to a logicsheet if it's been applied
> before on a given page so that it doesn't re-add class-level logic,
> leading to duplicate method and variable declarations. any thoughts?
As long as we don't have circular dependencies, we should be ok. I would
prefer that mapping to be specified in "cocoon.xconf" with a "requires"
We would build a logicsheet Set that would be applied by iterating through
the required logicsheets, and adding the ones that are required if they
aren't already added.
(I don't know if any of the Java Set classes preserve natural ordering, so
I would implement with a List and do manual checks with the contains() method).
So if I had an XSP page that was specified like this:
The engine would apply the sheets in this order:
How do we determine the order?
1)The core-logicsheet is ALWAYS applied last (so we
don't add it to the list until the end).
2)The logicsheet engine then adds the next namespace
received ("xsp-request"). This is inserted into the
3)The logicsheet engine then sees that "foo" has two
requirements: "xsp-request" and "esql".
3.1) The logicsheet engine checks to see if the required
logicsheets are already in the list.
3.1.1) If they are in the list, get it's index.
3.1.2) If not, add it to the list (and and get it's index)
3.2) Compare the indexes of the required logicsheets,
and insert this logicsheet reference before the lowest
Please note that step 3 is a recursive process.
The only problem comes from circular dependancies.
To unsubscribe, e-mail: email@example.com
For additional commands, email: firstname.lastname@example.org