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