You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Angel Faus <af...@derecho.org> on 2000/03/10 00:33:35 UTC
Some thoughts about XMLForms and symmetry on Cocoon
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
Re: Some thoughts about XMLForms and symmetry on Cocoon
Posted by Niclas Hedhman <ni...@localbar.com>.
Angel Faus wrote:
> Ok. I agree with you that it would be better i we could get the same effect
> without having to make any significant changes in the XSP stuff. What's
> exactly your suggestion? I mean, how would you start a chain of Generator +
> Filters within a XSP file, and then being able to use the output of that in
> the next step of the xml processing?? The idea is having the ability to
> start a chain whose output doesn't got the client browser, but to another
> consumer (a XSP library): XML file, Mail, XML database, whatever....
In fact, the original proposal some months ago was not specific to the XSP, but
to Cocoon in general in respect to the then upcoming SiteMap.
So I guess we are at a point of conflict. Is XSP independent of Cocoon? Should
all XSP pages be execution compatible in all its running environments? If the
answer is YES, then you need to do some serious thinking. What resources must
be provided to the XSP author? File system? Network? Security? and so on.
But Stefano, I believe, myself and others more sees XSP as a language
independent and platform/environment independent compiled code generation out
of XML syntax. May it be Java, Perl or C++. May it be interpreted or compiled
natively to the hardware. May it use any resource available or not.
And if this is the case, Cocoon is ONE XSP environment, which has a defined set
of resources available. One of them would be the SiteMap, and if the SiteMap is
a pluggable module, which can be of any complexity you may think of, you are
practically free to come up with any strategy you wish.
The XSP code gets hold of the SiteMap object and instruct it how to proceed.
Cocoon will ask the SiteMap for next stage, and so forth.
I am not sure whether Pier has moved into this yet, but I am pretty sure there
will be something along these lines in Cocoon 2.
Niclas
RE: Some thoughts about XMLForms and symmetry on Cocoon
Posted by Angel Faus <li...@derecho.org>.
>
> I have earlier proposed that the SiteMap is generated from a pluggable
module.
> Normally, it is a standard "FileProducer" that picks up a static file and
> parses it, and hand over the the SiteMap object for each request
processed. But
> here you could extend with your dynamic stuff, and also establish your
link
> into the XSP realm.
>
> That would probably mean that your new tag is not needed, which I believe
is
> not clean by design.
>
Ok. I agree with you that it would be better i we could get the same effect
without having to make any significant changes in the XSP stuff. What's
exactly your suggestion? I mean, how would you start a chain of Generator +
Filters within a XSP file, and then being able to use the output of that in
the next step of the xml processing?? The idea is having the ability to
start a chain whose output doesn't got the client browser, but to another
consumer (a XSP library): XML file, Mail, XML database, whatever....
Would your solution just work in the Java level (i mean would it be just for
current java XSP, or could it be accessed by Perl/Python/... XSP? And...
would it be architecture dependent, so whenever Cocoon changes its
architecture all the XSP made using this stuff becomes obsoleted, or would
it provide enough abstraction??
I think that a <xsp:cocoon-chain> tag cannot be reduced to just another XSP
library, because it something that affects strongly the xsp works... its not
just another library. (but maybe i am wrong; i would welcome improvments in
the design, in order to make it clean enough).
I am very interested in your suggestion.. but i would like to understand the
details better.
Thanks in advance.
Angel Faus.
Re: Some thoughts about XMLForms and symmetry on Cocoon
Posted by Niclas Hedhman <ni...@localbar.com>.
Long mail, and frankly speaking it is too early in the morning to understand it
all. I will focus on one single thing.
Angel Faus wrote:
> - Create a "xsp:cocoon-chain" tag (or a cocoon-chain library) that
> allows xsp pages to generate sitemap chains for their own use.
I have earlier proposed that the SiteMap is generated from a pluggable module.
Normally, it is a standard "FileProducer" that picks up a static file and
parses it, and hand over the the SiteMap object for each request processed. But
here you could extend with your dynamic stuff, and also establish your link
into the XSP realm.
That would probably mean that your new tag is not needed, which I believe is
not clean by design.
Niclas
Re: Some thoughts about XMLForms and symmetry on Cocoon
Posted by Stefano Mazzocchi <st...@apache.org>.
Angel Faus wrote:
> (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).
I really appreciated your proposal since I believe you put lots of
reasoning into it and it's _always_ a great thing to do.
But having spent the last week thinking along these lines while writing
my slides using Cocoon, I believe that your proposal is wrong by design
(hey, don't worry, it was the same thing that occurred to me too!)
The fact is that by using something like "xsp:chain" (as Niclas wisely
outlines) you not only tie XSP to Cocoon's sitemap, but also make the
two things overlap. In fact, you are using part of the sitemap
capabilities inside XSP as new functionalities.
Instead, I believe is more reasonable to have a good support for
inclusion of other cocoon-generated URIs, as Ricardo is doing right now.
So you simply say "I want the result of that URI here" and Cocoon will
be called again. The result can be either created at runtime (if
dynamic) or at compile time (if static).
Also, in case you want to change how that URI is created, you do so in
the sitemap, and you don't mess up with the XSP page.
Everyone agrees that the functionality you propose is a great thing to
have. But many of us believe that having a programmatic include is
better than specifying how to generate it using subchains.
Also, it's a dangerous path to follow: people will want to do subchains
inside subchains and so on. With programmatic inclusion you gain the
same power without loosing any of what you already have.
Hope it makes sense.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Come to the first official Apache Software Foundation Conference!
------------------------- http://ApacheCon.Com ---------------------
RE: Some thoughts about XMLForms and symmetry on Cocoon
Posted by Angel Faus <li...@derecho.org>.
> Donald and I have just agreed to collaborate in developing a proposal for
an XSP
> TagLib to implement some of what you are proposing with regard to Form
handling,
> building, checking, processing, storing etc.
>
> Whether we are successful or not will be another issue :)
>
> My hope is that this will result in a generic TagLib that will
considerably
> assist the whole process of having HTML Forms on Cocoon sites, for
whatever
> purpose. Further that this TagLib will embody good design practise in
terms of
> the separation of contracts ... logic, content, style.
>
> Your suggestions are useful, it helps me understand what this thing needs
to do
> to be truly a generic solution.
>
>
I will wait anxiously your proposal... :)
My humble suggestion would be to differentiate whether the forms are used to
create a XML document, or to edit a existing one. In the second case, what i
was suggesting is to separate in different files the "view" definition (what
is the user allowed to edit); the style (xslt) and the default values of the
form (this would be decided in the dynamic xsp file). This means further
separation that just logic/content/style.
The benefit of having the view stored in a different file is reusability and
a new level of abstraction, specially in the context of a "authoring suite"
i was suggesting.
Thanks for your attention.
Angel Faus.
Re: Some thoughts about XMLForms and symmetry on Cocoon
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On 10/3/00 at 12:33 am, afaus@derecho.org (Angel Faus) wrote:
>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.
Donald and I have just agreed to collaborate in developing a proposal for an XSP
TagLib to implement some of what you are proposing with regard to Form handling,
building, checking, processing, storing etc.
Whether we are successful or not will be another issue :)
My hope is that this will result in a generic TagLib that will considerably
assist the whole process of having HTML Forms on Cocoon sites, for whatever
purpose. Further that this TagLib will embody good design practise in terms of
the separation of contracts ... logic, content, style.
Your suggestions are useful, it helps me understand what this thing needs to do
to be truly a generic solution.
regards Jeremy
____________________________________________________________________
Jeremy Quinn media.demon
webSpace Design
<ma...@media.demon.co.uk> <http://www.media.demon.co.uk>
<phone:+44.[0].207.737.6831> <pa...@sms.genie.co.uk>