CKEditor component released version 0.1

(Reposted under UI Components)

Thanks to Matti Tahvonen for suggesting his TinyMCEEditor code in incubator to jump start the CKEditor integration. I’ve done just that, though confess it was all new to me, so there could be far nicer ways to do this than the approach taken.

Thanks also to Joonas for suggesting that the code be stored at Google, so you can access the code at http://code.google.com/p/vaadin-ckeditor/ While the Vaadin Directory is still under construction, I’ve also put an entry in there.

I’m only now going to go beyond testing with a trivial sample app, so perhaps new capabilities will arise from that work.

Released an update that supports a Save button in the CKEditor toolbar that will send the contents to the server ‘immediate’. Sorry for the ugly button, but I’m no graphics person.

Also, have a hack/patch to fix the blur timing issue that was most notable on IE8, but could be found on any browser. CKEditor’s blur handler introduces a 100ms delay to fix “blur and focus effects” (don’t know what they are, so may have re-introduced those!), so this hack/patch basically replaces the blur function with the forceBlur function (both of CKEditor’s focusmanager.js code) that blur normally calls after the 100ms delay. This seems to fix the problem with the button’s onclick sometimes firing before the editor’s contents are queued up to the server on the blur event.

This also updates to CKEditor 3.2 from 3.1.

It’s still built on Vaadin 6.3 nightly with JDK 1.6. This is updated in the vaadin directory and the
http://code.google.com/p/vaadin-ckeditor/
project.

Great work, thanks for sharing!

Great work, David, thanks ! I think such powerful html editor is an important component for the entire framework.

By the way, did you think on implementing support (or api) to allow client-side to browse and select images and other resources form the server (and upload new resources to the server) via the vaadin application ? This could be an excellent final touch to the component :slight_smile:

Im personally not a deep UI/JS guy to join the client/ck integration side, but I may and wish to help with the supporting server-side for this, just let me know.

Neither am I a UI/JS person, which is why it was some experience building this.:wacko:

Yes, I do plan on having such an image upload feature at some point, but there’s no specific timeframe because we’re just now integrating CKEditor into our new vaadin app. I’ve not investigated the Vaadin file upload capability, but figure it somehow needs to be similar for uploading images (and maybe is all that’s needed), and perhaps using resources or whatever it is that Vaadin uses for retrieving images. The API clearly needs to be general since the actual datastore used will vary. In our case, images are likely stored as blobs in the database, though we may consider using a filesystem. The advantage of the DB is that a DB backup will contain everything, and DB replication will automatically copy the images too, and of course we get transactional control to know that an image insert/delete was committed with other DB operations that likely reference them.

It seems that CKEditor has a built in UI for browsing images (not sure about uploading), so that’s where the main integration point would be for the server code.

Eventually, we want to allow user-defined styles as well, but again, these are to be built as we need them.

So if you need it now and build something, let me know and we’ll be happy to incorporate it. Your help would be appreciated. Unfortunately, our project that uses CKEditor has not moved along as fast as originally planned because of a lack of resources – most still spending the majority of their time with our current products/customers.

Yep, I did see the ckeditor’s built-in image browser, it seems it is oriented to some server-side php scripts. But since ckeditor is ported to Vaadin - could we use Vaadin panels/popups and build a custom browser, based on Vaadin controls ?

I’ll think on the api/prototype and try to make a try when I’ll had a free time this week. I think, at least api/upload should not be a big deal, so we’ll see.

Yeah, I’m not sure what it all means since I’ve not looked into the details yet.

It looks like the API is really to just an URL to launch a browser window, so that window could certainly be a Vaadin window perhaps using the scheme of attaching the Window to the Application so it’s an external browser window with a separate URL (not sure if internal windows have separate URLs or not). It passes along some params for the editor id, etc. that is used to tie back the responses.

No doubt it will get hairy figuring out how to integrate those URLs to Vaadin, how to take the responses from the browser (which image was selected) so we can update the editor to store the image’s URL, alt-text, width/height, etc.

Have fun! Wish you good luck in figuring it out since it will be a nice capability and avoid the need for CKFinder (a commercial product that doesn’t even appear to support Java), though what it all means to generate thumbnails and such for the browser is not clear to me (maybe there’s already image thumbnail stuff in the contrib/incubator? haven’t checked). I suppose phase one wouldn’t need thumbnails if you could at least select from a list of files (URLs) that represent images available.

Don’t know the internals of ckEditor, does it allow to delegate a click to “insert image” button to some custom JS ? It seems, we’ll need to intercept this and open either Vaadin popup or window. And also return the selected image url somehow back…

I think I’ll start with the image manager server-side api and implementation, so we’ll get a working Vaadin window and all image management/selection stuff inside as well as sample simple api for folder-based image storage. Then, once it working, will try to figure out how to pair this with the ckEditor port.

The 0.4.1 release has been released into the
Directory
, demo app and the code is checked in. This resolves all known issues with the basic editor. We still have not progressed to using this in any detail in our project, so hopefully when that occurs, we’ll tackle extra features like image uploads, styles, etc.

The IE8 bug was resolved by not using CssLayout in the main window. A VerticalLayout did not exhibit the bug.

Updated in the directory and google projects, CKEditor for Vaadin has been updated to v0.5 with the following improvements:

0.5 (23 July 2010)

  • Recompiled with Vaadin 6.4.1
  • CKEditorTextField now extends AbstractField instead of TextField.
  • Added LI tag to list of compact tags.
  • Support setReadOnly(boolean) (default false). If the editor exists when you setReadOnly(true), the editor instance is destroyed.
  • Editor is now configured with a new CKEditorConfig class that can help build the configuration, or you can still just use JSON notation.
  • Ability to add other plugins by name: CKEditorConfig.addToExtraPlugins(String pluginName)
  • Ability to add the ‘vaadinsave’ plugin: CKEditorConfig.enableVaadinSavePlugin()
  • Ability to remove other plugins by name: CKEditorConfig.addToRemovePlugins(String pluginName)
  • Turn off (default on) HTML nesting levels (elementspath) shown at bottom if desired: CKEditorConfig.disableElementsPath()
  • Turn off (default on) resizing editor capability if desired: CKEditorConfig.disableResizeEditor()
  • Turn off (default on) the spell checker (scayt) if desired: CKEditorConfig.disableSpellChecker()
  • Using JSON notation, build a custom toolbar line-by-line: CKEditorConfig.addCustomToolbarLine(String toolbarLineJS)
  • Build the Open eSignForms standard custom toolbar: CKEditorConfig.addOpenESignFormsCustomToolbar()
  • Set whether the toolbar (default can) can be collapsed or not: CKEditorConfig.setToolbarCanCollapse(boolean v)
  • Set resize editor ability to vertical, horizontal or both (default): CKEditorConfig.setResizeDir(RESIZE_DIR dir)
  • Set editor width: CKEditorConfig.setWidth(String cssSizeFormat)
  • Set editor height: CKEditorConfig.setHeight(String cssSizeFormat)

===================

One issue I’d like to resolve is a way to allow the editor to be set with setSizeFull() so that it expands and contracts (within the limitations of CKEditor itself) based on the space available to it. Any good pointers on where to look for examples to detect when resizes take place and then attempt to resize the editor as well?

For example, I found that in a simple VerticalLayout on the main window, I can set the width to 100% and it works. But in a VerticalLayout in a Form in a popup Window, it doesn’t expand the width.

Any pointers to other components that handle resizing of their contained components is appreciated…

Hi,

Vaadin client side calls widgets setWidth/Height methods, so you should do required adjustment there. Also note that Vaadin expects the offset size (including paddings and borders) to become what it calls in those methods. You might need to call some CKEditor API from those methods if the editor is already initialized.

I’d also suggest to use a “double div structure”:

. This way DOM structures generated by CKEditor stays inside the editor widget.

BTW. Is it possible to compile the addon with Java 5? Some ancient Vaadin projects still use Java5.

cheers,
matti

The setWidth() seems to work fine now when it’s a percentage, but is there any trick to getting setHeight() to work as a percentage? A way to make the editor fill all of the space on the Form besides the buttons (footer)?

It does seem odd in some regards since no real height is specified other than the browser window its in.

We’ve switched to CKEditor’s appendTo method instead of replace, so it puts the editor inside our DIV. This resolved the width not being set correctly, and also got rid of the odd shift we’d see when our hack was to make our DIV hidden, so at least the code is looking more normal now, and so the double DIV shouldn’t be needed.

I’ll look into this, but we’ve not used Java 5 for years and so there’s no interest on our end for it, though I understand that Vaadin widget policy is to use it. What’s the hold up in migrating to Java 6 when Vaadin/GWT 2 etc are such new technologies?

Of course, the source is open so it can be recompiled as desired. We can look to download Java 5 and install as an Eclipse JRE for this subproject. Maybe we can do our next release since we do have new code now that resolves those other issues with the DIV and while not much functionality wise has changed.

From the
Java site for JDK 5
:

More reason to move forward than having everyone else move backwards…

Since I’ve not done it before, can I just use the Eclipse project-specific setting for Java Compiler and set the compliance level to 1.5? It appears that it will let me do this even though I only have Java 6 installed. It says we can generate .class files for 1.5. Will this work, or will I have to also install Java 5? That is, can Java 6 compile Java 5 compatible files?

With the 0.6 release, the code seems somewhat usable, so we’ve bumped it from Experimental to BETA, though we expect to do much more work on it as we continue to integrate it into Open eSignForms, mostly having to do with styles.

Note that it’s still compiled with Java 6. We tried Java 5, but it produced compiler errors which mean doing some code rework that we may consider in the future, but it’s very low priority to worry about a new widget having to support an obsolete JVM (sorry Vaadin Widget standards :frowning: ).

Not sure why pasting this into the Directory’s “release notes” results in it never keeping any of it, so here some details:

0.6 (26 July 2010)

  • Use CKEDITOR.appendTo instead of CKEDITOR.replace to create the edit instance. This resolved the bugs associated with the editor moving down
    and button clicks, as well as allowing the component to fill the space of the DIV from Vaadin’s perspective. Simplified the code as we no longer
    had to worry about that the DIV we created versus the DIV created for the editor as we switched between readonly and normal modes. Now the editor
    places itself inside the DIV we created so we have more natural control over it.
  • Added ability to set the config contentsCss with either a single file name or an array file files: setContentCss(String file) or setContentCss(String files)
  • Added ability to enable/disable the native spell checker feature: setDisableNativeSpellChecker(boolean)
  • Added support to CKEditor for editor.execCommand(String cmd)

Released version 0.7 of the CKEditor for Vaadin component which is in the Directory.

0.7 (20 October 2010)

  • Using CKEditor 3.4.1.
  • Recompiled with Vaadin 6.4.6.
  • Add ability to configure an external styles definition for the Styles combobox: config.setStylesCombo_stylesSet(String styleSetSpec)
  • Added editor destroy code when the widget is unloaded to hopefully avoid leaks.
  • Root DIV for the editor includes overflow:auto so it will show scrollbars if needed (such as in read-only mode when the editor is not present with its scrollbars).
  • Added method CKEditorConfig.enableTableResizePlugin() to add the optional ‘tableresize’ plugin since it seems to be generally useful.
  • Added method CKEDitorConfig.setupForOpenESignForms(String contextPath) to set up the editor in a common way for the Open eSignForms project and removed the other project-specific API: addOpenESignFormsCustomToolbar().

The CKEditor has a problem when in modal Vaadin windows.
The popup dialogs don’t react to mouseclicks.
Even if I configure the editor with

config.baseFloatZIndex = 15000; the mouse clicks are ignored.
This is sad, because otherwise the CKEditor is a nice tool.

Hmm… I’ve never used modal windows to house an HTML editor – maybe for a simple OK/Cancel dialog – but otherwise never. I have had other issues with CKEditor and popup windows, so it’s not too surprising.

I am not even sure how a modal windows should behave since the general idea is that you can’t work with other windows until you close it. What does it mean for a modal window to contain a full-fledged HTML editor that will use its own modal popup windows for such dialogs?

Team Vaadin, what might cause this problem? While dropdown lists seem to work in CKEditor, something like the Find dialog box in the editor will open a popup window (itself modal), but you can’t do anything with it (or even return back to the Vaadin modal window).

It seems that popup windows present their own challenges since I don’t see this when I open CKEditor in a Form in a Tab panel in a split panel in a main window. Nor when I open it in a new browser window. But when it’s opened in a popup window, we have some problems.

I confirm the problem exists

Can anyone at Vaadin or elsewhere help with understanding this problem? Is there a solution?

The problem is that a modal window is created that contains the editor, which itself has modal dialog boxes.

Should modal dialog boxes work correctly in a modal window? Right now, the second modal dialog box will appear, but no data entry is allowed, perhaps because the underlying modal window is trying to capture everything.

I have no idea how modal is implemented with popup windows (DIV elements) to restrict input focus, but is this something we can fix, something wrong with Vaadin or something that’s just not possible to expect a modal window to give control to other modal windows. In non-web world, this would be allowed as the top most modal window would hold the focus.

Thanks for any tips to help…