[development] implementing #format
larry at garfieldtech.com
Tue Feb 19 20:25:06 UTC 2008
On Tue, 19 Feb 2008 16:06:35 +0100, Konstantin Käfer <kkaefer at gmail.com> wrote:
>> 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
>> - 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.
More information about the development