[sakai2-tcc] Sakai 2.8 - CKEditor

[Noah Botimer]

The technique I've worked up is going to make it even easier. This will be written up in more of a document form, but here is the core concept.

The basis is:

 * A JavaScript file for the editor (swapped into head by ToolPortal or dynamically substituted by a servlet that knows how to redirect to the active one from a static URL)
 * A binding script specific to the active editor loaded
 * UI toolkit modifications to call this generic launch script rather than the native launch as they are now


For example, here is part of the patch to the velocity module:


 #macro (chef_setupformattedtextareaparams $textarea_id $height $width $ToolBarSetChoice)
+    #*
    ## setup wysiwyg editor
    #set($editor_path = "vm/editor/$!sakai_editor/sakai_body.vm")
    <!-- $editor_path -->
    #parse("$editor_path")
    <script type="text/javascript" defer="1">chef_setupformattedtextarea('$textarea_id','$height','$width','$ToolBarSetChoice');</script>
+    *#
+   <script type="text/javascript" defer="1">sakai.editor.launch('$textarea_id','$height','$width','$ToolBarSetChoice');</script>   
 #end

It switches from pulling some editor-specific velocity file for launching to calling a statically named JavaScript function that is already bound to the right editor.

Any code in any UI toolkit can use the pure JavaScript API or continue to use the tookit-specific utilities like the velocity macro, <sakai:inputRichText> for JSF tools, or any other. Also, I'm toying with the idea of allowing an automatic replacement by adding a specific class to textarea tags. That means that any toolkit that can render a textarea with a given class gets the "magical Sakai rich text editor" for free with no code or nasty details.

So, there's the preview. Stay tuned for more.

Thanks,
-Noah

On Sep 16, 2010, at 11:58 AM, David Horwitz wrote:

>  Ok Thanks for the clarity. Wrt to the RSF tools the editor is rendered 
> by an evelver - I presume this is where the rewrite would occur and the 
> option to use it or not would be in the tools spring config:
> 
> <!-- rich text evolver bean def -->
> <bean id="richTextEvolver" parent="sakaiFCKTextEvolver" />
> 
> 
> (Can't speak for the other UI technologies)
> 
> D
> 
> On 09/16/2010 05:43 PM, Noah Botimer wrote:
>> The tricky bit is that the API is different. Native FCKeditor plugins will need some level of rewrite.
>> 
>> This is a big reason that I'm calling for the editor to be available but not the default. Things like the entity picker, movie plugin, citations helper, Kaltura plugin, assignments 2, and probably others will need attention over time. I can't commit to finding and fixing everything.
>> 
>> The most important to me was the file browser, which is working for browsing, attaching, and uploading.
>> 
>> I also have some custom code that tweaks the editor at runtime for styles and implements some autosaving, which I ported pretty easily. But it was a port.
>> 
>> We may be able to provide a minimal adapter and write to that, but it's not clear to me how sensible that is past the most basic stuff like GetXHTML ->  getData, IsDirty ->  checkDirty and so on. I haven't studied the differences in the plugin models much yet.
>> 
>> Thanks,
>> -Noah
>> 
>> On Sep 16, 2010, at 12:04 AM, John Bush wrote:
>> 
>>> I'm really going to miss the fck editor, the name is so descriptive.
>>> 
>>> Any idea this might affect things like the kaltura integration or entitybrowser
>>> 
>>> Sent from my commodore 64
>>> 
>>> On Sep 15, 2010, at 8:58 PM, Noah Botimer<botimer at umich.edu>  wrote:
>>> 
>>>> Hello TCC,
>>>> 
>>>> I'd like to declare my intention/proposal to make CKEditor available for the Sakai 2.8 release.
>>>> 
>>>> I've been working to verify that the integration would work with the most important and expected components supported. The good news is that the general editing experience is pretty good (more accessible, much faster, paste form Word is better) and the file browser works.
>>>> 
>>>> There is certainly some work to do before the code freeze, namely some cleanups to how the editor is launched from the different UI technologies. I've been working up a mechanism to "push down" the editor selection and binding so there would be less ongoing maintenance of the UI toolkits. It works well, but needs to be cleaned up a bit.
>>>> 
>>>> My intent is that CKEditor 3.x be available in a sort of beta state for 2.8, leaving the default as FCKeditor 2.x. I would encourage that at least one QA server enable it and that we do some significant functional testing. There will be configuration settings that we want to adjust and bugs that we should fix. The user experience also has some changes that should be understood and documented plainly before changing the default editor.
>>>> 
>>>> I'm also of the mind that, once the initial testing passes, we should merge the new editor to 2.7.x and allow institutions the opportunity to test and switch earlier than 2.8 without custom patching, etc.
>>>> 
>>>> I plan to check the support into a branch (set) so we can do any appropriate technical review and share documentation of the techniques in play and how they could affect tools or UI toolkits of the future. Barring objections, these changes would be checked into the main lines (trunk) for each affected module.
>>>> 
>>>> Please let me know if there are concerns with this general approach.
>>>> 
>>>> Thanks,
>>>> -Noah
>>>> 
>>>> _______________________________________________
>>>> sakai2-tcc mailing list
>>>> sakai2-tcc at collab.sakaiproject.org
>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>>> 
>> _______________________________________________
>> sakai2-tcc mailing list
>> sakai2-tcc at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
> _______________________________________________
> sakai2-tcc mailing list
> sakai2-tcc at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
> 
>