[EMAIL PROTECTED] wrote:
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23901>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23901
[PATCH] [woody], adding <wd:on-phase> and moving load() and save() to Form.
------- Additional Comments From [EMAIL PROTECTED] 2003-10-18 11:03 -------
You're introducing here non-widget elements as child of the wd:form element.
This makes me think that now might be a good time to introduce a wd:children
element as child of the wd:form element, in which all child widgets would be
wrapped, something like:
<wd:form> <wd:on-phase ... /> <wd:children> <wd:field ... /> ... </wd:children> </wd:form>
This enables us to distinguish widgets from other configuration elements, so
that we can keep the strong checking. I'd do the same also for the children of
the wd:repeater.
I've got the same idea about encapsulating the children of the <wd:form>, but that would break other people forms, and I didn't want to make that without asking here first on the list.
+1 also for having an enclosing tag for child widgets. But I don't like much the "wd:children" name, which I find not descriptive enough. What about "wd:items" or "wd:widgets". I prefer "wd:items" as, in the case of a repeater, these widgets are not the immediate childrens of the repeater (these are the rows).
As for compatibility, we can have a temporary compatible mode that considers that if there's no "wd:items" (or whatever its name) element, then all direct children of the "wd:form" elements are considered as widgets and a nice error message is written in the logs.
Then something else: please try to leave out stuff like this in your diffs:
- formDefinition.setId("");
- setLabel(formElement, formDefinition);
+ formDefinition.setId( "" );
+ setLabel( formElement, formDefinition );
it makes the diffs harder to read, and it doesn't follow the style of the rest of the Cocoon code anyway.
I apologize for that, I'm kinda new to the diff stuff, thanks for the hint.
But what do you mean by the style of the cocoon code, you mean in the above 2 sentences or in the rest of the patch? or better asking, is there any coding style guide for cocoon patches?
It's Sun's standard code style, with no extra spaces between parenthesis and parameters.
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } Orixo, the opensource XML business alliance - http://www.orixo.com
