cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Quinn <je...@media.demon.co.uk>
Subject new taglib nearly ready
Date Sun, 02 Jul 2000 13:26:12 GMT
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

   <mailto:sharkbait@mac.com>     		 <http://www.media.demon.co.uk>
    <phone:+44.[0].20.7737.6831>        <pager:jermq@sms.genie.co.uk>

Mime
View raw message