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

Metzler, David metzlerd at evergreen.edu
Fri Oct 6 18:03:42 UTC 2006

>Isn't this the exact reason that FAPI supports extensible element types
via hook_elements()?  

Possibly, but I'm pointing out that there are different data types in
Drupal core.  These form elements don't have different element types,
because by default they don't behave differently.   That's one of the
reason that modules like TinyMCE have to encorperate all these features
to suppress their invocation in some forms.  Not every textarea in core
is meant for html data, so you have to get TincyMCE to turn itself off
whenever there is data in a form that it could mess up. 

Custom element types imply different behavior. We could expect module
developers to form alter every form in core, but that's a lot of work
for module developers to be expected to go to, when their trying to
extend existing functionality with form elements.  

I could see writing a form_alter hook that redefined all form element
types with a particualar #datatype attribute to another and then
implementing the new functionality in hook_element. Sounds like a recipe
for flexibilty.   

In short I guess I don't think of hook elements as solving the same

Ultimately I think some of us are asking for some discernable difference
between the "Sepecific Pages" textbox in Admin/Block and the "Footer
Message" in admin/settings general settings.  We want to turn tincymce
on for one, but off for the other in some systemic way that doesn't
require insane form_alter hooks, or other programming intesnive work

I do believe that this will pave the way for improved usability within
drupal core. 

More information about the development mailing list