[development] implementing #format

Gordon Heydon gordon at heydon.com.au
Thu Feb 21 09:26:36 UTC 2008


I was thinking about this for D7. The main reasons is that it will make 
implementing WYSIWYG editors much easier as you will be able to see 
which textareas will be able to see exactly what is a text output and 
what is html output.

Get this done, it will make things much easier for WISIWYG editors

Gábor Hojtsy wrote:
> Hey,
> In light of http://hojtsy.hu/blog/2008-feb-04/supporting-wysiwyg-editing-better-drupal-battle-plan
> I'd like to implement direct input format support for Form API
> constructs. I have been thinking and researching on the following
> lately:
> 1. What form API element to support?
>  - Drupal core only uses input formats with textareas
>  - CCK also supports input formats with textfields
> Any other field one would need to support? Do we need to support
> textfields really?
> 2. How to add to the form structure?
>  - Core does wrap the field in a wrapper FAPI element and then add the
> textarea and the 'format' fieldset / radio group to that wrapper.
>  - CCK adds the field and adds the format fieldset / radio group with
> name: $field_name .'_format' (no specific wrapper).
> Core things like teasers and the splitter require that wrapper so that
> related fields are together. We should either enforce the wrapper
> (which could complicate life for #tree forms), or do not care about a
> wrapper existing or not, leave that off to the implementor.
> 3. How to make adding format selectors and acting on them easy?
>  - The different (free to modify) methods of adding input format
> support on fields makes it hard to act on it from form altering, etc.
>  - Devise a unified approach to add format (selection) support => add
> a #format (#input_format, something else?) key to FAPI
>  - Expand textareas with #format to a textarea and a format selector
> (or just help if there is only one format) with the help of #process
> This should provide a one and only standard way to tie formats to
> textareas, and form altering would have the important metadata
> available at a predictable place. (I'd also like to add more metadata
> about what type of field is actually presented for format selection,
> so we would be able to limit input formats available for blocks,
> nodes, comments, etc).
> Anything obvious I am missing or total misdirection I am taking?
> Better ideas or tips to get this done easier? Does someone see where
> I'll stop and freeze without a way forward (because certain APIs will
> not allow me to proceed without major refactoring)? :) If #format a
> good idea for input format specification on forms, or should I use a
> better name? (I would not like to get in conflict with #formatter and
> friends).
> Gabor
> !DSPAM:1000,47bab26b269181468016628!

More information about the development mailing list