Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <00e201c11377$00709a20$0200a8c0@fuckup>
From: "Peter Nuetzel - inglobo" <peter.nuetzel@inglobo.de>
To: <cocoon-dev@xml.apache.org>
Subject: Re: [RT] forms
Date: Mon, 23 Jul 2001 14:55:23 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit


-----Urspr�ngliche Nachricht-----
Von: Torsten Curdt <tcurdt@dff.st>
An: cocoon-dev@xml.apache.org <cocoon-dev@xml.apache.org>
Cc: peter.nuetzel@inglobo.de <peter.nuetzel@inglobo.de>;
haul@dvs1.informatik.tu-darmstadt.de <haul@dvs1.informatik.tu-darmstadt.de>
Datum: Sonntag, 22. Juli 2001 14:49
Betreff: RE: [RT] forms


>> 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.
>

My Action uses a DOM representation of the form descriptor. All form
controls with their ref attributes and validation information are extracted
via XPath and used to update the instance data accordingly.

>--
>
>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?

I'm using a special <enum> element in my form descriptor to reference
enumerations from other XML documents and construct xform <item>
enumerations for multiple/single select controls.
<enum document="units.xml" absref="/units/unit[@name='currency']/item"
value="." name="."/>
Better would probably be using some kind of XLink to do this.

- peter


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org