Re: [development] Controlling whether WYSIWYG editors are viewed - Forms feature request.
There was a thread in the issue queue recently about adding a flag to textareas that the >module author could apply or not, which RTEs (TinyMCE, FCKeditor, etc.) could then hook >onto to decide where they should or should not be used.
This got me thinking that most of the time the problem with the WYSIWG editor being displayed all the time was that a lot of the time it screws up data that wasn't supposed to be HTML to start with. I've posted an alernative solution here that I've detailed in the following issue: http://drupal.org/node/87806 Basically it's to standardize how we tell the forms api and therefor contrib modules, what kind of data is supposed to be in the text area. Works for Rich Text editors, Color pickers, CSS editors, etc.
This was exactly my point when proposing a #html property in my previous email rather then a #wysiwyg property. Your #datatype property is even more generalised and thus better, but I share the view. Robrecht On 10/6/06, Metzler, David <metzlerd@evergreen.edu> wrote:
There was a thread in the issue queue recently about adding a flag to textareas that the >module author could apply or not, which RTEs (TinyMCE, FCKeditor, etc.) could then hook >onto to decide where they should or should not be used.
This got me thinking that most of the time the problem with the WYSIWG editor being displayed all the time was that a lot of the time it screws up data that wasn't supposed to be HTML to start with.
I've posted an alernative solution here that I've detailed in the following issue:
Basically it's to standardize how we tell the forms api and therefor contrib modules, what kind of data is supposed to be in the text area. Works for Rich Text editors, Color pickers, CSS editors, etc.
Isn't this the exact reason that FAPI supports extensible element types via hook_elements()? I don't think we need yet another flag. Instead, have a type of textarea (basic textarea, with or without the size grippie), a type of rte (which falls back to the same as textarea if nothing uses it, or else uses TinyMCE/FCKeditor/whatever), a type of "freelist" (or whatever name) for defining line-delimited lists of potential values, etc. Richer semantic information rather than a dozen extra flag parameters. form_alter() can still switch back and forth by just changing the #type property. This somewhat matches the direction CCK is going with field types like "email", whihc offer built-in validation. (I guess as long as we're discussing wishlist items for Drupal 6, I'll throw in that I'd love to have per-nodetype filter selection so that page nodes can have html but form nodes never can, no matter who the user is. I mean to write that one of these days... *sigh*) -- Larry Garfield On Fri, October 6, 2006 10:50 am, Robrecht Jacques said:
This was exactly my point when proposing a #html property in my previous email rather then a #wysiwyg property. Your #datatype property is even more generalised and thus better, but I share the view.
Robrecht
On 10/6/06, Metzler, David <metzlerd@evergreen.edu> wrote:
There was a thread in the issue queue recently about adding a flag to textareas that the >module author could apply or not, which RTEs (TinyMCE, FCKeditor, etc.) could then hook >onto to decide where they should or should not be used.
This got me thinking that most of the time the problem with the WYSIWG editor being displayed all the time was that a lot of the time it screws up data that wasn't supposed to be HTML to start with.
I've posted an alernative solution here that I've detailed in the following issue:
Basically it's to standardize how we tell the forms api and therefor contrib modules, what kind of data is supposed to be in the text area. Works for Rich Text editors, Color pickers, CSS editors, etc.
participants (3)
-
Larry Garfield -
Metzler, David -
Robrecht Jacques