[development] implementing #format

[Konstantin Käfer]

Hi,


> Any other field one would need to support? Do we need to support
> textfields really?

IIRC, textarea and textfield are the only input types in core which  
allow entering of freeform text. I'd absolutely go for supporting  
textfield input formats as well; I see a lot of use cases here, e.g.  
allowing specific HTML tags (Like <strong> or <em>) or parts of other  
input formats (e.g. **bold**) for node titles. I'd add an additional  
locked input format named "Plain text" which represents the current  
format (without any filtering // only check_plain (depending on the  
use case)).

Another issue with allowing filters for regular textfields is the vast  
space required by the current filter selector. I think we can minimize  
this by not displaying it for textfields when there is only one  
available input format. The input method can be specified in the  
textfield's description.


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

I don't particularly like such "wrapper" elements because they are not  
part of the semantics of the form. In fact, they are only a helper for  
associating the current input filter control with the body field. But  
when the filter is part of the textarea/textfield, this is no longer  
necessary.

> - 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

No. I see the input format selector as part of the textarea/textfield  
entity itself, not as a separate control.

> If #format a good idea for input format specification on forms, or  
> should I use a
> better name?

No, #format is perfectly fine. I don't think we should use less  
obvious names only because contrib modules for a previous version used  
them for a *slightly* different purpose or with a different syntax.


Konstantin Käfer -- http://kkaefer.com/


------------------------------------------------------
Don't miss DrupalCON Boston 2008 · March 3-6, 2008
Learn more at http://boston2008.drupalcon.org
Affordable sponsorship packages available
------------------------------------------------------


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2110 bytes
Desc: not available
Url : http://lists.drupal.org/pipermail/development/attachments/20080219/2520888c/attachment-0001.bin