I am just starting to familiarize myself with w-api's way of doing things and i like it's approach of piggy-backing on to input formats.
I get that the idea of w-api is to prevent developers from duplicating each feature in an editor specific module; but am wondering if it has got up to the existing modules as far as feature support.
Back in Dr5 days we required the need to assert specific Tiny "themes" to specific fields. Please keep in mind that a Tiny theme is NOT css but is a configuration definition for Tiny which includes more than just which plugins are enabled.
We started by adding a lot of template.php code to do this and then eventually migrated this to a module i called Tiny Fields. Tiny Fields did 2 things for us:
- gave field by field control of how Tiny appeared
- FCK Editor module (but sadly not W-API module) does this and i thnik the Better Formats module will do this with W-API due to how w-api ties in to formats.
and..
- allowed us to create custom Tiny themes to assign to fields (http://screencast.com/t/soEBuVisyq0)
From all of this, my questions are:
- does w-api now support the more fine grained detail of configuring an editor?
- is there a module that ties in with w-api that does this?
- is this a generic feature requirement for all/most editors such that if i was to design a module for this would i be able to do somewhat editor independent?
Comments
does w-api now support the
does w-api now support the more fine grained detail of configuring an editor?
No, not yet. This is something we intend to improve in Wysiwyg 3.x.
is there a module that ties in with w-api that does this?
Not that I know of, but modules and themes can override certain settings using drupal_add_js(.., 'settings'). Settings which require object/function references to be passed to the editor init call can not yet be controlled from the server as they can't be packed as JSON.
is this a generic feature requirement for all/most editors such that if i was to design a module for this would i be able to do somewhat editor independent?
We intend to keep the API editor independent so other modules do not have to worry about which exact editor is being used. Wysiwyg module has a plugin framework which allows for the creation of generic plugins. Each editor implementation should create a proxy plugin to wrap these 'Drupal plugins' so they look like a native plugin to the editor, or at least very similar.
Modules can also 'tell' a specific editor where to find the plugins it can handle natively as well as pass on additional or override existing editor options before the editor is initialized.