You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Jeremy Quinn <je...@media.demon.co.uk> on 2000/07/02 15:26:12 UTC
new taglib nearly ready
Hi Stefano et al,
Sorry, I am a bit over-excited ...... sorry for the long mail :)
I have been writing a TagLib for handling the interaction between HTML
Forms and XML Files on disk.
It is pretty much working! (no dist yet....)
It basically allows you to read and write to elements in XML files, using
XPaths.
Here is a snippet with 4 fields :
(this would be an example of an "add <item/> to <news/>" form)
<xfp:form action="add-item.xml" redirect="../news.xml">
<!-- Identifies a resource we're going to write new items to -->
<xfp:resource id="source">
<xfp:resource-file>../news.xml</xfp:resource-file>
<xfp:resource-node>news/item[position()=<request:get-parameter
name="item"/>]</xfp:resource-node>
<xfp:write-mode>insert-before</xfp:write-mode>
</xfp:resource>
<!-- Identifies a resource to read default values from -->
<xfp:resource id="default">
<xfp:resource-file>defaults.xml</xfp:resource-file>
<xfp:resource-node>form/news/item</xfp:resource-node>
</xfp:resource>
<!-- Identifies a form field, treats data as a String -->
<xfp:field name="titletext">
<xfp:if-post>
<xfp:write to="source" select="title">
<request:get-parameter name="titletext"/>
</xfp:write>
</xfp:if-post>
<xfp:if-get>
<xfp:read select="title/value" from="default"/>
</xfp:if-get>
</xfp:field>
<!-- Identifies a form field, treats data as an XML Node -->
<xfp:field name="bodynode" type="textarea">
<xfp:if-post>
<xfp:write as="node" to="source" select="body">
<request:get-parameter name="bodynode"/>
</xfp:write>
</xfp:if-post>
<xfp:if-get>
<xfp:read select="body/value" from="default" as="node"/>
</xfp:if-get>
</xfp:field>
<!-- write modification date if-post -->
<xfp:field name="moddate">
<xfp:if-post>
<xfp:write select="date" to="source">
<util:time format="dd/MM/yyyy"/>
</xfp:write>
</xfp:if-post>
</xfp:field>
<!-- pass through the param we are using to choose which item to edit-->
<xfp:field name="item" type="hidden">
<request:get-parameter name="item"/>
</xfp:field>
<xfp:form>
I always planned to donate the project to the Cocoon Project.
(if the project is not suitable for inclusion, just let me know, I will not
be offended :)
My first question is: would you be interested in having this added to the
dist, when it is ready?
If so, you may like to have a say in what NameSpace the TagLib uses, I use
these as a temporary measure:
xmlns:xfp="http://www.hrc.wmin.ac.uk/2000/XSP/XFP"
My packages are currently:
uk.ac.wmin.hrc.jermq.xsp.xfp.XFPLibrary
uk.ac.wmin.hrc.jermq.xsp.xfp.XFPResource
You may like to change these ...
You may or may not like the structure or paradigm of the TagLib, I'd
welcome input on this.
Plus, I'll bet there are better ways of writing most of the java ....
Key Points:
1. You can read and write from several different files at the same time,
all in the same form, so for instance, you could maintain a central
navmap.rdf while you add/remove/edit files from the structure it lays out.
No changes are written until everything is finished, with no errors. You
can also write during a GET request, so this could be used for certain
types of logging.
2. The read and write tags allow the use of as="node|string", allowing you
to define how data in the node is treated. as="string" is default, you get
"<" etc. as entities, while as="node" gives you the raw XML fragment to
work with.
3. Like in XMLForm, XPaths are supplied in two places. The XPath in
<xfp:resource-node/> provides the root context for the XPaths in the
<xfp:read/> and <xfp:write/> tags to work from.
4. unlike XMLForm, there is no need to expose the X or file paths in the form.
5. Errors are returned as XML in the tag that caused it.
6. You would make one XML file for each [structure|modification] axis pair
ie. item-edit.xml, item-add.xml, item-remove.xml, news-edit.xml; each xml
handles both POST and GET methods.
7. Designed to use XSchemas to validate the data.
8. <xfp:write-mode/> replace|insert-before|insert-after|remove with
"replace" being the default
9. the XSL required to render this to HTML is very similar to the one for
XMLForm.
10. Both <xfp:read/> and <xfp:write/> currently write directly to
xspCurrentNode (I want to change this, see below). They put their content
in a </value>. It is obvious that an as="string" should just go in as the
TextNode of </value>, but should an as="node" be put in as the actual Node
discovered by the XPath, or the _contents_ of that Node? Maybe this gets
sidestepped by points 1 and 5 below.
Future plans:
-1. Finish off an alpha :)
0. Make lots of samples (+ a bug report site? :)
1. Allow the use of "template" fragments for building new nodes I can only
have handle simple path for the "write new to" XPath at the moment, I can't
deal with complex XPaths here because I have to be able to create the
structure to write into and I can only interpret simple stuff,
select="one/two/four".
2. Allow tags to pass Nodes around better ....
ie. something like this could be used for archiving off changes to a
separate file, or moving nodes etc.
<xfp:field name="bodynode" type="textarea">
<xfp:if-post>
<xfp:write as="node" to="archive" select="body">
<xfp:read select="body" from="source" as="node">
</xfp:write>
<xfp:write as="node" to="source" select="body">
<request:get-parameter name="bodynode"/>
</xfp:write>
</xfp:if-post>
<xfp:if-get>
<xfp:read select="body/value" from="default" as="node">
</xfp:if-get>
</xfp:field>
3. Ways to work with individual attributes.
4. A way to select files or XPaths based on request language?
5. At the moment, you only get the first node selected by your XPaths. I am
thinking about how allowing multiple selections would work, and if it would
be useful. This ties in with point 1 and 10 above, if all treatment of
XPaths is assumed to be completely literal, you know exactly what to
output, but you have to have a predefined fragment to write into.
6. Abstract the "resource" mechanism, so that other types of data can be
accessed, like putting in SQL Tags, LDAP or eMail tags etc?
7. For editing, work out how to reconstruct an <option/> list for a
<select/> object, with your previous selection selected. Ugh!, can we leave
this up to the XSL?
8. Allow more than one <xfp:form> per file selecting on a parameter?
9. Choice of being able to use either sessions or hidden fields for passing
on intermediate data between accesses to the same form handler?
10. I'm sure there's more ...
I have a problem with Xerces that stops me implementing XSchemas for field
validation.
The idea is that you put a reference to a Schema in your source file
<news xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
xsi:noNamespaceSchemaLocation='news.xsd'>
XFPTagLib would use a RevalidatingDOMParser to parse resources, allowing
them to be revalidated once modified. To implement this I need
Xerces_1_1_2, which does not currently appear to work with C1.7.5-dev.
During the course of it's execution, XFPTagLib creates it's own DOMParsers,
OutputFormat and SerializerFactory. Is it possible/preferable to get these
from Cocoon? I am particularly thinking here of being able to automatically
get these objects set up according to the settings in cocoon.properties.
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>
Re: new taglib nearly ready
Posted by Olivier Richaud <ri...@cstb.fr>.
Ditto! Great work. Wanna see it!
Olivier Richaud
CSTB
office: +33 4 93 95 67 24
mobile: +33 6 87 52 53 17
www: http://cic.cstb.fr
----- Message d'origine -----
De : Ulrich Mayring <ul...@denic.de>
À : <co...@xml.apache.org>
Envoyé : lundi 3 juillet 2000 10:33
Objet : Re: new taglib nearly ready
> Jeremy Quinn wrote:
> >
> > I have been writing a TagLib for handling the interaction between HTML
> > Forms and XML Files on disk.
> > It is pretty much working! (no dist yet....)
> > It basically allows you to read and write to elements in XML files,
using
> > XPaths.
>
> Gimme it!! Wanna have! :-)
>
> Seriously, I have an XMLForm servlet running somewhere as a "temporary
> work-around" and would like to re-visit this particular construction
> site. So, get this thing committed and you'll have a beta tester :)
>
> Ulrich
>
> --
> Ulrich Mayring
> DENIC eG, Systementwicklung
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org
>
>
Re: new taglib nearly ready
Posted by Ulrich Mayring <ul...@denic.de>.
Jeremy Quinn wrote:
>
> Using XPath means that your query could get multiple hits.
> It is obvious that if you are *reading*, this is a useful thing. But if you
> are *writing* ..... what should the TagLib do?
>
> For instance, let's say I am doing a copy ... I want to archive what I am
> changing ....
>
> <xfp:write as="node" to="archive" select="*/title">
> <xfp:read select="*/title" from="resource" as="node">
> </xfp:write>
>
> This copies the node called "title" from one file to another, OK?
>
> So what would happen if there are several titles?
> More specifically, what should happen if the write XPath was phrased in
> such a way that it selects several *discontinuous* Nodes?
> At the moment, if someone specifies an XPath for a write, that returns more
> than one Hit, I return an error.
How about this idea: you write a method write_one_node that writes out
one node (plus children, perhaps). If you have an XPATH expression that
selects several nodes, you just call that method several times. Whenever
the XPATH doesn't work in the target file, your write_one_node method
returns an error.
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
Re: new taglib nearly ready
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 09:44 -0400 05/07/00, sudhi wrote:
>One more....:-)
>
>Michele Bianchi wrote:
>>
>> On Mon, 3 Jul 2000, Ulrich Mayring wrote:
>>
>> > Jeremy Quinn wrote:
>> > >
>> > > I have been writing a TagLib for handling the interaction between HTML
>> > > Forms and XML Files on disk.
>> > > It is pretty much working! (no dist yet....)
>> > > It basically allows you to read and write to elements in XML files,
>>using
>> > > XPaths.
>> >
>> > Gimme it!! Wanna have! :-)
>> >
>> > Seriously, I have an XMLForm servlet running somewhere as a "temporary
>> > work-around" and would like to re-visit this particular construction
>> > site. So, get this thing committed and you'll have a beta tester :)
Thanks everyone for their encouraging response!
I hoped to get a first version out this week, unfortunately I've got tied
up with family stuff, so it will be next week, sorry folks. I've imposed
Thursday as a deadline on myself, as I will be off for a week after that.
I also got the thumbs down on the name I have chosen (xfp:) so suggestions
would be welcome for a new name. This may result in a total renaming of all
tags ...
I have implemented several key ideas from my last post, like proper passing
of elements from one Tag to another, receiving all results of a query, not
just the first etc. I have worked out how to do write-fragment templates as
well I think.
The code is still an embarrassing mess :) particularly error handling, it
shows my lack of experience with Java, I hope to get (kind :) suggestions
on coding style when this gets released!
One big issue I am trying to get my head around ......
Using XPath means that your query could get multiple hits.
It is obvious that if you are *reading*, this is a useful thing. But if you
are *writing* ..... what should the TagLib do?
For instance, let's say I am doing a copy ... I want to archive what I am
changing ....
<xfp:write as="node" to="archive" select="*/title">
<xfp:read select="*/title" from="resource" as="node">
</xfp:write>
This copies the node called "title" from one file to another, OK?
So what would happen if there are several titles?
More specifically, what should happen if the write XPath was phrased in
such a way that it selects several *discontinuous* Nodes?
At the moment, if someone specifies an XPath for a write, that returns more
than one Hit, I return an error.
I do not know if this is adequate behaviour!
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>
Re: new taglib nearly ready
Posted by sudhi <su...@planet.net>.
One more....:-)
Michele Bianchi wrote:
>
> On Mon, 3 Jul 2000, Ulrich Mayring wrote:
>
> > Jeremy Quinn wrote:
> > >
> > > I have been writing a TagLib for handling the interaction between HTML
> > > Forms and XML Files on disk.
> > > It is pretty much working! (no dist yet....)
> > > It basically allows you to read and write to elements in XML files, using
> > > XPaths.
> >
> > Gimme it!! Wanna have! :-)
> >
> > Seriously, I have an XMLForm servlet running somewhere as a "temporary
> > work-around" and would like to re-visit this particular construction
> > site. So, get this thing committed and you'll have a beta tester :)
>
> here's another beta tester!
>
> -------------------------------------------------------------------------------
> michele_bianchi exsense | integrated_solutions
> phone://+39_348_7651874 via_scrimiari_45b
> http://mic.aesthetica.it 37132_verona_italy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org
Re: new taglib nearly ready
Posted by Michele Bianchi <mi...@research.telcordia.com>.
On Mon, 3 Jul 2000, Ulrich Mayring wrote:
> Jeremy Quinn wrote:
> >
> > I have been writing a TagLib for handling the interaction between HTML
> > Forms and XML Files on disk.
> > It is pretty much working! (no dist yet....)
> > It basically allows you to read and write to elements in XML files, using
> > XPaths.
>
> Gimme it!! Wanna have! :-)
>
> Seriously, I have an XMLForm servlet running somewhere as a "temporary
> work-around" and would like to re-visit this particular construction
> site. So, get this thing committed and you'll have a beta tester :)
here's another beta tester!
-------------------------------------------------------------------------------
michele_bianchi exsense | integrated_solutions
phone://+39_348_7651874 via_scrimiari_45b
http://mic.aesthetica.it 37132_verona_italy
Re: new taglib nearly ready
Posted by Ulrich Mayring <ul...@denic.de>.
Jeremy Quinn wrote:
>
> I have been writing a TagLib for handling the interaction between HTML
> Forms and XML Files on disk.
> It is pretty much working! (no dist yet....)
> It basically allows you to read and write to elements in XML files, using
> XPaths.
Gimme it!! Wanna have! :-)
Seriously, I have an XMLForm servlet running somewhere as a "temporary
work-around" and would like to re-visit this particular construction
site. So, get this thing committed and you'll have a beta tester :)
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
Re: new taglib nearly ready
Posted by Giacomo Pati <Gi...@pwr.ch>.
On Mon, Jul 03, 2000 at 09:09:36PM +0200, Hans Ulrich Niedermann wrote:
> Giacomo Pati <Gi...@pwr.ch> writes:
>
> > Jeremy Quinn wrote:
> > >
> > > I always planned to donate the project to the Cocoon Project.
> > > (if the project is not suitable for inclusion, just let me know, I will not
> > > be offended :)
> >
> > I think we can host it for the moment in a separate directory (lets call
> > it "donnations") in the CVS until we decide to put it somewhere else.
> > Any opposition?
>
> Yes. I suggest "donations" :-)
>
> However, usually these kings of directories are called "contrib", I
> think.
Yup :)
Giacomo
--
PWR GmbH, Organisation & Entwicklung Tel: +41 (0)1 856 2202
Giacomo Pati, CTO/CEO Fax: +41 (0)1 856 2201
Hintereichenstrasse 7 Mailto:Giacomo.Pati@pwr.ch
CH-8166 Niederweningen Web: http://www.pwr.ch
Re: new taglib nearly ready
Posted by Hans Ulrich Niedermann <ni...@isd.uni-stuttgart.de>.
Giacomo Pati <Gi...@pwr.ch> writes:
> Jeremy Quinn wrote:
> >
> > I always planned to donate the project to the Cocoon Project.
> > (if the project is not suitable for inclusion, just let me know, I will not
> > be offended :)
>
> I think we can host it for the moment in a separate directory (lets call
> it "donnations") in the CVS until we decide to put it somewhere else.
> Any opposition?
Yes. I suggest "donations" :-)
However, usually these kings of directories are called "contrib", I
think.
Uli
Re: new taglib nearly ready
Posted by Giacomo Pati <Gi...@pwr.ch>.
On Mon, Jul 03, 2000 at 07:38:06PM +0100, Ross Burton wrote:
> > > I always planned to donate the project to the Cocoon Project.
> > > (if the project is not suitable for inclusion, just let me know, I will
> not
> > > be offended :)
> >
> > I think we can host it for the moment in a separate directory (lets call
> > it "donnations") in the CVS until we decide to put it somewhere else.
> > Any opposition?
>
> I'd prefer the usual name "contrib", but +1, Cocoon needs this sort of
> thing.
Yes, "contrib" is ok forme.
Giacomo
--
PWR GmbH, Organisation & Entwicklung Tel: +41 (0)1 856 2202
Giacomo Pati, CTO/CEO Fax: +41 (0)1 856 2201
Hintereichenstrasse 7 Mailto:Giacomo.Pati@pwr.ch
CH-8166 Niederweningen Web: http://www.pwr.ch
Re: new taglib nearly ready
Posted by Ross Burton <ro...@mail.com>.
> > I always planned to donate the project to the Cocoon Project.
> > (if the project is not suitable for inclusion, just let me know, I will
not
> > be offended :)
>
> I think we can host it for the moment in a separate directory (lets call
> it "donnations") in the CVS until we decide to put it somewhere else.
> Any opposition?
I'd prefer the usual name "contrib", but +1, Cocoon needs this sort of
thing.
Ross
Re: new taglib nearly ready
Posted by Giacomo Pati <Gi...@pwr.ch>.
Jeremy Quinn wrote:
>
> I always planned to donate the project to the Cocoon Project.
> (if the project is not suitable for inclusion, just let me know, I will not
> be offended :)
I think we can host it for the moment in a separate directory (lets call
it "donnations") in the CVS until we decide to put it somewhere else.
Any opposition?
Giacomo
--
PWR GmbH, Organisation & Entwicklung Tel: +41 (0)1 856 2202
Giacomo Pati, CTO/CEO Fax: +41 (0)1 856 2201
Hintereichenstrasse 7 Mailto:Giacomo.Pati@pwr.ch
CH-8166 Niederweningen Web: http://www.pwr.ch