cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Quinn <je...@media.demon.co.uk>
Subject Re: [announce] XMLForm - a new project using Xerces, Xalan, & JTidy
Date Mon, 28 Feb 2000 12:10:50 GMT
On 27/2/00 at 3:11 pm, balld@webslingerZ.com (Donald Ball) wrote:

Donald,
Thanks for starting this off.
I am sure you understand that I am not chastising you for having produced the
"wrong thing", we just have different goals. What you produced fired my
imagination as to how this could be done within Cocoon and why.


>On Tue, 22 Feb 2000, Jeremy Quinn wrote:
>> On 21/2/00 at 4:24 pm, balld@webslingerZ.com (Donald Ball) wrote:

>> Sorry to say this, considering how much work you have already done, but 
>could
>> this Form handling functionality be considered for inclusion into Cocoon?
>> If so, how should it interact with SiteMap, XSL and XSP?
>
>It's possible, I suppose, but I think a marriage would be forced, at best.
>I see the two projects as complementary. What advantage would be gained by
>putting this functionality inside cocoon itself somewhere?

I feel that a generic way of handling form input is important to Cocoon.

Publishing forms and and handling the data they generate involve all the same
issues of content|logic|style separation that any other publishing project
requires.

I don't see any reason why this functionality should _not_ be integrated into
Cocoon. :)

>
>> >From the README file in the distribution.
>> > <input name="xmlform:virtual" value="/news.xml">
>> > <input name="xmlform:xpath" value="/articles/article[position()=last()]">
>> 
>> Is this not a bit of a security hole? Anyone with the motivation,
>> could "explore" your XML file structure (with feedback from error
>> messages) and add Nodes wherever they like; just by modifying the
>> Form. (In fact I have some students who might think of this as fun :)
>
>Well, I wouldn't open up the XMLForm servlet to untrusted users. 

Ah Ha! Here is the difference between us .... I see the need for a generic
solution, one that is inherently secure and does not need hiding away. One that
could be safely used by anyone for any task, however sensitive.

Maybe one person will use it for sending search requests to the server, maybe
someone else will use it to allow users to make new pages on their site.
It should not matter. 

We just have different design goals ....

>Cocoon is a web publishing framework. 

And Forms are a component of web publishing ...

>XMLForm doesn't need cocoon since it
>only returns HTTP redirects (unless something goes wrong). 

I understand, though I am thinking (aloud) about whether the need is the other
way around.

>I'm all ears, otherwise I say keep the code and feature bloat to a minimum ;)

Absolutely!


OK, I am probably going to put my foot in it here .... this is just a first stab 

What I think I am trying to do, is work out if it would be possible, or even
desirable, to come up with a DTD for a FormGlue.xml file that would contain the
all the information required to specify every stage in the process of publishing
and handling Forms.

I want to do this because these are issues that will need to be solved if Bugoon
is to get off the ground.


How do I see seperation working with Forms?

Logic Contract
    What data is to be captured?
    What are the fields called?
    Where is that data to go? (XML Fragment, SQL db, email msg etc.)
    How does the data need to be transformed to fit the storage?
    What are the constraints on the data? (form checking)
Style Contract
    How should it look?
    What different formats should the form be output in? (HTML, WAP etc.)
Content Contract
    What are the default values for the form?
    What should you get when you fill in the form correctly?
    What is the content of the page the form is in?


What processing needs to happen (due to my flawed understanding of how this will
be effected by the SiteMap and XSP, this is probably garbage :)

The Form is rendered
    Authorisation? (optional)
    Choose Browser (optional)
    Collect page content 
        (based on user-lang or some other context)
    Collect Form Field default values 
        (based on user-lang or some other context)
    Collect Form Field "inherited" values (optional)
        (Maybe someone is editing or correcting existing data or 
        form submission)
    Assemble the Form
    
The Form is submitted
    Authorisation? (optional)
    Convert PostArgs (or "GetArgs") into an XML Node, using "glue" to 
        define which Field goes into which Element.
    Check the data. 
        too long, too short, coercable to correct data-type, valid URL, 
        whatever ...
    Data Action (optional)
        Storage: static or calculated FilePath, XPath expression, SQL 
            connection defs, email address, etc.
        Trigger: Method to invoke with Form XML
            Maybe we are controlling a Robot or linking to a Merchant Server
    Generate response
        Send back the pre-filled form, with error messages if incorrect
        Redirect to, or assemble response page
        or chain to next Form (pre-filling accepted data into hidden fields)

Basically, if this functionality is not built into Cocoon, we will all be
re-inventing the wheel .... whenever we need forms in our sites.

Maybe I am only seeing my little bit of the Forest :)
    (English expression: Can't see the wood for the trees)


I hope this makes sense to SOMEBODY!  :)

regards Jeremy

      ____________________________________________________________________

      Jeremy Quinn                                             media.demon
                                                           webSpace Design
     <mailto:jeremy@media.demon.co.uk>       <http://www.media.demon.co.uk>
      <phone:+44.[0].207.737.6831>          <pager:jermq@sms.genie.co.uk>




Mime
View raw message