> -----Original Message-----
> From: Ivelin Ivanov [mailto:[EMAIL PROTECTED]]
> 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 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]
