On 19.Jul.2001 -- 03:08 PM, Torsten Curdt wrote:
> So how could we tackle things now. I think it is quite
> natural on such approach to have a DOMObject that will
> hold the instance data of the xform. The most simplyfied
> definition of such an interface would probably be:
>
> interface DOMObject extends XMLFragment, XMLConsumer, XMLProducer {
> public void setValue( String XPath );
> public String getValue( String XPath );
> }
Agreed. But what's your opinion regarding the returned instance? It's
not likely to get XML back, well, a simplified path expression form,
yes. Shall we reconstruct it?
> When a subpage is chosen to be viewed an intance of
> an DOMObject referring to the xform id needs to be
> looked up. If there is none, one needs to be created
> and registered. (Just like the Components in the ComponentManager)
> Creation means also passing the SAX events from the
> xform:instance data to the DOMObject. Now the DOMObject
> holds the expected XForm structure.
I don't quite get what you're at. If this object contains the instance
data -- which is likely to be different for every invocation as partly
filled in forms return -- why should an instance get looked up?
If that's the caching concern again, I strongly believe that that is a
different concern and should be handled otherwise. E.g. if it's a XSP
that generates the form, it's up to cocoon to cache this request and
deliver a cached copy.
> Now we have an XFormAction that will do:
> * Population of values into the DOMObjects
The returned / posted values. OK, so you're in favour of
reconstructing the XML, good.
> * Validation of the populated values in the DOMObjects
Right.
> * Selection of the subpage based on the validation results
See other reply.
> Then I would propose a XFormTransformer that will
> extract the selected subpage fragment and add the
> value to the xform elements. Here is an example of
> what should come out of the transformer:
What would that be exactly? Fill in the blanks in a form with values
from the instance data, like the SQLTransformer? This wouldn't be
cachable by cocoon, would it?
> Or maybe to the instance data structure:
Preferred, as it is conform to XForms.
> This would probably make the XSLT stylesheet a lot more
> complicated but would be even more consistent.
Not really, more expensive though, because you'd need path expressions
referencing document parts that wouldn't have been kept in memory
otherwise.
> A Transformer will have different consderable advantages:
> * the form does not usually have to be an XSP page
Why is this bad?
> * at least the describtor XML can be cached then
Could be with XSP as well.
> * the form can be filled from esql or other taglibs easily
With XSP as well.
> * taglib would mean to but multiple (sub)pages into
> one XSP page - I'm always afraid of the 64k limitation
> of XSP pages
AFAIK this limitation is a per method limit. So putting each sub page
in a different method would circumvent it.
> This presented concept leaves even room for the business
> object mapping that I want. A "class" attribute could be
> added easily to the xform:instance tag that will specify
> the actual class to use. The business objects only have
> to implement DOMObject or be an intance of an AbstractDOMObject.
I believe that's not XForms compliant. Perhaps an action propagating
the request parameter DOMObject to your BO could do the mapping.
> Still there are some issues left.
> * error reporting
> The validator could set an errorcode attribute in
> the DOMObject. But somewhere there must happen
> a translation into a full message. Maybe we could
> reuse the i18n transformer for this? So what comes
> out is something like:
>
> <xform:textbox ref="/order/firstname">
> <error><i18n:translate>firstnameERR001</i18n:translate></error>
> </xform:textbox>
>
> So the correct error messages only have to be
> specified in the dictionary. voila!
Again this is not compliant. But it is a problem to conform to it
here. What about different error conditions? Currently
FormValidatorAction offers a number of constraints that each may be
invalid. XForms specs only one arbitrary complex constraint returning
a boolean.
I think this is because XForms rely on client side validation and thus
this arbirary complex validation constraint could be ECMA script
poping up message boxes. So this falls short server side checking and
error reporting.
This is also a presentation problem. How is an error message
displayed?
> * DBMS comboboxes
> (just peeked into your answer on the list ;)
> Of course this shouln't be an issue because
> of DBMS caching of queries - but unfortunately it is.
> In real world it turns out that still the DBMS part
> is the slow one. Especially because usually form pages
> cannot be cached. We had a couple of case where
> there where up to 100 items. And multiple comboboxes
> per page!
> DBMS changes aren't a problem for the applications
> we wrote so far. If so - well then use esql to
> fill the combobox... But I would consider this
> need as unusual.
I still think it's not a form issue. If you're not happy with your
DBMS caching the data, well, create an alternative way to contact the
DBMS and do the caching in that component like the descriptor caching
is done. After all, this might come in handy with other issues as
well.
> * output definition
> I think what is not quite clear (at least for me)
> from the XForms spec is what "output" means
> on selections aka choices. Is it the value
> or the text? Both is needed! So how do you specify
I think as with HTML it's the value. If you'd need the text, add that
to the value as well.
> * subpage navigation
> A subpage is only a part of a xform. So submit
> would not be the right term to goto the next
> subpage. I haven't any spec for that. I would
> propose somthing like:
>
> <xform:popup name="subpagename"/> or
> <xform:goto name="subpagename"/>
Name the submit button as you like.
> * datatypes
> How can we integrate datatypes?
XSchema? Validation through xerces?
> * binding
> How can we integrate binding?
Should be easy, this is done when rendering XForm to e.g. HTML with a
XSL stylesheet.
Chris.
--
C h r i s t i a n H a u l
[EMAIL PROTECTED]
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
