Mailing-List: contact users-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cocoon.apache.org
Message-ID: <3F9D8D0C.5070600@web.de>
Date: Mon, 27 Oct 2003 22:24:28 +0100
From: joern turner <joern.turner@web.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.5) Gecko/20031007
MIME-Version: 1.0
To: users@cocoon.apache.org
Subject: Re: JXForms vs. Woody vs. KISS
References: <3F9CD514.10716.4B186B2@localhost>
 <3F9D5949.8040305@olegdulin.com>
In-Reply-To: <3F9D5949.8040305@olegdulin.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Oleg Dulin wrote:
>  > I've been using Chiba (and a pre-release version of Chicoon which 
> integrates Chiba with Cocoon) quite extensively on a client project, but 
> I have not had to write any server-side code yet. Some XSL transforms. 
> Some declarative XML files which specify the form definition (using a 
> mix of XForms and XHTML)...but no code.
>  >
> 
> Has Chicoon been updated to work with Cocoon 2.1 ? I noticed the 
> released archive is from April, 2003 , older than Cocoon 2.1 .
> 
>  > So I'm a bit puzzled as to why you think Chiba XForms needs server 
> side code added since this is contrary to my recent experiences.
> 
> 
> If the requirement is simply to show a form based on an XML file, let 
> the user edit it, validate it, and then save the updates, then this can 
> be easier done with a simple pipeline and I see no reason to deal with a 
> yet another framework outside of Cocoon.
but didn't you mentioned standard conformance on your wishlist? sure, 
there are many form frameworks out there with more or less functionality 
or elegance but if you want to go for a standard you'll hardly escape 
XForms. with xhtml2 it will be part of the standard and replace the html 
forms.

> 
> Here is an example:
> 
> - I have an XML document
> - I want to prepopulate an HTML form and present it to ther user based 
> on the values in document
> - The user edits the form and clicks "Save"
> - The values are extracted out of POST parameters and saved back to the 
> original document.
this is exactly what Chiba does for you. and, of course you don't have 
to care about the mapping of request to document and back - this is 
handled automatically.

> 
> First two points are trivial, because all one needs to do is transform 
> original document into an HTML form.
> 
> The remainder is tricky. I accomplished this by setting up an internal 
> pipeline that uses RequestGenerator to create an XSL transform called 
> "update.xsl" that applies the changes to the original document. To know 
> which form values go to which places in the original document I used 
> xpaths of the original elements and attributes as names for input 
> fields. So, an XSL can be generated that applies the changes to the 
> original doc and wraps it in something that SOurceWritingTransformer can 
> understand.
Chiba has a similar concept but without exposing xpathes of the instance 
(for security reasons). it uses a mapping between xpathes and internally 
generated ids.

> 
> Is there a Cocoon solution that would let me easily set up a form that 
> essentially edit XML w/o all of the aforementioned convoluted XSLTs ? To 
> rephrase -- is there a way to map XML document onto an HTML form and 
> then apply the changes back to the original document other than what I 
> mentioned ?  Would Chicoon or Woody be helpful ?
Chicoon is soon available as a integration of the latest Chiba code 
(0.9.2) and therefore providing all the additional functionality added 
since Chiba 0.8.

Joern
> 
> Kind regards,
> Oleg
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org