Hello, Just catching up on this thread.
We have been prepared on the testing end to have this change to FCKEditor come in. I think that if the normalization stuff is all fixed we should be able to commit this for Infusion 1.2. Thanks Justin On 2010-04-06, at 7:39 AM, Antranig Basman wrote: > Hi Colin, this looks awesome. I support that this should be committed to > trunk and FCKEditor removed from our SVN image as soon as possible. There is > a tiny bit of cruft at line 293 in that there is a fake declaration of > fluid.inlineEdit.CKEditor.editModeRenderer but otherwise the patch looks > great. > In terms of the HTML normalisation, this was always a bit "opportunistic" and > made just as good as it needed to be to handle the markup corruption > performed by the rich text editors we already supported. I will have a look > at it now to see if I can find a straightforward way of generalising it to > handle CKEditor as well... > > > On 06/04/2010 02:19, Colin Clark wrote: >> Hi all, >> >> I've added support for CKEditor 3.x to the Rich Text Inline Editor. The >> patch is attached to this ticket: >> >> http://issues.fluidproject.org/browse/FLUID-3604 >> >> One bug I'm encountering: even when a user doesn't make any changes to the >> text, our HTML normalization code doesn't seem to work quite right for >> CKEditor. As a result, the undo widget will always appear after saving, >> regardless of whether the text actually changed. This strikes me as a fairly >> minor, though annoying, issue. Thoughts? >> >> This patch also includes some refactoring of InlineEditIntegrations.js, >> hopefully for the better. There's still more we could do. In particular, we >> might want to separate out each Inline Edit flavour into a separate file to >> keep download times low. Opinions? Should we do this for Infusion 1.2, or >> wait for the next release? This is a user-facing change, so we may want to >> do it sooner rather than later. >> >> I also think there's an opportunity to define a more formal interface for >> rich text editors. There's now clearly a pattern for how we use each of >> them: create an editor, get the editor associated with an edit field, and >> get/set values on the editor. I have only peripherally addressed this with >> the new shared makeViewAccessor() function, but it's not particularly >> well-implemented yet. So, another question: refactor now, or wait for the >> next release? This is not user-facing, so it could wait. >> >> Assuming we like this new CKEditor support, I think we can deprecate support >> for the old FCKEditor. We can also switch to Yura's CDN version of CKEditor >> and boot the rather bulky FCKEditor source code from our repository. >> >> Colin >> >> >> On 2010-04-05, at 2:49 PM, Yura Zenevich wrote: >> >>> Last week I uploaded the latest version (3.2) of CKEditor to fluid project >>> team CDN that already hosts tiny-mce editor used in Inline Edit component. >>> >>> The editor files can be accessed at http://ckeditor-fluid.appspot.com/. The >>> hierarchy there is the same as the structure of the ckeditor source so you >>> can access the files similarly to this: >>> >>> http://ckeditor-fluid.appspot.com/ckeditor.js >>> http://ckeditor-fluid.appspot.com/adapters/jquery.js and so on. >>> >>> Regards, >>> >>> Yura >> --- >> Colin Clark >> Technical Lead, Fluid Project >> http://fluidproject.org >> > > _______________________________________________________ > fluid-work mailing list - [email protected] > To unsubscribe, change settings or access archives, > see http://fluidproject.org/mailman/listinfo/fluid-work _______________________________________________________ fluid-work mailing list - [email protected] To unsubscribe, change settings or access archives, see http://fluidproject.org/mailman/listinfo/fluid-work
