What should be in Fluid-all.js?

[Colin Clark]

Hey,

On 20-Jan-09, at 11:02 AM, Anastasia Cheetham wrote:
>> There are a couple of javascript files that we ship in our bundle  
>> that are not included in Fluid-all:
>>
>> InlineEditIntegrations.js
>
> Oops, maybe?
>
>> jquery.tinymce.js
>
> Possibly oops...

I suggested that we leave both of these out of the Infusion 0.7 build  
until we'd had this discussion. Given that they're still evolving, I  
think this is reasonable.

>> They can do that today but not if they want to use rich text inline  
>> edit. Fair enough since rich text inline edit is in sneak peak mode  
>> but what about going forward? It would be crazy to include all  
>> possible rich text editors but do we want to include one?
>
> This is a good question. I'm trying to remember the discussions we  
> had at the time we put together the rich-text inline edit. If I  
> recall, the *idea* was that we were delivering an Inline Edit that  
> could have a rich-text editor plugged in, but not delivering the  
> rich-text editors. That's why the file is called  
> InlineEditIntegrations instead of RichTextInlineEdit. But we do need  
> to figure out the correct path forward.

There are a few reasons why I'd suggest not including any of the rich  
text editors themselves in Fluid-all.js:

1. They're huge.
2. They have very different licenses
3. They're pretty hacky in terms of how they initialize themselves,   
and merging them into Fluid-all is likely to be error-prone

It seems to me that if InlineEditIntegrations.js and jquery.tinymce.js  
don't force any hard dependencies on FCK or Tiny, we're safe to  
include them in Fluid-all. This means that our users would simply have  
to link to their favourite rich text editor and Fluid-all.js into  
their page to get it all working.

Just taking a quick look at the code, it looks like the  
FluidInlineEditIntegrations.js does not force a hard dependency on  
either rich text editor. My jquery.tinymce plugin does, however. This  
would be a super-easy fix, but we should run a test to ensure my  
reading of the code is correct.

All of this will need to be refined again when we integrate Simon  
Wang's new modular build scripts into the process. I'd like that to be  
a feature of this next release.

>> In essence that's what we are doing with Uploader. We include swf  
>> but not Gears. Regardless of what we decide we really need to  
>> document this somewhere.

At this point, Uploader is a slightly different case. The Gears  
support isn't finished yet, so we don't ship it with the Uploader. But  
when it's done, I expect that both Gears and Flash support will ship  
out of the box. We'll even leverage our graceful degradation support  
to check for Gears, then fall back to Flash, then finally fall back to  
plain old HTML.

Colin

---
Colin Clark
Technical Lead, Fluid Project
Adaptive Technology Resource Centre, University of Toronto
http://fluidproject.org