cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivelin Ivanov" <ive...@apache.org>
Subject Re: Parameterizing Sitemap with XMLForms
Date Fri, 07 Jun 2002 09:46:08 GMT

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" <topping@digidemic.com>
To: <cocoon-dev@xml.apache.org>
Sent: Friday, June 07, 2002 12:12 AM
Subject: RE: Parameterizing Sitemap with XMLForms


> -----Original Message-----
> From: Ivelin Ivanov [mailto:ivelin@apache.org]
> 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" <topping@digidemic.com>
> To: <cocoon-dev@xml.apache.org>
> 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: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>

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



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


Mime
View raw message