> I'm sorry no, only the concat() function is evaluated not the resulting
> xpath.
So we have to make a decision: xform standard or extensions?
I'm not so sure anymore if a extension is that bad... I'm pretty
sure that most of XSLT processors have this type of functionality.
"Evaluate" is not a remarkable or unusual feature I guess...
On the other hand writers of the xform2[media].xsl would
only have to keep in mind that it is more a cxform2[media].xsl and
they would need a cxform2xform.xsl for the standard format.
What do you think, guys?
--
Thinking of the action... Peter how did you
address the checkbox problem so far? (Checkboxes
will not appear in the POST if they are not
checked. This makes changing to "unchecked"
a problem if do not know what POST variables
you have to expect.
Of course we could extract this information from the
xform descriptor via XPath. But I am wondering if there
is an easier way. What _I_ do right now is to have
a page post registry where viewed pages register
what elements are to be expected on POSTs from
the page. This works quite good altough it feels
to be a bit of kludge.
--
If noone objects my xsp.xsl proposal the instance creation
(including creation of the DOM structure) will pretty
easy. All we have to do is to make DOMObject implement
XMLConsumer and redirect the SAX events from the serverpage
to the DOMObject. The SAX events will build up the DOM
structure.
--
I will ask the guys from the xform working group about
the xform:output and selections...
--
Taking the further Schema into account this all gonna get
a bit more tricky. We haven't yet talked about types.
XForm specifies a type to be "xsd:anyType" as defaut but
AFAIU this should give the possibility to also specify
a set of complex types for reuse. Like:
<xform:textbox type="xsd:Email"/>
<xform:selectOne type="xsd:Country"/>
So the facet pattern, the validation or even the
database query has not to be specified over and over
again. (That's what speeds up development:)!
Question is: how do we map the types to the
elements? And: since this will mean there is another
file specifying the validation we don't have validation
information at hand in the xform descriptor anymore!
The xsd needs to become dynamic so we are able to use esql
to fill e.g. the country field or any other often reused
selection boxes.
Maybe we should have some kind of type registry?
This migth also address the caching of selections...
Anyone some thoughts on this yet?
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
