cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brian Topping" <>
Subject RE: Parameterizing Sitemap with XMLForms
Date Fri, 07 Jun 2002 05:12:12 GMT
> -----Original Message-----
> From: Ivelin Ivanov []
> Subject: Re: Parameterizing Sitemap with XMLForms
> The cause for the exception is
> <map:parameter name="xmlform-validator-schema"
> 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 <map:match pattern="bill2forms/*.html">
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 <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,
"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.


> ----- Original Message -----
> From: "Brian Topping" <>
> To: <>
> 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=""/>
> <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=""/>
> <!-- 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
> 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
> 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:
> For additional commands, email:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, email:

To unsubscribe, e-mail:
For additional commands, email:

View raw message