You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Jeremy Quinn <je...@apache.org> on 2006/12/27 17:37:41 UTC
RFC: Changes to CForms in 2.1.11-dev
Hi All
I hope you all had a good Christmas.
Santa's little helpers have been busy working on CForms over the
holiday break :)
Below is a list of changes I have in my local repo, ready to commit.
I would like to get feedback on these changes, in case of dissent, or
usecases I have not fully understood.
1. Updated to use Dojo 0.4.1 -- brings lots of improvements, bug
fixes and broader browser support.
2. Introduction of widget namespaces, allows lazy loading of widgets
via lookup from a manifest.
3. Dojo debugging is now turned on and off via an optional sitemap
parameter.
4. The contents of the optional <fi:init/> tag is now inserted after
the scripts to load dojo etc.
5. TODO: cocoon.forms.* to take over from forms_* in forms_lib.js.
Notes:
The upgrade to Dojo 0.4.1 brings us many advantages, but may break
some user's custom widgets due to changes in some of the APIs. The
work required to adapt the existing forms and ajax widgets was pretty
minor.
The widgets that come with 0.4.1 are much improved. This will make it
far easier to replace the legacy javascripts like htmlarea and the
mattkruse-libs with their dojo equivalents, while supporting a wider
range of browsers.
The main rationale for these changes has been to reduce the amount of
javascript that gets loaded by a CForms page. Currently everything
possible gets loaded, regardless of whether it gets used or not.
One of the big changes in 0.4.1 is the introduction of Widget
Namespaces, with it's auto-load mechanism, using a manifest and
namespace resolver to load the Widget's resources. This removes the
need to dojo.require Widgets before they are used :
Before :
<script type="text/javascript">dojo.require
("cocoon.ajax.FormUploadProgress");</script>
. . .
<div dojoType="FormUploadProgress"><div>Upload Progress Sample</div></
div>
After :
<div dojoType="ajax:FormUploadProgress"><div>Upload Progress Sample</
div></div>
NB. Unfortunately @class="namespace-WidgetName" is not currently
supported by 0.4.1.
The default namespace (does not need declaring) is 'dojo:'.
I have introduced 2 new namespaces for Cocoon, 'forms:' is for
widgets in cocoon.forms.* and 'ajax:' is for widgets in
cocoon.ajax.*. There is a manifest file for each new namespace that
registers the name of each Widget and provides a mapping between a
widget name and it's module and path. i.e.
cformsform --> cocoon.forms.CFormsForm which can be found in : ../
forms/js/
Unfortunately, because dojo.ns does it's resolution in lower case and
we have CamelCase widget names, we need an actual map. New widgets
must be registered there for auto-discovery to work.
The manifest for the forms namespace looks like this :
dojo.provide("cocoon.forms.manifest");
(function(){
var map = {
html: {
"cformsdraganddroprepeater" :
"cocoon.forms.CFormsDragAndDropRepeater",
"cformsform" : "cocoon.forms.CFormsForm",
"cformsrepeater" : "cocoon.forms.CFormsRepeater",
"cformssuggest" : "cocoon.forms.CFormsSuggest"
// register new Widgets in the cocoon.forms namespace here
}, svg: {
// register svg widgets here
}, vml: {
// register vml widgets here
}
};
function formsNamespaceResolver(name, domain){
if(!domain){ domain="html"; }
if(!map[domain]){ return null; }
return map[domain][name];
}
// cocoon.forms module has a dependency on the cocoon.ajax module
libraries
dojo.registerModulePath("cocoon.ajax", "../ajax/js");
dojo.registerModulePath("cocoon.forms", "../forms/js");
dojo.registerNamespace("forms", "cocoon.forms",
formsNamespaceResolver);
})();
The path is wide open for users to add their own auto-loading widget
namespaces via their own manifests. Converting existing custom
widgets to use a custom namespace is pretty trivial.
The big plus we get from this switch, is that is will be far easier
to write the CForms XSLT in a way that allows only used code to be
loaded by the browser. When we have managed to replace all legacy
widgets with dojo equivalents, the browser will only load code that
is actually used.
That pretty much covers points 1 and 2.
The next issues regard points 3 and 4: debugging and the use of
<fi:init/>.
The <fi:init/> tag, introduced in 2.1.9, was being used to add
<script/> tags into the html/head of pages *before* dojo was loaded.
It was being used in a couple of samples for turning on dojo debug
mode on the browser.
Debugging can now be turned on from the sitemap :
<map:transform src="resources/forms-samples-styling.xsl">
<map:parameter name="resources-uri" value="{request:contextPath}/
_cocoon/resources"/>
<map:parameter name="dojo-debug" value="true"/>
</map:transform>
Leave the param out or set it to false, to turn off debugging.
Debug messages now should go to the Browser's console (tested in
Safari, FireFox ± FireBug) instead of being written into the end of
the page. You can get navigable tree-views of your Objects even on
browsers that do not support FireBug.
The contents of <fi:init/> are now inserted *after* dojo is loaded,
so may be used for custom initialisation code required for custom
dojo widgets and other custom functions. eg.
<fi:init><!-- load my custom non-widget library module -->
<script type="text/javascript">
dojo.registerModulePath("myns.stuff", "../path/to/my/
stuff"); // relative to dojo.js
dojo.require("myns.stuff.somelibrary");
... do something with the lib now, or later in the page ...
</script>
</fi:init>
NB. dojo.registerModulePath is now used instead of the dojo.require
hack we used to have in ajax/cocoon.js.
I think this is far more useful but the change could possibly break
some user's forms.
Which leads us to point 5.
We have a complicated mixture of legacy global forms_* functions (in
forms_lib.js) and the cocoon.forms.* namespace.
I would like to make the following changes :
Deprecate forms_onloadHandlers, forms_onsubmitHandlers,
forms_getForm, forms_submitForm and forms_onsubmit. (Leave an alias
to those functions for now, but print a deprecation warning if they
are called directly, remove after the next release). Move all of that
functionality into cocoon.forms.*.
Also forms should always use a CFormsForm Widget, regardless of
whether Ajax behaviour is wanted or not. There would be two versions
of the CFormsForm Widget, one SimpleForm (@ajax='false') which is
extended by AjaxForm(@ajax='true'). CForms XSLT would choose the
right one depending on form-template/@ajax. Since dojo is always
loaded, this decision is inevitable imho.
To get closer to allowing more than one form per page, the
cocoon.forms library should manage onsubmit handlers for each
CFormsForm Widget by storing them in a global hash instead of an
Array, with the CFormsForm Widget id as the key (I'd have to change
the API). The onload handlers can remain in a global Array.
The trouble here is that this will have a far greater impact on
existing user projects.
So that's it, a lot of changes, some that may break user's projects
(but AFAICS all of the samples are still working).
Apart from general feedback, I'd like to ask for feedback on possible
widget name changes.
Firstly, are you happy with the names of the two new namespaces,
'forms:' and 'ajax:' they are named after the blocks that contain them.
Secondly, I find stuff like @dojoType="forms:CFormsRepeater" a bit
redundant now.
To me, the forms block and cforms are synonymous.
I would suggest removing the 'CForms' from the beginning of all of
the forms widget names :
@dojoType="forms:CFormsSuggest" --> @dojoType="forms:Suggest"
@dojoType="forms:CFormsDragAndDropRepeater" -->
@dojoType="forms:DragAndDropRepeater"
etc.
WDYT ? Or is this change for changes sake ?
What's next ? Make dojo replacements for all legacy code (forms_lib,
mattkruse, htmlarea etc.),
Thanks for any feedback
regards Jeremy
PS. All the samples seem to be working :)
Re: RFC: Changes to CForms in 2.1.11-dev
Posted by Jeremy Quinn <je...@apache.org>.
On 28 Dec 2006, at 09:26, Jeroen Reijn wrote:
>
>
> Jeremy Quinn wrote:
>> Hi All
>> I hope you all had a good Christmas.
>> Santa's little helpers have been busy working on CForms over the
>> holiday break :)
>> Below is a list of changes I have in my local repo, ready to
>> commit. I would like to get feedback on these changes, in case of
>> dissent, or usecases I have not fully understood.
>> 1. Updated to use Dojo 0.4.1 -- brings lots of improvements, bug
>> fixes and broader browser support.
>
> Great!
:)
>> 2. Introduction of widget namespaces, allows lazy loading of
>> widgets via lookup from a manifest.
>
> Sounds interesting.
It is a very cool feature, but it is going to create backwards
incompatibility as widget declarations have to change. If all the
user is doing is using the built-in XLST libraries, then they should
notice no difference.
>> 3. Dojo debugging is now turned on and off via an optional sitemap
>> parameter.
>
> Cool
Yes, and the debug facilities are far improved.
see : http://archive.dojotoolkit.org/nightly/tests/debug/
test_debug_console.html
>> 4. The contents of the optional <fi:init/> tag is now inserted
>> after the scripts to load dojo etc.
>> 5. TODO: cocoon.forms.* to take over from forms_* in forms_lib.js.
>
> This sounds like a good idea to me.
The cleanup has gone quite well.
However, people who have written their own cforms rendering pipelines
or custom widget will have some work to do.
>
>> Notes:
>> The upgrade to Dojo 0.4.1 brings us many advantages, but may break
>> some user's custom widgets due to changes in some of the APIs. The
>> work required to adapt the existing forms and ajax widgets was
>> pretty minor.
>> The widgets that come with 0.4.1 are much improved. This will make
>> it far easier to replace the legacy javascripts like htmlarea and
>> the mattkruse-libs with their dojo equivalents, while supporting a
>> wider range of browsers.
>
> Hmm I'm still not sure if the Dojo rich text editor is capable of
> all HTMLArea functionalities. Do your changes allow me to still
> configure my own rich text editor for certain elements in my cforms
> page?
I know you guys have a heavy investment in HtmlArea :)
Also keep in mind that I have not started work on the dojo editor
yet .....
My feelings ATM are that the Dojo Editor is probably more
lightweight, has wider compatibility across browsers, is being more
actively supported and developed and is therefore more likely to suit
common rich-text editing needs of most users.
Saying that however, I have no intention of stopping you from using
htmlarea !
Currently my intention is not to take the existing 'htmlarea' styling
and change it to output a Dojo Editor instead, but to leave the
htmlarea styling as it is, and introduce a new styling to create the
new editor.
The existing XSLT for making an htmlarea need not be removed from
cocoon, but IMO it should no longer be automatically imported into
the built-in CForms rendering XSLT as it is more difficult to make it
lazy-load than the dojo equivalent (htmlarea is always loaded in the
current cforms, regardless of whether it is used in the form and this
is one of the big issues I am trying to solve).
My proposal is that after the change to add the Dojo Editor, anyone
wanting to continue to use htmlarea should ensure that the legacy
forms-htmlarea-styling.xsl is imported into their XSLT themselves.
However, if you think that the XSLT can be adjusted so that forms-
htmlarea-styling.xsl does not unconditionally add it's load scripts
when it is not used, and does not add significantly to the render
overhead, then I would be happy to leave it in.
WDYT ?
>> The main rationale for these changes has been to reduce the amount
>> of javascript that gets loaded by a CForms page. Currently
>> everything possible gets loaded, regardless of whether it gets
>> used or not.
>
> I'm all +1 on that.
Thanks for your feedback mate !
regards Jeremy
Re: RFC: Changes to CForms in 2.1.11-dev
Posted by Jeroen Reijn <j....@hippo.nl>.
Jeremy Quinn wrote:
> Hi All
>
> I hope you all had a good Christmas.
> Santa's little helpers have been busy working on CForms over the holiday
> break :)
>
> Below is a list of changes I have in my local repo, ready to commit. I
> would like to get feedback on these changes, in case of dissent, or
> usecases I have not fully understood.
>
> 1. Updated to use Dojo 0.4.1 -- brings lots of improvements, bug fixes
> and broader browser support.
Great!
>
> 2. Introduction of widget namespaces, allows lazy loading of widgets via
> lookup from a manifest.
Sounds interesting.
>
> 3. Dojo debugging is now turned on and off via an optional sitemap
> parameter.
Cool
>
> 4. The contents of the optional <fi:init/> tag is now inserted after the
> scripts to load dojo etc.
>
> 5. TODO: cocoon.forms.* to take over from forms_* in forms_lib.js.
This sounds like a good idea to me.
>
>
> Notes:
>
> The upgrade to Dojo 0.4.1 brings us many advantages, but may break some
> user's custom widgets due to changes in some of the APIs. The work
> required to adapt the existing forms and ajax widgets was pretty minor.
>
> The widgets that come with 0.4.1 are much improved. This will make it
> far easier to replace the legacy javascripts like htmlarea and the
> mattkruse-libs with their dojo equivalents, while supporting a wider
> range of browsers.
Hmm I'm still not sure if the Dojo rich text editor is capable of all
HTMLArea functionalities. Do your changes allow me to still configure my
own rich text editor for certain elements in my cforms page?
>
> The main rationale for these changes has been to reduce the amount of
> javascript that gets loaded by a CForms page. Currently everything
> possible gets loaded, regardless of whether it gets used or not.
I'm all +1 on that.
Reijn
Re: RFC: Changes to CForms in 2.1.11-dev
Posted by Carsten Ziegeler <cz...@apache.org>.
Jeremy Quinn wrote:
> I have not tested how cforms works without javascript for a long time
> TBH.
Me neither, but I know that there are several projects (trying to use)
using cforms without any javascript at all (for accessibility).
So as long as it doesn't get harder with your changes, I'm fine :)
> <snip/>
> Each of your forms must now have a unique ID attribute (one is added
> in XSLT for you if you did not add your own).
Great - I'm giving each form a unique id anyway :)
>
> Using this ID, I keep the list of submit handlers for each form
> separate and only call the handlers for the form being submitted.
Ok.
Thanks
Carsten
Re: RFC: Changes to CForms in 2.1.11-dev
Posted by Jeremy Quinn <je...@apache.org>.
On 28 Dec 2006, at 12:01, Jeremy Quinn wrote:
>
>> And does the new stuff better support multiple forms on one page. I
>> think there are some problems with the current onsubmit handlers when
>> there is more than one form.
>
> Yes, I had to change the API for adding submit handlers to allow
> for more than one form per page.
>
> Instead of this :
>
> forms_onsubmitHandlers.push(handler)
>
> You would have to do this :
>
> cocoon.forms.addOnSubmitHandler(formID, handler)
A quick correction, the new function is this :
cocoon.forms.addOnSubmitHandler = function(elt, handler)
Where 'elt' is the Element that is adding the handler.
cocoon.forms.addOnSubmitHandler = function(elt, handler) {
if (typeof(handler.forms_onsubmit) == "function") {
var form = this.getForm(elt);
if (form) {
var id = form.getAttribute("id");
if (id) {
if (!cocoon.forms.onSubmitHandlers[id])
cocoon.forms.onSubmitHandlers[id] = new Array();
cocoon.forms.onSubmitHandlers[id].push(handler);
} else {
if (dojo) dojo.debug("WARNING: SubmitHandler not
added. There is no id attribute on your form.");
}
}
}
}
regards Jeremy
Re: RFC: Changes to CForms in 2.1.11-dev
Posted by Jeremy Quinn <je...@apache.org>.
On 28 Dec 2006, at 07:38, Carsten Ziegeler wrote:
> Hi Jeremy,
>
> this sounds all great to me -
cool :)
> but I can't really judge the impact of
> your suggested changes.
not until I commit anyway ;)
> But I have two questions :)
> Is it still possible to use cforms without javascript after your
> changes?
I have not tested how cforms works without javascript for a long time
TBH.
I do not see how my changes would effect that situation however,
there is still a form with submit buttons, properly designed dojo
widgets should embellish an existing form field, so just give you
less functionality if the widget does not instantiate.
But, this is a very good point, I will do some testing here.
> And does the new stuff better support multiple forms on one page. I
> think there are some problems with the current onsubmit handlers when
> there is more than one form.
Yes, I had to change the API for adding submit handlers to allow for
more than one form per page.
Instead of this :
forms_onsubmitHandlers.push(handler)
You would have to do this :
cocoon.forms.addOnSubmitHandler(formID, handler)
Each of your forms must now have a unique ID attribute (one is added
in XSLT for you if you did not add your own).
Using this ID, I keep the list of submit handlers for each form
separate and only call the handlers for the form being submitted.
I was looking at ways of having the Form Widget keep it's own submit
handlers (avoiding the need for the ID parameter), but I am not sure
it would be reliable ...... you would not be able to easily guarantee
that the calls to add handlers were not made before the Form Widget
had instantiated. Whereas cocoon.forms.addOnSubmitHandler is static
so does not suffer that problem, it only needs to have been required.
I have not tested multi-form pages yet, I am sure there will be other
issues to deal with :)
Thanks for the feedback
regards Jeremy
>
> Jeremy Quinn wrote:
>> Hi All
>>
>> I hope you all had a good Christmas.
>> Santa's little helpers have been busy working on CForms over the
>> holiday break :)
>>
>> Below is a list of changes I have in my local repo, ready to commit.
>> I would like to get feedback on these changes, in case of dissent, or
>> usecases I have not fully understood.
>>
>> 1. Updated to use Dojo 0.4.1 -- brings lots of improvements, bug
>> fixes and broader browser support.
>>
>> 2. Introduction of widget namespaces, allows lazy loading of widgets
>> via lookup from a manifest.
>>
>> 3. Dojo debugging is now turned on and off via an optional sitemap
>> parameter.
>>
>> 4. The contents of the optional <fi:init/> tag is now inserted after
>> the scripts to load dojo etc.
>>
>> 5. TODO: cocoon.forms.* to take over from forms_* in forms_lib.js.
this is done now BTW.
<snip/>
>
> --
> Carsten Ziegeler - Chief Architect
> http://www.s-und-n.de
> http://www.osoco.org/weblogs/rael/
Re: RFC: Changes to CForms in 2.1.11-dev
Posted by Carsten Ziegeler <cz...@apache.org>.
Hi Jeremy,
this sounds all great to me - but I can't really judge the impact of
your suggested changes.
But I have two questions :)
Is it still possible to use cforms without javascript after your changes?
And does the new stuff better support multiple forms on one page. I
think there are some problems with the current onsubmit handlers when
there is more than one form.
Thanks
Carsten
Jeremy Quinn wrote:
> Hi All
>
> I hope you all had a good Christmas.
> Santa's little helpers have been busy working on CForms over the
> holiday break :)
>
> Below is a list of changes I have in my local repo, ready to commit.
> I would like to get feedback on these changes, in case of dissent, or
> usecases I have not fully understood.
>
> 1. Updated to use Dojo 0.4.1 -- brings lots of improvements, bug
> fixes and broader browser support.
>
> 2. Introduction of widget namespaces, allows lazy loading of widgets
> via lookup from a manifest.
>
> 3. Dojo debugging is now turned on and off via an optional sitemap
> parameter.
>
> 4. The contents of the optional <fi:init/> tag is now inserted after
> the scripts to load dojo etc.
>
> 5. TODO: cocoon.forms.* to take over from forms_* in forms_lib.js.
>
>
> Notes:
>
> The upgrade to Dojo 0.4.1 brings us many advantages, but may break
> some user's custom widgets due to changes in some of the APIs. The
> work required to adapt the existing forms and ajax widgets was pretty
> minor.
>
> The widgets that come with 0.4.1 are much improved. This will make it
> far easier to replace the legacy javascripts like htmlarea and the
> mattkruse-libs with their dojo equivalents, while supporting a wider
> range of browsers.
>
> The main rationale for these changes has been to reduce the amount of
> javascript that gets loaded by a CForms page. Currently everything
> possible gets loaded, regardless of whether it gets used or not.
>
> One of the big changes in 0.4.1 is the introduction of Widget
> Namespaces, with it's auto-load mechanism, using a manifest and
> namespace resolver to load the Widget's resources. This removes the
> need to dojo.require Widgets before they are used :
>
> Before :
> <script type="text/javascript">dojo.require
> ("cocoon.ajax.FormUploadProgress");</script>
> . . .
> <div dojoType="FormUploadProgress"><div>Upload Progress Sample</div></
> div>
>
> After :
> <div dojoType="ajax:FormUploadProgress"><div>Upload Progress Sample</
> div></div>
>
> NB. Unfortunately @class="namespace-WidgetName" is not currently
> supported by 0.4.1.
>
> The default namespace (does not need declaring) is 'dojo:'.
> I have introduced 2 new namespaces for Cocoon, 'forms:' is for
> widgets in cocoon.forms.* and 'ajax:' is for widgets in
> cocoon.ajax.*. There is a manifest file for each new namespace that
> registers the name of each Widget and provides a mapping between a
> widget name and it's module and path. i.e.
>
> cformsform --> cocoon.forms.CFormsForm which can be found in : ../
> forms/js/
>
> Unfortunately, because dojo.ns does it's resolution in lower case and
> we have CamelCase widget names, we need an actual map. New widgets
> must be registered there for auto-discovery to work.
>
> The manifest for the forms namespace looks like this :
>
> dojo.provide("cocoon.forms.manifest");
> (function(){
> var map = {
> html: {
> "cformsdraganddroprepeater" :
> "cocoon.forms.CFormsDragAndDropRepeater",
> "cformsform" : "cocoon.forms.CFormsForm",
> "cformsrepeater" : "cocoon.forms.CFormsRepeater",
> "cformssuggest" : "cocoon.forms.CFormsSuggest"
> // register new Widgets in the cocoon.forms namespace here
> }, svg: {
> // register svg widgets here
> }, vml: {
> // register vml widgets here
> }
> };
> function formsNamespaceResolver(name, domain){
> if(!domain){ domain="html"; }
> if(!map[domain]){ return null; }
> return map[domain][name];
> }
> // cocoon.forms module has a dependency on the cocoon.ajax module
> libraries
> dojo.registerModulePath("cocoon.ajax", "../ajax/js");
> dojo.registerModulePath("cocoon.forms", "../forms/js");
> dojo.registerNamespace("forms", "cocoon.forms",
> formsNamespaceResolver);
> })();
>
> The path is wide open for users to add their own auto-loading widget
> namespaces via their own manifests. Converting existing custom
> widgets to use a custom namespace is pretty trivial.
>
> The big plus we get from this switch, is that is will be far easier
> to write the CForms XSLT in a way that allows only used code to be
> loaded by the browser. When we have managed to replace all legacy
> widgets with dojo equivalents, the browser will only load code that
> is actually used.
>
> That pretty much covers points 1 and 2.
>
> The next issues regard points 3 and 4: debugging and the use of
> <fi:init/>.
>
> The <fi:init/> tag, introduced in 2.1.9, was being used to add
> <script/> tags into the html/head of pages *before* dojo was loaded.
> It was being used in a couple of samples for turning on dojo debug
> mode on the browser.
>
> Debugging can now be turned on from the sitemap :
>
> <map:transform src="resources/forms-samples-styling.xsl">
> <map:parameter name="resources-uri" value="{request:contextPath}/
> _cocoon/resources"/>
> <map:parameter name="dojo-debug" value="true"/>
> </map:transform>
>
> Leave the param out or set it to false, to turn off debugging.
>
> Debug messages now should go to the Browser's console (tested in
> Safari, FireFox ± FireBug) instead of being written into the end of
> the page. You can get navigable tree-views of your Objects even on
> browsers that do not support FireBug.
>
> The contents of <fi:init/> are now inserted *after* dojo is loaded,
> so may be used for custom initialisation code required for custom
> dojo widgets and other custom functions. eg.
>
> <fi:init><!-- load my custom non-widget library module -->
> <script type="text/javascript">
> dojo.registerModulePath("myns.stuff", "../path/to/my/
> stuff"); // relative to dojo.js
> dojo.require("myns.stuff.somelibrary");
> ... do something with the lib now, or later in the page ...
> </script>
> </fi:init>
>
> NB. dojo.registerModulePath is now used instead of the dojo.require
> hack we used to have in ajax/cocoon.js.
>
> I think this is far more useful but the change could possibly break
> some user's forms.
>
> Which leads us to point 5.
>
> We have a complicated mixture of legacy global forms_* functions (in
> forms_lib.js) and the cocoon.forms.* namespace.
>
> I would like to make the following changes :
> Deprecate forms_onloadHandlers, forms_onsubmitHandlers,
> forms_getForm, forms_submitForm and forms_onsubmit. (Leave an alias
> to those functions for now, but print a deprecation warning if they
> are called directly, remove after the next release). Move all of that
> functionality into cocoon.forms.*.
>
> Also forms should always use a CFormsForm Widget, regardless of
> whether Ajax behaviour is wanted or not. There would be two versions
> of the CFormsForm Widget, one SimpleForm (@ajax='false') which is
> extended by AjaxForm(@ajax='true'). CForms XSLT would choose the
> right one depending on form-template/@ajax. Since dojo is always
> loaded, this decision is inevitable imho.
>
> To get closer to allowing more than one form per page, the
> cocoon.forms library should manage onsubmit handlers for each
> CFormsForm Widget by storing them in a global hash instead of an
> Array, with the CFormsForm Widget id as the key (I'd have to change
> the API). The onload handlers can remain in a global Array.
>
> The trouble here is that this will have a far greater impact on
> existing user projects.
>
>
> So that's it, a lot of changes, some that may break user's projects
> (but AFAICS all of the samples are still working).
>
>
>
> Apart from general feedback, I'd like to ask for feedback on possible
> widget name changes.
>
> Firstly, are you happy with the names of the two new namespaces,
> 'forms:' and 'ajax:' they are named after the blocks that contain them.
>
> Secondly, I find stuff like @dojoType="forms:CFormsRepeater" a bit
> redundant now.
> To me, the forms block and cforms are synonymous.
>
> I would suggest removing the 'CForms' from the beginning of all of
> the forms widget names :
>
> @dojoType="forms:CFormsSuggest" --> @dojoType="forms:Suggest"
> @dojoType="forms:CFormsDragAndDropRepeater" -->
> @dojoType="forms:DragAndDropRepeater"
> etc.
>
> WDYT ? Or is this change for changes sake ?
>
>
> What's next ? Make dojo replacements for all legacy code (forms_lib,
> mattkruse, htmlarea etc.),
>
>
> Thanks for any feedback
>
> regards Jeremy
>
> PS. All the samples seem to be working :)
>
>
>
>
--
Carsten Ziegeler - Chief Architect
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/