> Torsten,
>
> although I've said that doing this with xslt is feasible I think I was
> wrong.
>
> So here is a transformer that does a) handle the complete xform
> binding spec and adds instance data as <value/> child element to form
> controls and b) adds a @name attribute to them containing the form
> name + "/" + path to instance data (e.g. name="order_form/address/street")
>
> It does not remove anything from the document, e.g. form declarations
> or @refs.
So we are back to the transformer ;) We should really decide which way to go!
So what are your PROs for the transformer now?
> The package name is a temporal convenience and will change.
>
> I did waste quite some time toying with an DTM representation, since
> this transformer is quite slow and DTM looked like it would speed it
> up a lot. E.g. creating the cached form declaration took half the
> time. Unfortunately I had to find out the hard way that a number of
> important API calls are not implemented yet.... :-(
>
> Since this transformer caches form declarations which also contain the
> model necessary for validation, I think it would be nice to "register"
> this model (+submitInfo) somewhere so that it is available when
> validation takes place. This doesn't need to be session bound (doesn't
> register instance data).
Not for the submitInfo and the model. But you don't wanna POST the
instance all the time, don't you? Where do you wanna hold the instance
data?
Do we agree on holding the instance as DOM in the session?
> This information would be useful also when determining which form has
> been submitted.
>
> Caching is done only during the lifetime of a transformer instance as
> I have no idea how to decide easily if a cached form declaration &
> instance data is still valid. Ideas?
Well, I decided that the structure of the xform instance may not change
but the values. So what already works for me is the following:
<xform:xform id="myform">
<xform:submitInfo href="submit"/>
<xform:model>
</xform:model>
<xform:instance>
<customernr><my:customerid/></customernr>
<positionid><xsp-request:get-parameter name="id"/></positionid>
<date/>
<deliveryaddress id="00200000000000000843">
<esql:connection>
<esql:pool>dff</esql:pool>
<esql:execute-query>
<esql:query>
select street, zip, city from addresses
where CUS_ID='<xform:output ref="/customernr"/>'
and ADDRESSID = '<xform:output ref="/deliveryaddress/@id"/>'
</esql:query>
<esql:results>
<esql:row-results>
<esql:get-columns/>
</esql:row-results>
</esql:results>
</esql:execute-query>
</esql:connection>
</deliveryaddress>
<esql:connection>
<esql:pool>dff</esql:pool>
<esql:execute-query>
<esql:query>
select * from customer
where CUS_ID='<xform:output ref="/customernr"/>'
and AP_ID = '<xform:output ref="/positionid"/>'
</esql:query>
<esql:results>
<esql:row-results>
<esql:get-columns/>
</esql:row-results>
</esql:results>
</esql:execute-query>
</esql:connection>
</xform:instance>
</xform:xform>
Right now I'm trying to update the instance data directly
via SAX events. But this gave me some headaches in the last few days...
> BTW if I understand the xforms WD correctly, form controls need to set
> the default namespace or child elements like <caption/>, <hint/>
> &c. need to explicitly carry their namespace. So your sample xform.xml
> needs to be changed:
>
> <xform:textbox ref="order/city" xform="orderForm">
> <caption>City</caption>
> </xform:textbox>
>
> becomes
>
> <xform:textbox ref="order/city" xform="orderForm"
>xmlns="http://www.w3.org/2001/06/xforms";>
> <caption>City</caption>
> </xform:textbox>
This might be true
> I will next look into such a "registry" that keeps track of xform
> declarations and provides them to a validator. Obviously, I will go
> and see if I can use the code you posted earlier :-)
Sure.
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
