You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Donald Ball <ba...@webslingerZ.com> on 2001/04/12 21:28:49 UTC
[c2] xsp engine changes
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?
- donald
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [c2] xsp engine changes
Posted by Davanum Srinivas <di...@yahoo.com>.
Berin,
Just checked in changes to add logic sheets recursively. Please give it a shot. But i have not
taken care of circular dependencies.
Thanks,
dims
--- Berin Loritsch <bl...@apache.org> wrote:
> 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"
> configuration element:
>
> <builtin-logicsheet>
> <parameter name="prefix" value="foo"/>
> <parameter name="uri" value="http://apache.org/xsp/foo"/>
> <parameter name="href" value="context://WEB-INF/logicsheets/foo.xsl"/>
> <requires>
> <logicsheet uri="http://apache.org/xsp/request"/>
> <logicsheet uri="http://apache.org/xsp/sql/v2"/>
> </requires>
> </builtin-logicsheet>
>
> 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:
>
> <?xml version="1.0"?>
>
> <xsp:page language="java"
> xmlns:xsp="http://apache.org/xsp"
> xmlns:xsp-request="http://apache.org/xsp/request"
> xmlns:foo="http://apache.org/xsp/foo"
> >
>
> <page>
> <header><title><xsp-request:get-parameter name="foo-title"/></title></header>
> <foo:get-bar name="foo"/>
> </page>
> </xsp:page>
>
> The engine would apply the sheets in this order:
>
> foo
> xsp-request
> esql
> xsp
>
> 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
> list.
>
> 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
> index.
>
> Please note that step 3 is a recursive process.
>
> The only problem comes from circular dependancies.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
=====
Davanum Srinivas, JNI-FAQ Manager
http://www.jGuru.com/faq/JNI
__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [c2] xsp engine changes
Posted by Berin Loritsch <bl...@apache.org>.
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"
configuration element:
<builtin-logicsheet>
<parameter name="prefix" value="foo"/>
<parameter name="uri" value="http://apache.org/xsp/foo"/>
<parameter name="href" value="context://WEB-INF/logicsheets/foo.xsl"/>
<requires>
<logicsheet uri="http://apache.org/xsp/request"/>
<logicsheet uri="http://apache.org/xsp/sql/v2"/>
</requires>
</builtin-logicsheet>
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:
<?xml version="1.0"?>
<xsp:page language="java"
xmlns:xsp="http://apache.org/xsp"
xmlns:xsp-request="http://apache.org/xsp/request"
xmlns:foo="http://apache.org/xsp/foo"
>
<page>
<header><title><xsp-request:get-parameter name="foo-title"/></title></header>
<foo:get-bar name="foo"/>
</page>
</xsp:page>
The engine would apply the sheets in this order:
foo
xsp-request
esql
xsp
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
list.
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
index.
Please note that step 3 is a recursive process.
The only problem comes from circular dependancies.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org