implementing #format
Hey, In light of http://hojtsy.hu/blog/2008-feb-04/supporting-wysiwyg-editing-better-drupal-b... 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
Quoting Gábor Hojtsy <gabor@hojtsy.hu>:
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).
Excuse my ignorance in this part of the Drupal code but ... How about adding "${fieldtype}_format" functions to the theme engine that look for hooked "${formname}_${fieldname}_format" and/or "${formname}_{$fieldtype}_format" else apply a default format for that field type? Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
On Feb 19, 2008 2:12 PM, Earnie Boyd <earnie@users.sourceforge.net> wrote:
Quoting Gábor Hojtsy <gabor@hojtsy.hu>:
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).
Excuse my ignorance in this part of the Drupal code but ... How about adding "${fieldtype}_format" functions to the theme engine that look for hooked "${formname}_${fieldname}_format" and/or "${formname}_{$fieldtype}_format" else apply a default format for that field type?
Probably we don't see/understand each others thinking in its entirety. What we need is a Drupal core level knowledge of how fields and formats are tied together, so we can drop input formats when irrelevant, or attach WYSIWYG editors to then when needed. This will all be modifiable in the theme, but should not be a task of the theme or theme engine, since setting up these relations and limits on the admin interface will be global, certainly not theme dependent. Gabor
I'd like to implement direct input format support for Form API constructs.
#format as you've described would be a huge step forward. i can't imagine that there would any serious obstacles. i recall that chx worked on this in Montreal a couple of years ago when attempting to improve output filtering in general. i'm curious for his input.
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 ------------------------------------------------------
Konstantin, let me say up front that this is perfect feedback, very valuable! On Feb 19, 2008 4:06 PM, Konstantin Käfer <kkaefer@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)).
Yeah, I am also thinking about adding formats like "Plain text" (check_plain()) and possibly even "XSS filtered" (filter_[admin_]xss()), although I am for introducing format support for stuff like site settings as well somehow (eg. site mission, slogan, footer, instead of tying them to the filter_admin_xss() as they are now).
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.
I am also about to submit a patch to allow admins to limit certain input formats to certain "input types" (eg. story node body, comment body, ...). Look at http://groups.drupal.org/node/8911 for related discussions. There is valuable feedback there as well for this topic (although I started it for a different purpose :)
- 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.
You mean we should generate the HTML for the format selector / indicator and never have this in a FAPI structure more then the meta information? I did not think about this yet, but it sounds like a good idea to me :)
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.
I was rather thinking about #format being too generic and possibly misleading / conflicting for efforts to get email, number, etc. type fields, which would probably need a similar meta-mechanism for format limiting / specification. Anyway, if this comes significantly sooner, then the patch coming later needs to bother with this :P I am just trying to solicit some initial feedback, so that the keywords do not need to be modified later. Gabor
I was rather thinking about #format being too generic and possibly misleading / conflicting for efforts to get email, number, etc. type fields, which would probably need a similar meta-mechanism for format limiting / specification. Anyway, if this comes significantly sooner, then the patch coming later needs to bother with this :P I am just trying to solicit some initial feedback, so that the keywords do not need to be modified later.
Good point, '#format' would indeed be ambigious. '#filter_format', '#filter format', or '#filter-format' would be more appropriate, IMHO. If we tie input formats to form elements, we should also implement some logic to let filters know about which field is actually filtered, and, to which object the field belongs. Most filters suffer from not knowing anything about the context of the filtered content. That information is very valuable, for example to generate different output for different fields, or to access certain other values of a node object while filtering a field of it. Daniel
On Feb 19, 2008, at 16:06, Konstantin Käfer wrote:
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.
Yea, this would be great! Previous attempts to allow bold/italic text in the Title field has involved patching core or other dirty methods. On Feb 19, 2008, at 11:41, Gábor Hojtsy wrote:
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).
I'm all for including relevant information as metadata. That would make it much easier for WYSIWYG editors to determine whether they should attach to a certain field or not, and allow for more fine grained control of this from its admin pages. Joakim //ximo
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
Hi, 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 Gordon. Gábor Hojtsy wrote:
Hey,
In light of http://hojtsy.hu/blog/2008-feb-04/supporting-wysiwyg-editing-better-drupal-b... 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!
participants (8)
-
Daniel F. Kudwien -
Earnie Boyd -
Gordon Heydon -
Gábor Hojtsy -
Joakim Stai -
Konstantin Käfer -
Larry Garfield -
Moshe Weitzman