CKEditor component released version 0.1

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 :)

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.

Dmitri Livotov: 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 :)

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...

David Wall:
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?

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": <div id="rootOfWidget"><div id="elementForCKEditorToReplace"></div></div>. 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

Matti Tahvonen: 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.

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.

Matti Tahvonen: I'd also suggest to use a "double div structure": <div id="rootOfWidget"><div id="elementForCKEditorToReplace"></div></div>. This way DOM structures generated by CKEditor stays inside the editor widget.

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.

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

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:

J2SE 5.0 reached its End of Service Life (EOSL) on November 3, 2009

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 :( ).

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)

Sascha Broich: 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.

Sascha Broich: 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.

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...

Just released the 0.8 version of the CKEditor component. I always forget to update the Directory's "release notes" before selecting the file to upload (maybe the upload button needs to be lower in the UI?), but here they are:

0.8 (4 November 2010)
- Using CKEditor 3.4.2.
- Recompiled with Vaadin 6.4.7.
- Added setting the root DIV element to be visible so that Firefox will show it on popup windows -- previously, it would only show the editor area
once in Firefox, and then it would disappear every time after in popup windows, yet would still work in panels off the main window.
- Added ability to set the body class CKEditor will use so it renders like how you may show the HTML on another page: config.setBodyClass(String bs)
This is particularly useful if you are using config.setContentsCss() to specify a CSS file that should be used in the editor and when rendered.
- Added ability to set the baseFloatZIndex: config.setBaseFloatZIndex(int zindex)
This can be useful if your editors are opened in popup windows. Found that the default (10000) wasn't enough and we're using 32000 for Open eSignForms.
- Added ability to set another option: config.setPasteFromWordNumberedHeadingToList(boolean) -- testing it out ourselves.
- Added ability to set the startupMode to "source": config.setStartupModeSource()

David Wall: 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...

Does anybody at Vaadin or in the forums have any thoughts on this?

Is it a bug for a modal windows to hold an input component that then attempts to open more windows since the idea of the first modal window is that it gets the focus and nobody else does?

Or should it be possible for a modal window to include such a widget? We have another user complaining about this, but I have no idea if there's a solution or not.

Thanks!

David Wall:

David Wall: 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...

Does anybody at Vaadin or in the forums have any thoughts on this?

Is it a bug for a modal windows to hold an input component that then attempts to open more windows since the idea of the first modal window is that it gets the focus and nobody else does?

Or should it be possible for a modal window to include such a widget? We have another user complaining about this, but I have no idea if there's a solution or not.

Opening a modal Vaadin window from a modal Vaadin window should work in theory, although there are some related issues (e.g. #6159, #5435).

Your issue might be related either to focus being in the wrong place (it should probably be on the top-most modal dialog) or perhaps to modality curtains blocking user actions (#6159).

Henri Sara: Your issue might be related either to focus being in the wrong place (it should probably be on the top-most modal dialog) or perhaps to modality curtains blocking user actions (#6159).

Is there a way I can determine this? Like where does the click/typing go?

I know that the modal windows in CKEditor work fine when the editor itself is in a regular Vaadin window, but fails in a modal window.

Maybe if I understood how "modal" is implemented in Vaadin windows it would be something we could figure out. Here's what little I have learned:

1) A Vaadin popup windows uses a z-index of 10000. It also creates a "v-window-modalitycurtain" div with the z-index at 10000.
2) The default z-index of ckeditor dialogs is 10000.
3) If I change ckeditor to use a z-index of 1000, it's dialogs will appear behind the vaadin window. The vaadin window remains usable and can accept additional clicks, but of course the ckeditor popup itself cannot be accessed.
4) If I leave it at the default of 10000, or up it 20000, it makes no difference. The ckeditor dialog appears on top either way, as expected, but that dialog won't accept clicks or data entry, yet it's clearly "alive" in that you can see mouseovers and cursor changes as you move around the dialog.
5) In FF, I see no NET activity when I try to click or deal with the ckeditor popup dialog, so nothing is going back to the server -- it's all in the browser.

I did note that CKEditor creates a "dialog background cover" div using the z-index value specified, and the dialog div itself is 10 more. So the dialog background cover that grays out the entire browser area is 10000, while the dialog div+table is set at 10010.

Is there CSS or something else that is used to control "focus" for the keyboard/mouse events? If the vaadin popup window's modal is turned off, it all works as expected. Is there a way to determine what is getting the key/mouse events?

Here's a

http://youtu.be/H4IlLpFI2ac

Okay, noted a few new things that may help someone understand what is going wrong:

On IE9, I can still right click in a field and PASTE data into the fields, just can't type or click. FF5 doesn't seem to allow this.

Using CSS, I was able to convert the A and INPUT tags to have a z-index of 40000, but that made no difference.

Lastly, in FF5 with Firebug, I noted that even Firebug cannot select a field by clicking on it. It's as if the entire browser refuses to allow the click in that area, but I Firebug can still select other elements in the window below. To navigate to the input fields in Firebug, I have to basically open the DOM tree to zero down to the actual INPUT element rather than just click on it using the element inspector.

Here's the solution:

Problem: when a window is displayed in modal mode, it capture all events and only allow those belongs to the active window.

Fix:

1. Override the VWindow as below:

/**
 * <p>
 * A placement of VWindow implementation to fix issue with CKEditor component in a modal window.
 * </p>
 * 
 * @see http://code.google.com/p/vaadin-ckeditor/issues/detail?id=10
 * @see https://vaadin.com/forum/-/message_boards/view_message/238571
 * 
 * @since 1.2
 * @author ttran
 **/
public class GWindow extends VWindow
{
    private boolean modal;

    /**
     * {@inheritDoc}
     * 
     * @see VWindow#updateFromUIDL(UIDL, ApplicationConnection)
     */
    @Override
    public void updateFromUIDL(final UIDL uidl, final ApplicationConnection client)
    {
        if (uidl.hasAttribute("modal")) //$NON-NLS-1$
            modal = uidl.getBooleanAttribute("modal"); //$NON-NLS-1$
        super.updateFromUIDL(uidl, client);
    }

    /**
     * {@inheritDoc}
     * 
     * @see VWindow#onEventPreview(Event)
     */
    @Override
    public boolean onEventPreview(final Event event)
    {
        if (modal)
            return true; // why would they block click to other elements?
        return super.onEventPreview(event);
    }
}

2. Setup your own widgetset and have this somewhere in the module.xml:

<replace-with class="com.genix.platform3.commons.widgets.gwt.client.ui.GWindow">
		<when-type-is class="com.vaadin.terminal.gwt.client.ui.VWindow"/>
	</replace-with>

Voila, it works.

So if anyone can explain the rationale behind the blocking events outside modal windows, I would like to hear.

Cheers,
Tien

Thanks. We'll give this a try. Great job digging into it...

Does your solution imply that VWindow has a bug in not handling this correctly and that we should report this to Vaadin for a fix?

Released 1.6.4 with this patch as it does seem to do the trick. Thanks Tien!

I wouldn't call it a bug but rather an annoying intended design. Hope that this was not aware at the time and they will incorporate the improvement :bashful:

The ticket 9001 has been created by the way.

TT

Tien,

Have you played with Vaadin 7 yet? We are doing a quick & dirty port of CKEditor for Vaadin now (based on the 1.8.2 version) to support Vaadin 7 and we have it seemingly working except for that modal issue. I'm not sure how to get your modal fix to VWindow to work in this new scheme since there's no updateFromUIDL method in the new VWindow (which has also moved packages).

If you have any ideas, I'd like to incorporate this fix again. Otherwise I'll release a version for Vaadin 7 that just suffers the modal bug again so at least some people can begin playing with it (we don't use editors in modal windows anyway, so it's not a problem for us personally).

I updated ticket 9001 with these details:
In porting the CKEditor for Vaadin component, in which a fix was supplied by Tien, to Vaadin 7, we essentially removed the modal window fix and noted that the issue arises again. So it appears that this modal issue remains in Vaadin 7.0.5.

With Vaadin 6, this code fixed the modal bug issue:

public class ModalFixVWindow extends VWindow {

	private boolean modal;
	
    @Override
    public void updateFromUIDL(final UIDL uidl, final ApplicationConnection client)
    {
        if (uidl.hasAttribute("modal")) //$NON-NLS-1$
            modal = uidl.getBooleanAttribute("modal"); //$NON-NLS-1$
        super.updateFromUIDL(uidl, client);
    }

    @Override
    public boolean onEventPreview(final Event event)
    {
        if (modal)
            return true; // why would they block click to other elements?
        return super.onEventPreview(event);
    }
}

Then in the gwt.xml file added:

<replace-with class="org.vaadin.openesignforms.ckeditor.widgetset.client.ui.ModalFixVWindow">
        <when-type-is class="com.vaadin.terminal.gwt.client.ui.VWindow"/>
    </replace-with>

But we are not sure how to make this work with Vaadin 7 because VWindow has moved packaqe names and no longer has the updateFromUIDL (presumably moved to a Connector?). We tried just this hoping that the VWindow.isModal() would suffice, but it does not seem to work:

public class ModalFixVWindow extends VWindow {

    @Override
    public boolean onEventPreview(final Event event)
    {
        if (isModal())
            return true; // why would they block click to other elements?
        return super.onEventPreview(event);
    }
}

and using this update gwt.xml:

<replace-with class="org.vaadin.openesignforms.ckeditor.widgetset.client.ui.ModalFixVWindow">
        <when-type-is class="com.vaadin.client.ui.VWindow"/>
    </replace-with>