RE: Parameterizing Sitemap with XMLForms
> -Original Message-
> From: Piroumian Konstantin [mailto:[EMAIL PROTECTED]]
> Subject: RE: Parameterizing Sitemap with XMLForms
>
> I wonder, how could you experience that? AFAIK nothing has
> changed since
> I've checked it and it was like: {../1} references the parent pipeline
> element returned params and not the sitemap. Look:
>
> Request:
> /cocoon/files/page.xml
>
> Sitemap Entry:
>
>
>
>
>
>
>
> Note, that there are also {0} params available. See
> sitemap.log to get what
> are the available params and their values for every request.
What am I missing here?
For above, I agree on {1}. I don't agree on the others. Methinks:
{../1} = 'cocoon'
{../2} = 'files'
{0} = 'page.xml'
{../0} = 'cocoon/files'
a little confused... am I wrong?
-b
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RE: Parameterizing Sitemap with XMLForms
> From: Brian Topping [mailto:[EMAIL PROTECTED]]
> > From: Ivelin Ivanov [mailto:[EMAIL PROTECTED]]
...
>
> > A sitemap expert should be able to help with this one.
> > If I am not mistaken {1} references the first variable in
> the current
> > sitemap,
> > while {../1} references the first variable in the parent sitemap.
>
> Yes, that is my experience too.
I wonder, how could you experience that? AFAIK nothing has changed since
I've checked it and it was like: {../1} references the parent pipeline
element returned params and not the sitemap. Look:
Request:
/cocoon/files/page.xml
Sitemap Entry:
Note, that there are also {0} params available. See sitemap.log to get what
are the available params and their values for every request.
Konstantin
>
> > What do you think the bug in AbstractXMLFormAction is?
>
> The entities that are passed into the
> subclass of AbstractXMLFormAction improperly require {1} for
> the TreeProcessor to work; they should properly work with
> {../1} like the rest of the action. What I have described so
> far is a problem in the transitive closure of TreeProcessor,
> which may or may not include AbstractXMLFormAction. I don't
> know it yet, so I need to learn it. According to
> http://xml.apache.org/cocoon/userdocs/concepts/actions.html,
> "Communication Between Sitemap and Action", {1} should
> reference the current map object (the action) and {../1}
> should reference the previous one (the match). When
> value="forms/{../1}/xmlform-sch-report.xml"/>, the
> TreeProcessor complains with
> "org.apache.cocoon.sitemap.PatternException: Error while
> evaluating 'form-{../1}' : not so many levels", when passed
> {1} for same parameter, getFormValidator complains with the
> original exception.
>
> So there is either a bug in my brain, in the
> semantics/documentation, or in the code. I'm more inclined
> to believe that AbstractXMLFormAction is being handed a bad
> SourceResolver, but I haven't looked at a single line of
> AbstractXMLFormAction yet. The overall semantics are pretty
> simple, thereby minimizing that I am just not groking it and
> pointing to a problem somewhere. But until I can send a
> patch, the code works by definition, right? :)
>
> Gotta get some sleep now. Don't sweat this too much, I just
> wanted to see if anyone recognized it. I'll work on it soon.
>
> -B
>
> >
> > - Original Message -
> > From: "Brian Topping" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Thursday, June 06, 2002 5:46 AM
> > Subject: Parameterizing Sitemap with XMLForms
> >
> >
> > Hi all,
> >
> > So I am trying to parameterize a sitemap that I am using with
> > forms and
> > running into an interesting situation. I don't know enough
> > about components
> > and actions yet, but this may be a bug in
> > AbstractXMLFormAction. (I've
> > changed the names in the code below, but it's just Heidi's
> example...)
> >
> > Sitemap snippet:
> >
> >
> >
> >
> > > value="http://www.ascc.net/xml/schematron"/>
> > > value="forms/{1}/xmlform-sch-report.xml"/>
> >
> >
> > > value="com.bill2.site.xmlform.HowtoBean"/>
> >
> >
> >
> >
> > src="context://stylesheets/xmlform/xmlform2html.xsl"/>
> >
> >
> >
> >
> > If you look at the parameterization, all of the
> > use "{1}",
> > but all the other components are sent "{../1}". This is what
> > it takes to
> > get the sitemap interpreter to be happy and put the start
> page on the
> > screen. But when it comes to clicking on the "Start" link on
> > the first form
> > page, the following exception is generated:
> >
> > org.apache.avalon.framework.CascadingRuntimeException:
> Failed loading
> > validating schema
> > at
> > org.apache.cocoon.acting.AbstractXMLFormAction.getFormValidato
> > r(AbstractXMLF
> > ormAction.java:365)
> > at
> > org.apache.cocoon.acting.AbstractXMLFormAction.getForm(Abstrac
> > tXMLFormAction
> > .java:179)
> > at
> > org.apache.cocoon.acting.AbstractXMLFormAction.act(AbstractXML
> > FormAction.jav
> > a:202)
> > at
> > org.apache.cocoon.components.treeprocessor.sitemap.ActTypeNode
> > .invoke(ActTyp
> > eNode.java:133)
> >
> > I wouldn't mind submitting the patch, but I'm not confident
> > enough yet of
> > the semantics of parameterization to know if I am doing the
> > right thing. I
> > presume that the problem is in AbstractXMLFormAction by the
> > fact that the
> > other components weren't changed, but that kind of hunch is
> not a very
> > responsible manner in which to submit a patch...
> >
> > If it takes longer to describe than it does to fix, I can
> > wait for the next
> > bug in order to put some work in. But I do want to learn about the
> > semantics of parameterization more, and I only really know
> > about {../*} from
> > a post that Vadim made a long time back. Is there a full
> > explanation of
> > th
Re: Parameterizing Sitemap with XMLForms
I think we can use some help from the TreeProcessor authors here.
You're on to something interesting which is beyond my expertise at this
point.
Thanks for digging deeper on this issue.
Ivelin
- Original Message -
From: "Brian Topping" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, June 07, 2002 12:12 AM
Subject: RE: Parameterizing Sitemap with XMLForms
> -Original Message-
> From: Ivelin Ivanov [mailto:[EMAIL PROTECTED]]
> Subject: Re: Parameterizing Sitemap with XMLForms
>
> The cause for the exception is
>
> value="forms/{1}/xmlform-sch-report.xml"/>
Yes, that is correct.
> The value should point to a path which the SourceResolver
> passed to the
> AbstractXMLFormAction can locate and load.
My next step was to jdb through the code. I'll scrutinize the
SourceResolver that is passed. Something must be screwy there. I haven't
looked at SourceResolvers yet, but I'm guessing that it is out of your
hands, you just ask for a file handle or a stream back from the
SourceResolver.
> I am not quite sure what is the layout of the directories in
> your case.
For example, request of /bill2forms/HowtoWizard.html against results in {1} = 'HowtoWizard'.
The /forms/HowtoWizard/xmlform-sch-report.xml exists and is valid (simply
the file of similar name from the example.
> A sitemap expert should be able to help with this one.
> If I am not mistaken {1} references the first variable in the current
> sitemap,
> while {../1} references the first variable in the parent sitemap.
Yes, that is my experience too.
> What do you think the bug in AbstractXMLFormAction is?
The entities that are passed into the subclass of
AbstractXMLFormAction improperly require {1} for the TreeProcessor to work;
they should properly work with {../1} like the rest of the action. What I
have described so far is a problem in the transitive closure of
TreeProcessor, which may or may not include AbstractXMLFormAction. I don't
know it yet, so I need to learn it. According to
http://xml.apache.org/cocoon/userdocs/concepts/actions.html, "Communication
Between Sitemap and Action", {1} should reference the current map object
(the action) and {../1} should reference the previous one (the match). When
, the TreeProcessor complains
with "org.apache.cocoon.sitemap.PatternException: Error while evaluating
'form-{../1}' : not so many levels", when passed {1} for same parameter,
getFormValidator complains with the original exception.
So there is either a bug in my brain, in the semantics/documentation, or in
the code. I'm more inclined to believe that AbstractXMLFormAction is being
handed a bad SourceResolver, but I haven't looked at a single line of
AbstractXMLFormAction yet. The overall semantics are pretty simple, thereby
minimizing that I am just not groking it and pointing to a problem
somewhere. But until I can send a patch, the code works by definition,
right? :)
Gotta get some sleep now. Don't sweat this too much, I just wanted to see
if anyone recognized it. I'll work on it soon.
-B
>
> - Original Message -
> From: "Brian Topping" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Thursday, June 06, 2002 5:46 AM
> Subject: Parameterizing Sitemap with XMLForms
>
>
> Hi all,
>
> So I am trying to parameterize a sitemap that I am using with
> forms and
> running into an interesting situation. I don't know enough
> about components
> and actions yet, but this may be a bug in
> AbstractXMLFormAction. (I've
> changed the names in the code below, but it's just Heidi's example...)
>
> Sitemap snippet:
>
>
>
>
> value="http://www.ascc.net/xml/schematron"/>
> value="forms/{1}/xmlform-sch-report.xml"/>
>
>
> value="com.bill2.site.xmlform.HowtoBean"/>
>
>
>
>
>
>
>
>
>
> If you look at the parameterization, all of the
> use "{1}",
> but all the other components are sent "{../1}". This is what
> it takes to
> get the sitemap interpreter to be happy and put the start page on the
> screen. But when it comes to clicking on the "Start" link on
> the first form
> page, the following exception is generated:
>
> org.apache.avalon.framework.CascadingRuntimeException: Failed loading
> validating schema
> at
> org.apache.cocoon.acting.AbstractXMLFormAction.getFormValidato
> r(AbstractXMLF
> ormAction.java:365)
> at
> org.apache.cocoon.acting.AbstractXMLFormAction.getForm(Abstrac
> tXMLFormAction
> .java:179)
> at
> org.apache.cocoon.acting.AbstractXMLFormAction.act(AbstractXML
> FormAction.jav
> a:202)
> at
> org.apache.coc
RE: Parameterizing Sitemap with XMLForms
> -Original Message-
> From: Ivelin Ivanov [mailto:[EMAIL PROTECTED]]
> Subject: Re: Parameterizing Sitemap with XMLForms
>
> The cause for the exception is
>
> value="forms/{1}/xmlform-sch-report.xml"/>
Yes, that is correct.
> The value should point to a path which the SourceResolver
> passed to the
> AbstractXMLFormAction can locate and load.
My next step was to jdb through the code. I'll scrutinize the SourceResolver that is
passed. Something must be screwy there. I haven't looked at SourceResolvers yet, but
I'm guessing that it is out of your hands, you just ask for a file handle or a stream
back from the SourceResolver.
> I am not quite sure what is the layout of the directories in
> your case.
For example, request of /bill2forms/HowtoWizard.html against results in {1} = 'HowtoWizard'.
The /forms/HowtoWizard/xmlform-sch-report.xml exists and is valid (simply the file of
similar name from the example.
> A sitemap expert should be able to help with this one.
> If I am not mistaken {1} references the first variable in the current
> sitemap,
> while {../1} references the first variable in the parent sitemap.
Yes, that is my experience too.
> What do you think the bug in AbstractXMLFormAction is?
The entities that are passed into the subclass of
AbstractXMLFormAction improperly require {1} for the TreeProcessor to work; they
should properly work with {../1} like the rest of the action. What I have described
so far is a problem in the transitive closure of TreeProcessor, which may or may not
include AbstractXMLFormAction. I don't know it yet, so I need to learn it. According
to http://xml.apache.org/cocoon/userdocs/concepts/actions.html, "Communication Between
Sitemap and Action", {1} should reference the current map object (the action) and
{../1} should reference the previous one (the match). When , the
TreeProcessor complains with "org.apache.cocoon.sitemap.PatternException: Error while
evaluating 'form-{../1}' : not so many levels", when passed {1} for same parameter,
getFormValidator complains with the original exception.
So there is either a bug in my brain, in the semantics/documentation, or in the code.
I'm more inclined to believe that AbstractXMLFormAction is being handed a bad
SourceResolver, but I haven't looked at a single line of AbstractXMLFormAction yet.
The overall semantics are pretty simple, thereby minimizing that I am just not groking
it and pointing to a problem somewhere. But until I can send a patch, the code works
by definition, right? :)
Gotta get some sleep now. Don't sweat this too much, I just wanted to see if anyone
recognized it. I'll work on it soon.
-B
>
> - Original Message -
> From: "Brian Topping" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Thursday, June 06, 2002 5:46 AM
> Subject: Parameterizing Sitemap with XMLForms
>
>
> Hi all,
>
> So I am trying to parameterize a sitemap that I am using with
> forms and
> running into an interesting situation. I don't know enough
> about components
> and actions yet, but this may be a bug in
> AbstractXMLFormAction. (I've
> changed the names in the code below, but it's just Heidi's example...)
>
> Sitemap snippet:
>
>
>
>
> value="http://www.ascc.net/xml/schematron"/>
> value="forms/{1}/xmlform-sch-report.xml"/>
>
>
> value="com.bill2.site.xmlform.HowtoBean"/>
>
>
>
>
>
>
>
>
>
> If you look at the parameterization, all of the
> use "{1}",
> but all the other components are sent "{../1}". This is what
> it takes to
> get the sitemap interpreter to be happy and put the start page on the
> screen. But when it comes to clicking on the "Start" link on
> the first form
> page, the following exception is generated:
>
> org.apache.avalon.framework.CascadingRuntimeException: Failed loading
> validating schema
> at
> org.apache.cocoon.acting.AbstractXMLFormAction.getFormValidato
> r(AbstractXMLF
> ormAction.java:365)
> at
> org.apache.cocoon.acting.AbstractXMLFormAction.getForm(Abstrac
> tXMLFormAction
> .java:179)
> at
> org.apache.cocoon.acting.AbstractXMLFormAction.act(AbstractXML
> FormAction.jav
> a:202)
> at
> org.apache.cocoon.components.treeprocessor.sitemap.ActTypeNode
> .invoke(ActTyp
> eNode.java:133)
>
> I wouldn't mind submitting the patch, but I'm not confident
> enough yet of
> the semantics of parameterization to know if I am doing the
> right thing. I
> presume that the problem is in AbstractXMLFormAction by the
> fact that the
>
Re: Parameterizing Sitemap with XMLForms
Brian,
The cause for the exception is
The value should point to a path which the SourceResolver passed to the
AbstractXMLFormAction can locate and load.
I am not quite sure what is the layout of the directories in your case.
A sitemap expert should be able to help with this one.
If I am not mistaken {1} references the first variable in the current
sitemap,
while {../1} references the first variable in the parent sitemap.
What do you think the bug in AbstractXMLFormAction is?
Ivelin
- Original Message -
From: "Brian Topping" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, June 06, 2002 5:46 AM
Subject: Parameterizing Sitemap with XMLForms
Hi all,
So I am trying to parameterize a sitemap that I am using with forms and
running into an interesting situation. I don't know enough about components
and actions yet, but this may be a bug in AbstractXMLFormAction. (I've
changed the names in the code below, but it's just Heidi's example...)
Sitemap snippet:
http://www.ascc.net/xml/schematron"/>
If you look at the parameterization, all of the use "{1}",
but all the other components are sent "{../1}". This is what it takes to
get the sitemap interpreter to be happy and put the start page on the
screen. But when it comes to clicking on the "Start" link on the first form
page, the following exception is generated:
org.apache.avalon.framework.CascadingRuntimeException: Failed loading
validating schema
at
org.apache.cocoon.acting.AbstractXMLFormAction.getFormValidator(AbstractXMLF
ormAction.java:365)
at
org.apache.cocoon.acting.AbstractXMLFormAction.getForm(AbstractXMLFormAction
.java:179)
at
org.apache.cocoon.acting.AbstractXMLFormAction.act(AbstractXMLFormAction.jav
a:202)
at
org.apache.cocoon.components.treeprocessor.sitemap.ActTypeNode.invoke(ActTyp
eNode.java:133)
I wouldn't mind submitting the patch, but I'm not confident enough yet of
the semantics of parameterization to know if I am doing the right thing. I
presume that the problem is in AbstractXMLFormAction by the fact that the
other components weren't changed, but that kind of hunch is not a very
responsible manner in which to submit a patch...
If it takes longer to describe than it does to fix, I can wait for the next
bug in order to put some work in. But I do want to learn about the
semantics of parameterization more, and I only really know about {../*} from
a post that Vadim made a long time back. Is there a full explanation of
this anywhere? (RTFM?)
best,
-b
_
If you have some ice cream, I will give it to you.
If you have no ice cream, I will take it away from you.
- Ice Cream Koan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RE: Parameterizing Sitemap with XMLForms
> From: Brian Topping [mailto:[EMAIL PROTECTED]]
>
> Hi all,
>
> So I am trying to parameterize a sitemap that I am using with forms
and
> running into an interesting situation. I don't know enough about
components
> and actions yet, but this may be a bug in AbstractXMLFormAction.
(I've
> changed the names in the code below, but it's just Heidi's example...)
>
> Sitemap snippet:
>
>
>
>
>value="http://www.ascc.net/xml/schematron"/>
>value="forms/{1}/xmlform-sch-report.xml"/>
>
>
>value="com.bill2.site.xmlform.HowtoBean"/>
>
>
>
>
>src="context://stylesheets/xmlform/xmlform2html.xsl"/>
>
>
>
>
> If you look at the parameterization, all of the use
"{1}",
> but all the other components are sent "{../1}". This is what it takes
to get
> the sitemap interpreter to be happy and put the start page on the
screen. But
> when it comes to clicking on the "Start" link on the first form page,
the
> following exception is generated:
>
> org.apache.avalon.framework.CascadingRuntimeException: Failed loading
> validating schema
> at
>
org.apache.cocoon.acting.AbstractXMLFormAction.getFormValidator(Abstract
XMLFor
> mAction.java:365)
> at
>
org.apache.cocoon.acting.AbstractXMLFormAction.getForm(AbstractXMLFormAc
tion.j
> ava:179)
> at
>
org.apache.cocoon.acting.AbstractXMLFormAction.act(AbstractXMLFormAction
.java:
> 202)
> at
>
org.apache.cocoon.components.treeprocessor.sitemap.ActTypeNode.invoke(Ac
tTypeN
> ode.java:133)
>
> I wouldn't mind submitting the patch, but I'm not confident enough yet
of the
> semantics of parameterization to know if I am doing the right thing.
I
> presume that the problem is in AbstractXMLFormAction by the fact that
the
> other components weren't changed, but that kind of hunch is not a very
> responsible manner in which to submit a patch...
>
> If it takes longer to describe than it does to fix, I can wait for the
next
> bug in order to put some work in. But I do want to learn about the
semantics
> of parameterization more, and I only really know about {../*} from a
post that
> Vadim made a long time back. Is there a full explanation of this
anywhere?
> (RTFM?)
There is no one good document explaining this... I believe should be
explained somewhere
(http://xml.apache.org/cocoon/userdocs/concepts/sitemap.html ?), but it
is not.
Here is some info about parameters:
http://xml.apache.org/cocoon/faq.html#faq-19
http://xml.apache.org/cocoon/userdocs/concepts/actions.html
"Communication between Sitemap and Action"
(the same is for matchers)
Vadim
> best,
>
> -b
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
