cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ramy Mamdouh <r...@imkenberg.de>
Subject Re: DO NOT REPLY [Bug 23901] - [PATCH] [woody], adding <wd:on-phase> and moving load() and save() to Form.
Date Sun, 19 Oct 2003 20:00:29 GMT
bugzilla@apache.org 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 bruno@outerthought.org  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.

>
>                             -==-
>
>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?

Thanks



Mime
View raw message