Dear Richardo (or someone else with TagLib experience)
I am trying to develop a proposal for a generic Form Handing TagLib.
The idea is that the TagLib will allow the inclusion of other TagLibs
for I/O purposes.
ie. a form handler may want to make use of a File R/W TagLib, or the
SQLTagLib etc. to read and modify XML resources via a form.
My confusion is this:
How do TagLibs interact when there is more than one in the XML file?
What happens when they are nested within each other?
What effect does the order of the namespace declarations have?
My understanding is that it is the order of the declarations:
<xsp:page
language="java"
xmlns:xsp="http://www.apache.org/1999/XSP/Core"
xmlns:util="http://www.apache.org/1999/XSP/Util"
xmlns:sql="http://www.apache.org/1999/XSP/SQL"
xmlns:form="http://www.thing.org/2000/XSP/Form"
>
which defines what order the TagLibs are "expressed", not the nesting.
Is this true?
thanks for any help
regards Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@sms.genie.co.uk>
>Jeremy Quinn wrote:
>> I am trying to develop a proposal for a generic Form Handing TagLib.
[snip]
>> My understanding is that it is the order of the declarations:
>> which defines what order the TagLibs are "expressed", not the nesting.
>
>Yes, it's the namespace declaration order (or the order
>of <?xml-logicsheet?> directives) that governs the order
>in which logisheets are applied. It's declaration order,
>rather than nesting (which should never been necessary,
>see below).
[snip]
>Now, what do we understand by nesting? The inclusion of one
>stylesheet into another (i.e., <xsl:import>, <xsl:include>)?
>The use of external entities (&include;)?
[snip]
>Please, describe your form logicsheet design in more depth,
>especially in relation with its multiple IO strategy support.
>This sounds very interestring...
Dear Ricardo,
Thank you for your speedy reply.
The Form TagLib is at a very early stage of design. There are so many
different ways it could go at the moment .... I am using this project to
learn how to do TagLibs, I wish I had chosen a simpler project for my first
one!
[search for "xml:form" in the CocoonDev archives]
The basic idea is to design a TagLib that allows you to map a data-source
to a form.
It needs to cover issues such as :
mapping between incoming form fields and XML elements (glue)
checking incoming form field values (constraints)
transforming incoming and outgoing form field values (transforms)
storage and retrieval from data sources (stores)
post-processing (actions)
I was beginning to define a markup language for doing this, then someone
suggested using XSchema instead. Apart from the fact that I am almost
completely clueless about XSchema (except that it sounds like the best way
to go) it would probably completely change the way we do things. (Hence no
examples of the structure we have defined .....)
The issue about nesting is this:
I had planned a top-level tag called <form:handler> that contains all of
the information required to handle a particular bit of form handling for a
particular DTD. There could be several <form:handler>s in each XML file,
eg. some for editing, some for adding new objects etc. The choice of
<form:handler> is made by a path parameter or HTTP Method.
Each <form:handler> contains glue, constraint, store etc. elements.
The store element then contains whatever Tags are required to use the
storage TagLib you want, eg. SQL, FileI/O, Email, LDAP, RMI, XML/RPC, etc.
But I realise this just is not going to work, TagLibs are not "expressed"
according to their position, but the order of their xmlns declaration.
In my TagLib the processing order would need to be contextually defined.
ie. I am Editing existing data ....
Get Form (a <form:handler>)
Read Store
Translate Store structure to Field structure according to Glue
Transform Form structure to HTML via XSL
Post Form (another <form:handler>)
Translate Field data to Store structure
Verify Field data according to Constraints
Write Store
Build response and transform to HTML
So, I am hoping to have one TagLib use another for I/O. My TagLib should
not need to know how to do I/O itself, right? If, lets say, I am using the
SQLTagLib, there would be several different functional groups of SQL Tags
in the file, only one of them relevant to the current form handling process.
I am beginning to think with is not possible, because there is no way of
selecting which one would be expressed, and when.
I'm stuck !
I am sorry, but the confused and rambling nature of this message,
accurately reflects the confusion I am in regarding TagLibs. So few people
on this list actually understand this stuff .....
Thanks for any help
regards Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@sms.genie.co.uk>
Donald Ball wrote: > > On Sun, 28 May 2000, Ricardo Rocha wrote: > > > Yes, it's the namespace declaration order (or the order > > of <?xml-logicsheet?> directives) that governs the order > > in which logisheets are applied. It's declaration order, > > rather than nesting (which should never been necessary, > > see below). > > Where is the xml-logicsheet PI thing documented on the web site? It's not there yet, I have to update this document, sorry Ricardo
On Sun, 28 May 2000, Ricardo Rocha wrote: > Yes, it's the namespace declaration order (or the order > of <?xml-logicsheet?> directives) that governs the order > in which logisheets are applied. It's declaration order, > rather than nesting (which should never been necessary, > see below). Where is the xml-logicsheet PI thing documented on the web site? - donald
Jeremy Quinn wrote: > I am trying to develop a proposal for a generic Form Handing TagLib. > > The idea is that the TagLib will allow the inclusion of other TagLibs > for I/O purposes. > > ie. a form handler may want to make use of a File R/W TagLib, or the > SQLTagLib etc. to read and modify XML resources via a form. > > My confusion is this: > > How do TagLibs interact when there is more than one in the XML file? > What happens when they are nested within each other? > What effect does the order of the namespace declarations have? > > My understanding is that it is the order of the declarations: > > <xsp:page > language="java" > xmlns:xsp="http://www.apache.org/1999/XSP/Core" > xmlns:util="http://www.apache.org/1999/XSP/Util" > xmlns:sql="http://www.apache.org/1999/XSP/SQL" > xmlns:form="http://www.thing.org/2000/XSP/Form" > > > > which defines what order the TagLibs are "expressed", not the nesting. > > Is this true? Yes, it's the namespace declaration order (or the order of <?xml-logicsheet?> directives) that governs the order in which logisheets are applied. It's declaration order, rather than nesting (which should never been necessary, see below). Important exception: xmlns:xsp="http://www.apache.org/1999/XSP/Core" will be applied always _last_, regardless of its position within the logicsheet declaration list. In you example, logicsheets would be applied in the following order: - Util - SQL - Form - XSP I tend to put "util" at the end of the list (right before XSP) because other logicsheets may typically want to reuse the general-purpose functionality provided by this logicsheet. Now, what do we understand by nesting? The inclusion of one stylesheet into another (i.e., <xsl:import>, <xsl:include>)? The use of external entities (&include;)? XSP's layered approach is based on applying sequence, like in preprocessing. In principle, it's possible to apply the same logicsheet more than once: if an intermediate logicsheet generates dynamic tags belonging to the same namespace of a previously applied logicsheet (this doesn't sound like good design, though and requires using the pi'-based logichseet declaration form: <?xml-logicsheet?>) Please, describe your form logicsheet design in more depth, especially in relation with its multiple IO strategy support. This sounds very interestring... Ricardo