cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Washeim" <esa...@canuck.com>
Subject Re: xml:form TagLib
Date Thu, 18 May 2000 20:53:46 GMT
>
>A few of us are trying to sort out a spec for a Form Handling TagLib, as
you may have noticed :)
>
>
>We are trying to work out how information for rendering a form can be
passed to the StyleSheet. Stuff like field names, existing or default field
values, locale specific help text etc.
>
>My first approach was to think of assembling the data as an XML fragment
and inserting it in the document.
>
>But the remark by Ulrich earlier, that TagLibs can be used in XSL <doh/> it
makes me think we can take a different approach.
>
>Instead of forcing the XSL author to extract the data they want from an XML
Fragment, provide a "Natural Language" Tag Set to get each thing.
>
>xml:form Tags in the addressed file, set up the whole thing, reading,
writing etc., then Tags in the XSL read whatever they needs from the TagLib
when the StyleSheet processes.
>
>Something like this? :
>
> <xsl:element name="input">
> <xsl:attribute name="type">text</xsl:attribute>
> <xsl:attribute name="size">40</xsl:attribute>
> <xsl:attribute name="value">
> <form:get-attribute field="{@name}" name="value"/>
> </xsl:attribute>
> <xsl:attribute name="title">
> <form:get-attribute field="{@name}" name="title"/>
> </xsl:attribute>
> <xsl:attribute name="maxlength">
> <form:get-attribute field="{@name}" name="maxlength"/>
> </xsl:attribute>
> </xsl:element>
>
>Which is not much different to what the XSL developer would have to do
extracting from their info from an XML Fragment, or this? :
>
> <form:field
> name="{@name}"
> class="input"
> type="text"
> size="40"
> />
>
>The TagLib supplies all the other bits, you did not overload.
>At this extreme, the TagLib would be outputting HTML, not a good thing,
right?

>
>Any suggestions?


Ok, although we're almost complete on an applet to do this, why not use
schemas (as of feb). Namely, 'interpret' the schema to arrive at the form.

For instance, a complex type, obviously, requires a number of fields,
selects, textareas, etc.

Each of those, in turn has properties, more or less complex. Namely, (simple
example) the elment Apartment, may have the attribute 'vacant' which is of
type boolean.  That predicates the values for the attribute, and,
effectively, the presentation (ie. an option select with two values).

In any case, we have a Schema based applet working and we're just behind
schedule (client pressure) to get it to you. It, however, could, to a
certain extent, be implemented as forms, too. The advantages of using schema
are manifest (we're using extension to arrive at derived types, which could
work as well for forms as for iterative views in an applet)....

Mark

>Thanks Jeremy
>
>   ___________________________________________________________________
>
>   Jeremy Quinn                                           Karma Divers
>                                                       webSpace Design
>                                            HyperMedia Research Centre
>
>   <mailto:sharkbait@mac.com>     <http://www.media.demon.co.uk>
>    <phone:+44.[0].207.737.6831>        <pager:jermq@sms.genie.co.uk>
>
>


Mime
View raw message