Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
content-class: urn:content-classes:message
Subject: RE: Parameterizing Sitemap with XMLForms
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 7 Jun 2002 01:12:12 -0400
Message-ID: <60F6EF824F0C284481CEF5F49D2F54030C9BDF@centrum.digidemic.com>
Thread-Topic: Parameterizing Sitemap with XMLForms
Thread-Index: AcIN2U3kBhwx+g2XQgS2wbXwA6lOGwAA4kGw
From: "Brian Topping" <topping@digidemic.com>
To: <cocoon-dev@xml.apache.org>

> -----Original Message-----
> From: Ivelin Ivanov [mailto:ivelin@apache.org]
> Subject: Re: Parameterizing Sitemap with XMLForms
>=20
> The cause for the exception is
>=20
> <map:parameter name=3D"xmlform-validator-schema"
> value=3D"forms/{1}/xmlform-sch-report.xml"/>

Yes, that is correct.

> The value should point to a path which the SourceResolver=20
> 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=20
> your case.

For example, request of /bill2forms/HowtoWizard.html against <map:match =
pattern=3D"bill2forms/*.html"> results in {1} =3D '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=3D"xmlform-validator-schema" =
value=3D"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

>=20
> ----- Original Message -----
> From: "Brian Topping" <topping@digidemic.com>
> To: <cocoon-dev@xml.apache.org>
> Sent: Thursday, June 06, 2002 5:46 AM
> Subject: Parameterizing Sitemap with XMLForms
>=20
>=20
> Hi all,
>=20
> So I am trying to parameterize a sitemap that I am using with=20
> forms and
> running into an interesting situation.  I don't know enough=20
> about components
> and actions yet, but this may be a bug in=20
> AbstractXMLFormAction.  (I've
> changed the names in the code below, but it's just Heidi's example...)
>=20
> Sitemap snippet:
>=20
> <map:match pattern=3D"bill2forms/*.html">
> <map:act type=3D"HowtoWizardAction">
> <!-- XMLForm parameters for the HowtoWizardAction -->
> <map:parameter name=3D"xmlform-validator-schema-ns"
> value=3D"http://www.ascc.net/xml/schematron"/>
> <map:parameter name=3D"xmlform-validator-schema"
> value=3D"forms/{1}/xmlform-sch-report.xml"/>
> <map:parameter name=3D"xmlform-id" value=3D"form-{1}"/>
> <map:parameter name=3D"xmlform-scope" value=3D"session"/>
> <map:parameter name=3D"xmlform-model"
> value=3D"com.bill2.site.xmlform.HowtoBean"/>
> <!-- Content transformation logic -->
> <map:generate src=3D"forms/{../1}/{page}.xml"/>
> <map:transform type=3D"xmlform" label=3D"xml"/>
> <map:transform src=3D"forms/{../1}/wizard2html.xsl"/>
> <map:transform =
src=3D"context://stylesheets/xmlform/xmlform2html.xsl"/>
> <map:serialize type=3D"html"/>
> </map:act>
> </map:match>
>=20
> If you look at the parameterization, all of the=20
> <map:parameters> use "{1}",
> but all the other components are sent "{../1}".  This is what=20
> 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=20
> the first form
> page, the following exception is generated:
>=20
> 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)
>=20
> I wouldn't mind submitting the patch, but I'm not confident=20
> enough yet of
> the semantics of parameterization to know if I am doing the=20
> right thing.  I
> presume that the problem is in AbstractXMLFormAction by the=20
> 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...
>=20
> If it takes longer to describe than it does to fix, I can=20
> 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=20
> about {../*} from
> a post that Vadim made a long time back.  Is there a full=20
> explanation of
> this anywhere?  (RTFM?)
>=20
> best,
>=20
> -b
>=20
> _________________________________________________________
> 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
>=20
>=20
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>=20
>=20
>=20
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>=20
>=20

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org