Hi Antonio, On 9 Dec 2005, at 17:17, Antonio Gallardo wrote:
Jeremy Quinn wrote:Hi AllI am working on refactoring our CForms Ajax code to use the Dojo Ajax Library. [1]The aim of this is to reduce the amount of cocoon-specific ajax code that needs maintaining by us, to a minimum, while simultaneously adding useful new functionality.The first thing I have done is to use the dojo.require mechanism to dynamically load all JS in the browser, so for instance, if your form does not use htmlarea, the javascripts are not loaded :)This goes for all of the cforms, ajax, mattkruse and htmlarea libs we currently use.This is not working in Safari ATM, so I cannot commit the changes yet unfortunately. I am pretty confidant that it is fixable. [2]So what is the next step? This is what I was thinking, I would appreciate your feedback. Refactor Cocoon JS ------------------forms-lib.js and cforms.js get merged into a new file that will contain all (non-ajax) CForms-specific code in the following namespace: cocoon.forms.cforms.Can we change the namespace from "cocoon.forms.cforms" to "cocoon.forms"?Any ajax-specific code from the files above and from cocoon- ajax.js go into a new file in the following namespace: cocoon.ajax.cforms. This is only loaded by your browser if you have Ajax enabled in your form.cocoon.ajax.cforms --> cocoon.ajax.forms3 levels are ok if we will have others "cocoon.ajax.????" namespaces, if not the case, then "cocoon.ajax" should be enough.Shorter names --> faster typing --> faster development. ;-)
Sorry, I cannot help you there :) The namespace works like this : [framework].[block].[file] [....]The namespaces are converted into URLs, we need to distinguish between Cocoon and Dojo and between Ajax and Forms Blocks.
FormsMultiValueEditor from forms-lib.js goes into it's own file in the namespace : cocoon.ajax.FormsMultiValueEditor. So that it may be loaded only when that widget is displayed.AFAIK, the FormsMultiValueEditor works in non-AJAX mode too. If this is true, then we should not store it under "cocoon.ajax"?
Yes, thanks for pointing that out.
Here is something interesting, JS allow us to create more complex widgets. The FormsMultiValueEditor is only one of this "complex" widgets. I believe in the future we can have more sofisticated widgets as a widget looking up data from a database and others. If this is really going to happens, then we can create a namespace for them:cocoon.ajax.widget cocoon.forms.widget Hence we can store the FormsMultiValueEditor under: cocoon.forms.widget.FormsMultiValueEditor WDYT?
Fine by me.
DOMUtils from cocoon-ajax.js either get incorporated into cocoon.ajax.cforms or gets loaded separately in cocoon.ajax.DOMUtils.+1 for cocoon.ajax.DOMUtilsSwitch to Dojo Libs ------------------- Re-implement our BrowserUpdater(s) using dojo.io.bind. [3]Re-implement our load and submit event handlers using dojo.event.connect. [4]Determine which existing CForms code/widgets etc. may be replaced by their dojo equivalent.Determine which existing CForms code/widgets etc. do not have a dojo equivalent and what to do about it.Determine what widgets there are in dojo, that are not in CForms but may be usefully added to CForms.Determine what widget functionality is available in dojo, but not in CForms that could be added to our widgets (drag and drop repeaters? upload progress bar ? etc.).+1! Thanks Jeremy for taking care of this. :-)
Thank /you/ for you useful feedback ;) regards Jeremy
smime.p7s
Description: S/MIME cryptographic signature
