> From: Brian Topping [mailto:[EMAIL PROTECTED]]
> > From: Ivelin Ivanov [mailto:[EMAIL PROTECTED]]
...
<skip what="resolver discussion: no comments" />
>
> > 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:
<match pattern="*/*">
<match pattern="*.xml">
<!-- Use {1} to reference the inner matcher '*'
param = 'page'
{../1} - references the {1} in the parent
matcher = 'files'
{../2} - the {2} in the parent matcher =
'page.xml'
-->
<generate src="{../1}" />
</match>
</match>
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 <map:parameter> 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
> <map:parameter name="xmlform-validator-schema"
> 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:
> >
> > <map:match pattern="bill2forms/*.html">
> > <map:act type="HowtoWizardAction">
> > <!-- XMLForm parameters for the HowtoWizardAction -->
> > <map:parameter name="xmlform-validator-schema-ns"
> > value="http://www.ascc.net/xml/schematron"/>
> > <map:parameter name="xmlform-validator-schema"
> > value="forms/{1}/xmlform-sch-report.xml"/>
> > <map:parameter name="xmlform-id" value="form-{1}"/>
> > <map:parameter name="xmlform-scope" value="session"/>
> > <map:parameter name="xmlform-model"
> > value="com.bill2.site.xmlform.HowtoBean"/>
> > <!-- Content transformation logic -->
> > <map:generate src="forms/{../1}/{page}.xml"/>
> > <map:transform type="xmlform" label="xml"/>
> > <map:transform src="forms/{../1}/wizard2html.xsl"/>
> > <map:transform
> src="context://stylesheets/xmlform/xmlform2html.xsl"/>
> > <map:serialize type="html"/>
> > </map:act>
> > </map:match>
> >
> > If you look at the parameterization, all of the
> > <map:parameters> 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
> > 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]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
