> > 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?
What do you mean by "get back"? What I was thinking of was:
SAX -> DOMObject builds the DOM of the instance structure
Now since the DOMObjects implements XMLFragment and even XMLProducer
it is quite easy to insert into the SAX stream by calling
object.toSAX(handler)
So we have it back as XML when we need 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?
I want to save the DOMObject instances inside the session.
Simplified:
xform = (DOMObject)session.get("formid");
if(xform == null){
xform = new DOMObject();
xform.setLexicalHandler(lexicalhandler);
xform.setContentHandler(contenthandler);
}
Some kind of manager would be probably better?!
> 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 I'm wondering where you are up to... ;)
> > 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.
ok
> > * Validation of the populated values in the DOMObjects
>
> Right.
ok
> > * Selection of the subpage based on the validation results
>
> See other reply.
Could you please outline how you would want to do this?
I don't really see the problem about this one.
> > 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?
yes
> This wouldn't be
> cachable by cocoon, would it?
hm.. why not depends on how we implement the
generateKey and generateValidity methods.
> > Or maybe to the instance data structure:
>
> Preferred, as it is conform to XForms.
aggreed
> > 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.
Well, it is kept in memory anyway. But yes it's more expensive.
> > A Transformer will have different considerable advantages:
> > * the form does not usually have to be an XSP page
>
> Why is this bad?
I'm trying not to XSP if possible. Probably I
got infected from the recent discussions questioning
XSP in the long run. - It is much more overhead.
> > * 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.
Hm.. got me. I must admit I feel just more flexible and
safer not to run into compile time / run time problems.
Why would you want to go for a logicsheet?
> > 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.
This is just an addition. So I don't see the problem.
But as long as I see a way of doing the mapping (as I do)
I'm fine with that :) (But I will keep this in mind anyway.
I think changing the class can be extremly useful! I would
put all the submit logic or complexer constraints that
need DBMS access into this classes)
> > 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.
What's the compliant method? I must have missed it in the spec.
> 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.
Yepp! Then we need to come up with something nice
- not too far from the standard.
> This is also a presentation problem. How is an error message
> displayed?
Well, right now we list them via stylesheet right before the html
form begins. But the stylesheet could also create an onload javascript
alert. This should be no problem.
But we need a translateable error code somewhere in the xform!
If it is in a different namespace that's fine too...
> > * 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.
But still there is the output problem then!
> > * 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.
Arrrgh... NO! This becoming a real ugly hack then!!
(not talking about weak browser implementation that
might be swamped with long i18n text as values - just
a fear)
I aggree the value should be in the DOMObject as it
is what comes with the request. But I really often
need to show a summary of an order e.g. and I need
the text there - not the value!! (that's a common need)
Again doing queries for all values on a summery
page is tremenduous inefficient and ugly!
We need to definitly find a way around that!
> > * 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.
No. There is a difference! Submitting
a subpage is different from submitting
the xform!! Submitting the xform means
"placing the order" while submitting
a subpage is a navigation inside the
xform.
What about putting the whole multipage
navigation thing into it's own namespace?
Like:
<xfn:pages>
<xfn:page name="fillin">
<xform:.../>
<xfn:goto name="summary"/>
</xfn:page>
<xfn:page name="summary">
<xfn:goto name="fillin"/>
<xform: .../>
<xform:submit.../>
</xfn:page>
</xfn:pages>
So we would have both topics separated.
But we need a way to report the result
of the form submission (success/failed)
to the sitemap. Also a failed submit
need to show the last page again.
> > * 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.
ok - hope you are right :)
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
