cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Angel Faus" <af...@derecho.org>
Subject Some thoughts about XMLForms and symmetry on Cocoon
Date Thu, 09 Mar 2000 23:33:35 GMT
Hi Everybody.

While studying the XMLForm servlet designed by Donald Ball, i come around
with some ideas I'd like to share with you. Those ideas grow bigger and are
now nearly a proposal. If you like what I am suggesting here, I would be
happy to contribute to the completion of the project.

Well... The stuff is about Symmetry on Cocoon. Everybody has talked a lot
about symmetry on Cocoon in this list, but i think this is still a missing
piece on the Cocoon Framework.

I wanted to make a project to allow content developers in our company  to
author XML files, using Web Forms and without any XML knowledge (so my
project is very similar to XMLForms one). The main difference is that I do
want the forms to be automatically generated, in fact i want to create a
complete accounts/passwords system, and to define which documents (Schemas)
each developer can write, and in which place is he going to be able to store
them. I want also to write automatically indexes of the XML files that are
generated within a directory, and to be able to create directories. I want
also to use namespaces, so different developers can edit different
namespaces of the same document (an author creates de document body, an
editor qualifies it and writes a summary, a simple user votes it... who
knows....). (Actually i have a perl version of this system, and i want to
move it to Java)

So my project goes a bit further than XMLForms, but it is essential about
the same: creating XML Files from HTML Forms.

Some more projects come around in this list the last days: Using applets so
authors can create full XML files, using new protocols (SOAP), etc... What
frustrated me is that while all these projects share a lot, the are being
developed without any chance of sharing efforts. In fact, the thing i like
worst is that none of these projects (neither my own one) solves the
Symmetry problem in Cocoon. Cocoon is designed to publish XML files, no to
create them. And i understand too that there is not a single good solution,
but that there some different solutions suited for different authoring
environments.

I noticed that some stuff in the XMLForms could be considered, in the Cocoon
Framework, as just some more pieces of its own Framework. I explain myself:
the ability of parsing HTML, XML and text forms could be considered as just
3 different XML Generators, that take a Stream and generate a Document of
it. We could even have more Generators: MathML from TEX, X3D from VRML, and
a bunch of custom ones. They should be able to handle not just forms but
also file uploads, so a user can upload a file using a form and have it
stored in the server as a XML node.

All these pieces could be designed as Generators and be used by all XML
authoring projects... and even by Cocoon itself: maybe you would want to
store the TEX files as TEX, and only create the MathML when the user asks
for it. You could even use standard cocoon Transformers (i.e., XSLT) in the
Form Chain, so you make a xslt transformation on the XML before storing it.

So this would be the first step, move the 3 types in XMLForms to Cocoon
Generators (then create new Cocoon Generators) and use them everywhere.
Cool.

(I don't know if the should be Generators or maybe a subinterface of them; i
would like to ask Stefano as Cocoon2 Interfaces designer, what do you
think?)

But i would like to de some more changes. Imagine you want to store the Data
in a XML Database, or even in a SQL Database... or imagine you want to send
a mail with it... how can you do it??. And also, we need a simple way to
solve in a general way, the XML files authoring problem, and it should be,
at least, as easy for the webmaster as XMLForms.

Well...what i came out it's a pretty radical solution, and there will be
probably many people that will disagree with me. Anyway is the best i got, i
like it, and I'll be happy even if it's just a start point.

I think that we should solve this problem in the XSP context. I don't mean
adding a new XSP library... but changing the XSP stuff itself (in fact
adding more features to it).

What i would like is to add a new xsp tag: <xsp:cocoon-chain>.  (Yes, I
know. It's not a good name. Go and change it). This tag allows to create a
chain of Generators/Filters that feed an xsp library, which is the one which
is really going to store the data.

Let's start with an example that does not use "cocoon-chain" at all. Imagine
you want to send a mail with the contents of a request. You just do (into
your xsp page):

<mail:send>
    <from></from>
    <to> </to>
    ... al the headers...

    <body><request:get-parameter name="body"></body>
</mail:send>

Now imagine you want to do some more complicated stuff... one of the input
boxes will be a SVG graphic, and you want to validate it;  and you want to
use an xslt transformation too before sending the mail. You would do:

<mail:send>
    <from> </from>
    ....
    <body>
        <image>
        <xsp:cocoon-chain>
            <generator name="XMLParser"/>
                <param name="content"><xsp:attribute name="value">
                        <xsp:expr>request.getParamater("Body")<xsp:expr>
                </xsp:attribute></param>
                <param name="schema" value="http://svg-schema-uri"/>
            </generator>
            <filter name="xslt">
                 <param name="stylesheet" value="foo.xsl"/>
            </filter>
        </xsp:cocoon-chain>
        </image>
    </body>

</mail:send>

Let's go a bit further. Now i want to edit a file i have on my file system:

<file:edit>
    <file>myfile.xml</file>

    <file:node xpath="/root/generator">
        My Authoring System 1.0
    </file:node>

    <file:node xpath="/root/title">
        <xsp:expr>request.getParamater("title").<xsp:expr>
    </file:node>

    <file:node xpath="/root/body">
        <xsp:cocoon-chain>
            <generator name="HTMLParser">
                <param name="content">
                <xsp:attribute
name="value"><xsp:expr>request.getParamater("Body")<xsp:expr></xsp:attribute
>
                </param>
            </generator>
        </xsp:cocoon-chain>
    </file:node>

</file:edit>

Let's take a look to this example with some more detail.

    -<file:edit>is the tag of the xsp library that stores the result of the
inside stuff into the file
    -<file:node xpath="/root/title"> is just a file:edit library
specific-tag. It tells the file:edit library where to store the following
data.
    -<xsp:expr> is just standard nowadays XSP. You could have used here
<xsp:logic> or plain text, or a library tag or ...
    -<xsp:cocoon-chain> is the new tag. Here you define who is going to be
the Generator, which transformation do yon want to do, etc...

This three samples show also that the real job is going to be in the xsp
libraries. Since these xsp:libraries are so important, I think that there
should be a general guidelines of the "storer" libraries, so i can change
the target of my data (for instance, from a XML file to a XML database)
easily.

Let's make a summary of what i am proposing:
    - Create a series of Cocoon components designed for creating XML content
(instead of publishing it), but sharing the framework with "traditional"
components.  (And maybe create a new interface.. ¿?)
    - Create a "xsp:cocoon-chain" tag (or a cocoon-chain library) that
allows xsp pages to generate sitemap chains for their own use.
    - Create a bunch of "authoring" libraries.  i.e., libraries that
effectively store the data: File, SQLDatabase, Mail. (some of them may
already have been done.. i don't know exactly the features of de SQL and
Mail taglibs).
    - Rewrite XMLForm to use this framework. (shouldn't be difficult)

I know the most delicate point is the creation of the xsp:cocoon-chain one.
In fact we are changing many things if we change it, but... it's the key
point, because is where the symmetry problem is solved: it allows you to use
chains of Producers + Filters + Serializers in the authoring fase.

(In fact, it could be seen as a more general improvement: it allows you to
"fork" the chains, breaking the linearity: current Cocoon model enforces a
linear chain:
 Generator => .. => XSP => Transformer => ... => Serializer
The <xsp:cocoon-chain would allow):
Generator => .... => XSP => .... => ... => Serializer
                                |
                                |=> Generator => Transformer => .... etc..
)

<OFF-TOPIC>
This reminds me another feature i miss in Cocoon framework: why Serialized
Data => Serialized Data transformation components are not allowed. I mean
something like a PNG=>JPEG conversion). Maybe this have been discussed
before, are there any good reasons not to do that?
</OFF-TOPIC>

When we have this, we will have a much easier (and general) way to expand
XMLForm, and also the ability (which i would definitely encourage) to store
Xpath stuff in the server XSP, not in a HTML page that the user can crack,
or to add security stuff, or to..... i guess you know what i mean.

Not so hard.. and useful.

All this stuff just handles the last part of the process, when the user
sends the request. The next step is to generate the forms. This my
suggestion (and what i will try to implement). Use XSchema of the document
plus a extra file in which we store what are the values that the user can
edit (i would call it a document-view). This could be a first try:

<document-view schema="my-schema.xml">
    <node xpath="/root/title" type="shorttext" name="title/">
    <node xpath="/root/body" type="longtext" name="body"/>
    <node xpath="/root/karma" type="schema-select" name="karma-select"/>
</document-view>
(schema-select means the form should show a select combo, offering the
values that are allowed by the schema)

(You could have differnet document-views for different permissions set).

And then in your xsp page you use a library that works this way:

<form view="docview.xml"/>
    <title>My First Document</title>
</form>

This means: create a full form with all the allowed boxes empty, except the
'title' input which is set to "My First...".

I know needing 4 files (schema, document-view, xsp sending page, xsp
responding page) is too much. Schema should be optional (unless you want to
use this smart "schema-select" features or similar stuff). I don't see any
good way to reduce that, because you are in fact defining different things:
what do you allow to edit, what do you want do with the response, what are
the default values you want to use in each case. Separation of contexts
should work here too. Anyway i know many people is working on this same
problem, so i would be happy to use any standard way of doing it.

So this is what i am suggesting: if you like this stuff, i will be happy to
implement it (I need this stuff anyway, so...). I would prefer somebody of
the Cocoon Core team to do the <xsp:cocoon-chain> (because it means changing
the cocoon internals), but i will do it if everybody else has better
priorities. I will definitely code the storing xsp libraries (first step),
and the form creating stuff (second step), the rewriting of XMLForm into the
Generators framework (If Donald Ball agrees) and then i will go for the
complete stuff (permissions system, etc... )

(I know everybody is in the ApacheCon, and you all will probably come with a
lot of great ideas on your mind, but i will really appreciate comments on my
suggestions).

Thanks for your time and for your great job.

    Angel Faus.
    afaus@derecho.org
    Derecho.org TEO




Mime
View raw message