Re: ids now included in Formulator fields

Greetings -

The automatic formulator field html id's feature is now cleaned up, applied to 
all appropriate widgets, and checked in to the Formulator 1.12 branch and the 
trunk.  Formulator 1.12 will be used in Silva 2.2, and the Formulator trunk 
is now only compatible with Zope 2.12 (which Silva 2.2 will not initially 
support).

First, not all formulator fields have a title which directly correlate to a 
single input field.  Radio fields (which have multiple inputs) and checkbox 
groups are two fields that do not have a direct correlation.  I was unable to 
find any "best practice" online about what to do in this case -- should the 
field title be a label for the first input field in the group?  Should there 
not be a label around the field title?  I suppose in this case a better 
approach would be to use a fieldset.  

The widgets for all fields have a boolean property 'has_html_id' which can be 
inspected and used to omit the label.

There are two methods that can be used to retrieve the html id:

1) Field.generate_field_html_id:
          Generate the html id used to render the field in the form.
          The id is generated as follows:
           the `key` param is prefixed with the name of the form the field is 
           in and then sanitized to be an xml id addressable by css (i.e. 
           [._ :] converted to '-'
             
           Note that if a field's "extra" parameter has an ID attribute
           in it, the value of the ID attribute is used rather than the
           generated one described above.  This is for backward compatibility.
           
           The `key` param is useful for subfields (e.g. DateTime).  The 
           DateTimeWidget's render function needs to compute the subfield_key,
           and pass it into this function, since the subfield does not know
           what field it is a part of.
        
           Widgets can add this as the 'ID' attribute of rendered elements.

1) Field.html_id is a cached property that is the default return value of 
generate_field_html_id().  This is a faster way to get at the html_id from 
within page templates using path expressions.

Note that, for backwards compatibility purposes, if the field's "extra" 
parameter already specifies an html id attribute, the value of this is 
returned when calling generate_field_html_id (and html_id).

The Formulator Field edit screens now show the html id and the html name 
attributes at the top of the screen for easy reference.

regards,
Andy

On Friday 16 October 2009 04:13:32 am Kit BLAKE wrote:
> On 16 Oct 2009, at 03:45, Andy Altepeter wrote:
> > On Saturday 10 October 2009 10:04:39 am Kit BLAKE wrote:
> >> Seems the new version of Forumulator - which we're using in 2.2 - now
> >> adds ids to fields. This has created some conflict problems because
> >> we've added ids in the Formulator 'extra' fields. Everywhere. :(  But
> >> we think letting Formulator do it is the best behavior so we're
> >> planning on removing all the id=${here/id} and variants. You might
> >> check your own code.
> >
> > Everyone - sorry about that.  I added ids to many formulator fields
> > without
> > thinking about the possible repercussions.
>
> Aha, so that was you! No problem, it's better this way.
>
> > I have a few additional todo's
> > now regarding this:
> >
> > 1) sanitize the ids so they are valid html id's (and also valid CSS
> > selectors).  Mainly this means stripping out periods and colons from
> > field
> > ids.
>
> Please, replace with dashed, e.g. silva-content-shorttitle
>
> > 2) It would be nice to add to the Formulator ZMI screens a printout
> > of what
> > the html id of the field is.
>
> Perhaps both name and id:
> name="silva-content.shorttitle:record" id="silva-content-shorttitle"
>
> Kit