Issue 277 in dexterity: plone.app.textfield: support for collective.ckeditor

[dext...@googlecode.com]

Status: New
Owner: ----
Labels: Type-Defect Priority-Medium

New issue 277 by t_sch...@gmx.de: plone.app.textfield: support for
collective.ckeditor
http://code.google.com/p/dexterity/issues/detail?id=277

It seems plone.app.textfield currently doesn't support collective.ckeditor.

What steps will reproduce the problem?
1. add collective.ckeditor to your buildout
2. set CKEditor as default editor in either @@editing-controlpanel or
@@personal-preferences
2. create a dexterity content type with a richtext field, create and edit
an object of that type

What is the expected output?
CKEditor should show up as WYSIWYG editor for the richtext field

What do you see instead?
no WYSIWYG editor is showing up.

What version of the product are you using? On what operating system?
- plone.app.textfield from trunk or v 1.2.1
- collectice.ckeditor 3.6.7
(OS is Linux)

Please see attached patch for a fix that works for me - it let's you switch
between TinyMCE and CKEditor. Most of the relevant code is taken from
plone.app.form's widgets/wysiwygwidget.pt


Attachments:
collective.ckeditor-3.6.7.patch 1.7 KB

[dext...@googlecode.com]

Comment #1 on issue 277 by t_sch...@gmx.de: plone.app.textfield: support
for collective.ckeditor
http://code.google.com/p/dexterity/issues/detail?id=277

I can't find a way to to turn this issue into an enhancement rather than a
defect.

[dext...@googlecode.com]

Comment #2 on issue 277 by dgl...@gmail.com: plone.app.textfield: support
for collective.ckeditor
http://code.google.com/p/dexterity/issues/detail?id=277

Shouldn't collective.ckeditor's wysiwyg_support template declare these
variables itself if it needs them?

[dext...@googlecode.com]

Comment #3 on issue 277 by t_sch...@gmx.de: plone.app.textfield: support
for collective.ckeditor
http://code.google.com/p/dexterity/issues/detail?id=277

Hi,
collecktive.ckeditor doesn't have a wysiwyg_support.pt. It uses a browser
view named ckeditor_wysiwyg_support instead. The variables are needed here
to determine the correct editor depending on portal default and user
settings.
Best regards,
Thomas

[dext...@googlecode.com]

Comment #4 on issue 277 by dgl...@gmail.com: plone.app.textfield: support
for collective.ckeditor
http://code.google.com/p/dexterity/issues/detail?id=277

Sorry, ckeditor_wysiwyg_support is the one I meant. Is there a reason it
can't define the variables it needs for itself?

[dext...@googlecode.com]

Comment #5 on issue 277 by t_sch...@gmx.de: plone.app.textfield: support
for collective.ckeditor
http://code.google.com/p/dexterity/issues/detail?id=277

If you look at the patch, the new variables (member, isAnon, member_editor,
default_editor, editor, support_path, support) are all needed to determine
the correct template for the wysiwygEditorBox Macro. For ckeditor,
support_path will yield ckeditor_wysiwyg_support. For other editors, it
will e.g. yield wysiwyg_support. Also the line defining support_path will
determine wether to use a template from a skins folder or a browser view.
So these variables are not variables ckeditor_wysiwyg_support needs for
itself - they are defined in order to determine the correct view/template,
i.e. to determine the correct editor.

[dext...@googlecode.com]

Comment #6 on issue 277 by dgl...@gmail.com: plone.app.textfield: support
for collective.ckeditor
http://code.google.com/p/dexterity/issues/detail?id=277

My point is that these variables aren't needed by plone.app.textfield or
Products.TinyMCE, so widget_input.pt seems like the wrong place to add
them. No point in defining variables unless they are going to be used.
ckeditor_wysiwyg_support can add a block around its existing markup which
defines the variables.

However it could be argued that plone.app.textfield should do what it can
to support rich text widgets in the same way that they work with
Archetypes. If you turn this into a pull request on plone.app.textfield,
I'll probably merge it. But I'd rather see collective.ckeditor get fixed to
not expect things from the calling template that don't need to be there.

[dext...@googlecode.com]

Comment #7 on issue 277 by t_sch...@gmx.de: plone.app.textfield: support
for collective.ckeditor
http://code.google.com/p/dexterity/issues/detail?id=277

Hm... still not sure wether I've made my point. The question is: How does
widget_input.pt know it has to use the ckeditor_wysigwig_support browser
view instead of the wysiwyg_support template from skins?

That said, I admit that the suggested solution is not optimal. My patch
just fixes the problem in the same way it is fixed elsewhere. Templates
shouldn't have to take into account all the possible editors that exist.
But I'm not sure wether collective.ckeditor would be a better place to fix
things - maybe what is needed is a utility that can be queried for the
appropriate editor depending on the portal/user settings. But that would
require more work...

Anyway I'll turn the patch into a pull request.

[dext...@googlecode.com]

Comment #8 on issue 277 by t_sch...@gmx.de: plone.app.textfield: support
for collective.ckeditor
http://code.google.com/p/dexterity/issues/detail?id=277

Pull request is https://github.com/plone/plone.app.textfield/pull/3