What should be in Fluid-all.js?
colin.clark at utoronto.ca
Tue Jan 20 16:35:54 UTC 2009
On 20-Jan-09, at 11:02 AM, Anastasia Cheetham wrote:
>> that are not included in Fluid-all:
> Oops, maybe?
> 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.
Technical Lead, Fluid Project
Adaptive Technology Resource Centre, University of Toronto
More information about the fluid-work