[development] implementing #format

[Larry Garfield]

On Tue, 19 Feb 2008 16:06:35 +0100, Konstantin Käfer <kkaefer at gmail.com> wrote:
> 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

Big +1 on the concept here.  Filterable text is part of the essence of the textarea/textfield just as much as its max length.  Probably more. :-)

I would suggest something like the following, to parallel other FAPI keys:

$formats = array(1, 4, 5);

$form['mytext'] = array(
  '#type' => 'textarea',
  '#input_formats' = $formats,
  '#default_format' => 4
  ...
);

Alternatively, $formats could be an associative array.

$formats = array(
  1 => $format_description_text_here,
  4 => $format_description_text_here,
  5 => $format_description_text_here,
);

That way, it's easier to form_alter and even change the help text on if some client complaints about the default text. :-)  The actual display of the filterable content is then controlled via a FAPI theme function.

Perhaps we should also, then, look at using the #access property of the element to control access to it rather than making the entire page uneditable and not form_alter-able?  (The #access property seems, to me, to be the "right" way to control access to a form field rather than conditionally adding it, because the latter can't be form_altered to enable access again.)  That would have the side effect of only making the one field inaccessible instead of the entire node form, which I'd consider a good thing.

--Larry Garfield