Re: RFC: Changes to CForms in 2.1.11-dev
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
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/ smime.p7s Description: S/MIME cryptographic signature
Re: RFC: Changes to CForms in 2.1.11-dev
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 smime.p7s Description: S/MIME cryptographic signature
Re: RFC: Changes to CForms in 2.1.11-dev
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
smime.p7s
Description: S/MIME cryptographic signature
Re: RFC: Changes to CForms in 2.1.11-dev
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
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/javascriptdojo.require
(cocoon.ajax.FormUploadProgress);/script
. . .
div dojoType=FormUploadProgressdivUpload Progress Sample/div/
div
After :
div dojoType=ajax:FormUploadProgressdivUpload 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
