Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 64494 invoked from network); 14 Jan 2004 23:10:40 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 14 Jan 2004 23:10:40 -0000 Received: (qmail 86384 invoked by uid 500); 14 Jan 2004 23:10:22 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 86358 invoked by uid 500); 14 Jan 2004 23:10:22 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: dev@cocoon.apache.org Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 86345 invoked from network); 14 Jan 2004 23:10:22 -0000 Received: from unknown (HELO mail.gmx.net) (213.165.64.20) by daedalus.apache.org with SMTP; 14 Jan 2004 23:10:22 -0000 Received: (qmail 4458 invoked by uid 65534); 14 Jan 2004 23:10:28 -0000 Received: from a183069.studnetz.uni-leipzig.de (EHLO gmx.de) (139.18.183.69) by mail.gmx.net (mp001) with SMTP; 15 Jan 2004 00:10:28 +0100 X-Authenticated: #3483660 Message-ID: <4005CCA5.1030409@gmx.de> Date: Thu, 15 Jan 2004 00:11:33 +0100 From: Joerg Heinicke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: de-de, de, en-us, en-gb, en MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: [Woody] observations, issues, questions, best practices Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Hello, at work I may convert a Struts application into a Woody one. I played around with the Woody samples and created a form handling prototype for my application. But I came across some problems and made some observations I want to point out here. On the other hand the architecture is not "fixed", especially the communication with the backend, so the handling of the business logic is not that perfect. 1. When the template contains a reference to a not defined widget, I get an exception: "EffectWoodyTemplateTransformer: Widget with id "addcontact" does not exist in the container." What would be helpful in this error message is the mentioning of the file and the line number. 2. When a flow script function is not available (called via woody2.js, line 213) I only get a "CascadingRuntimeException: The undefined value has no properties." Isn't it possible to give a more exact explanation or at least to point to the expression that returns undefined? 3. JXTemplateGenerator: Here I mixed ${} and #{} and / and , so I got a double coercion exception - what ever that means. I found it out because I did only little steps. 4. The switching of binding to XML or beans costs to much effort. Binding file, JXTemplate (for the result), flow script. Maybe I did something the wrong way, but the XML needs at least a root element, why this would be annoying for the bean. Some ideas for that? 5. Closely related the next question: The bizData passed from sendPage() is it simply an object? What are the constraints? I know it's accessed in the Woody samples in the success pages via JXTemplateGenerator. The reason i ask is the need of a JXTemplate for every type of these success pages. I don't like that, but would like much more a generic generator that converts bizData into SAX events. 6. Next thing is about what we called table view in our LoFEx project. It's closely related to the repeater we already have and I like very much. The feature I didn't see at first sight is the native support for switching between parts of a result set (e.g. rows 1 - 10, rows 11 - 20, and so on). Something like first-page, next-page, last-page, previous-page actions are missing. 7. A short question: When to use wd:submit in the definition file and when a simple in the template? 8. Why a wd:submit needs an @action-command? I tried the solution at http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106814306509920&w=2, which does work because of missing attribute. I simply added @action-command="cancel", but without any usage. 9. Now I come to the unsure part of my prototype. The architecture I imagine at the moment is really Struts-like. I bind the values of the form to a bean and call an Action with the bean as parameter. This will cause much typing - the more granular the better, but the more typing. It's more a question for best practices. How do you meet such requirements? 10. And a last question: validating the form in application context (e.g. simple case "login already exists"). Last week there was a discussion about it. Are there any restrictions or constraints about it or is it just an arbitrary method call that returns true or false? So, I would like to hear you comments, proposals or what ever you like. Joerg