cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Haul <h...@dvs1.informatik.tu-darmstadt.de>
Subject Re: latest xform
Date Thu, 26 Jul 2001 19:15:42 GMT
On 26.Jul.2001 -- 11:08 AM, Torsten Curdt wrote:
> Well, without a session the whole instance data has to be posted
> for each subpage. When thinking of a 5 pages form this can be a lot
> of data... the current design just posts the data of the current
> subpage controls. This would be less than 1/5 of the whole instance
> data!! BTW: that's the usual way

OK, got it.

> I thought it was an alternative to specifiying the xform attribute.
> Anyway... Could you correct the xform.xml then please?
> So we have correct example to try with...

Attached it the one I'm currently trying to get bindings to work
properly. There might be other examples on www.mozquito.org but I
wasn't able to load the examples with my current browser (requires
java script).

> > > This also how we could define the errors or validation
> > > constrains...
> > 
> > One idea could be to use what Konstantin said about error elements in
> > the instance data. Messages would be presented by using output
> > elements referencing these error instances. If they are empty, no
> > error message is presented to the user.
> 
> Yes. This might be a good sollution. But where are the error message
> specified?! The instance would only hold a copy of them...

Would have to be done by the validation process(?)

> > I reckon daily usage would make a taglib necessary, that translates
> > some even more abstract input controls to xform input controls. But
> > that's probably very application specific.
> 
> Could you give an example?

I reckon that a (content) designer might be most happy by writing

  <orderForm:FirstName/>

than have to write the complete 
     <xform:textbox....>
        <caption>...
	...
     </xform:textbox>

OK, most likely a little bit more than just <oderForm:FirstName/>

> > This information (that there is a checkbox "foo") is contained in the
> > information that is needed by the validation process. Otherwise it
> > wouldn't be able to check "foo".
> 
> Exactly - that's the problem. This information is only available
> in the descriptor by selecting via XPath "//sel:page[@name='page']/(descendant::xform:textbox|descendant::xform:checkbox)"
> or via PageRegistry.
> The descriptor+XPath way gives us unwanted dependancy of the sel:page element
> (and it is a hell of an expression ;) ... but maybe we can cache this
> nodelist in our action as well...
> 
> Hm... what about this:
> 
>    <map:match pattern="xform.html">
>     <map:act type="XFormAction">
>       <map:parameter name="pageroot" value="//sel:page[@name='$page$']"/>
>       <map:parameter name="default" value="fillin1"/>
>       <map:generate type="serverpages" src="docs/samples/xform/xform.xml">
>         <map:parameter name="page" value="{page}"/>
>       </map:generate>
>     </map:act>
>     <map:transform src="stylesheets/xform2html.xsl"/>
>     <map:serialize type="html"/>
>    </map:match>
> 
> This would specifiy the path to the root node. We only would
> have to replace the $page$ (unfortunately {page} cannot work)

Why? (No idea what you're at.)

> by the page the action receives the data from. Then we have
> the root node of the suppage and we can make a select
> "descendant::xform:textbox|descendant::xform:checkbox" to get
> the expected elements. if we cache the nodelists with the
> pageroot expression as key in a Hashtable or somehting we
> should really have little expense...
> We can also provide the "//sel:page[@name='$page$']" expression
> as default value so you only have to change it if you
> don't use the sel:logicsheet...
> 
> Cool!

> > There's more to it. You need to determine wich form got submitted
> > since you can not split it to different HTML forms as they cannot be
> > nested or mixed. So a sitemap component has to find out which one is
> > the right one and "redirect" to the appropriate URI. "redirect"
> > because the request object has to be maintained. What about forms that
> > submit to a different site (or a part of the site that's not
> > controlled by C2)? (not solvable?)
> 
> I don't see the problem could you explain a bit more.
> The action already knows about which http form was submitted.

In short: HTML forms may not be nested, XForms may. So several XForms
will be combined into a single HTML form having several submit
buttons. Need to find out which one was used + send data to correct
target as different XForms may have different submit targets.

> > I hope to have a stylesheet tomorrow that does the full binding
> > stuff. After that I'll look into a multiple forms actor or into
> > validation.

Unfortunately, it looks like I haven't got a clue about advanced XPath
expressions and XForms contains more and more complicated issues than
I anticipated. So here is a tiny stylesheet that copies instance data
to a value child element of xforms controls. It's far from perfection,
greatest shortcomings are it doesn't do scoped binding or indirect
binding and it uses xalan's evaluate extension. But for the moment it
might be useful anyway. I hope that I'll be able to follow up on the
binding issues.


	Chris.

-- 
C h r i s t i a n       H a u l
haul@informatik.tu-darmstadt.de
    fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08

Mime
View raw message