cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Quinn <jer...@apache.org>
Subject Re: RFC: Changes to CForms in 2.1.11-dev
Date Thu, 28 Dec 2006 12:33:39 GMT

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


Mime
View raw message