[development] Controlling whether WYSIWYG editors are viewed - Forms feature request.

[Larry Garfield]

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