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
