How have I specifically hurt the simple use cases? Is there some
compromise we could make that would still give me a hook to have
multiple editors?
My code may be a little less elegant, but I don’t think it’s obtrusive.
The editor you didn’t see in my original submissions (but is in v5) is
the “content” editor. This is an editor with some features cut out
which is specifically setup for a “content” person to use. It’s only
supposed to show the partials that use can edit, and it hides things
like layout and page type. You can look at this editor in my v5
attachment.
I tried your suggested approach of having fck or tinyMCE load directly
into the current page structure. The problem with this is that it’s too
slow to use in practice. Both WYSIWYG editors take significant time
and bandwidth to load, and reloading them each time you tab between page
parts was unacceptably slow. Additionally, I couldn’t get tinyMCE to
work in Safari within the TabControl currently being used. It has to be
done the way I did it. (One WYSIWYG loads and the contents of the parts
are swapped in and out of it by the tabs)
The other reason for making facets support multiple editors is for
compatability. If there starts to be multiple extensions that alter the
page editor they can start to conflict. The easiest way to avoid
conflict is for each to define it’s own editor. I think it makes
writting extension a little more elegant too because you define all of
your page editor modification in your class which subclasses
DefaultEditor instead of having to define these changes in “activate”
Looking to the future, imagine very specific page types. A “calendar”
page type for instance. You don’t want to edit the calendar page with
the current editor, you want to edit it with a customized editor from
the calendar extension. And you don’t want all your page editors to be
calendar page editors. And your calendar editor should still re-use
components from the standard page editor, and still post to the
page_controller. This is the more “long term vision” problem I am
attempting to solve.
I’d like to further extend my work so that handle_new_or_edit_post in
PageController makes a call to some method of the editor_ui as a hook
for doing saving or whatever on whatever your editor has added to the
page. (In my case it’s page_attributes, and currently I’m just
overriding handle_new_or_edit_post)
In my latest version of facets, it’s possible to set
flash[:content_editor_ui]. If it is set, then it will use the editor
specified just for the current page edit. (And revert back to whatever
editor you have saved in your session for other pages)
I realize that:
Radiant::PageEditorUI.editors.default
isn’t as elegant as:
admin.page.edit_partials
I had envisioned doing something like:
admin.page_editors.default
This would be more consistend with the currently accepted admin.tabs.
method of adding tabs, But my ability to understand and debug
dependencies loading failed me.
What else are you objecting to?
Please suggest how I can improve my code to support multiple editors
without complicating the simple usecases.
On a side note,
I’ve found Radiant::ExtensionLoader::do_after_activate_extensions do end
to be usefull for more than just setting up multiple page editors. I’ve
found that getting dependencies to load in the proper order can be very
tricky, and this provides another hook for fiddling with the loading
order of things. (In my case, I had to load my extensions to
PageController in this block or I would get loading problems)