Re: implementing #format

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.dru
palcon.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 <kkaefergmail.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.drup
al.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