#202: Support inline validation and editing for formlib forms

Contents
  1. Definitions
  2. Motivation
  3. Assumptions
  4. Proposal
  5. Implementation
  6. Deliverables
  7. Risks
  8. Progress log
  9. Participants
by Martin Aspeli last modified Mar 02, 2008 01:50 PM

We already have KSS support for inline validation of the edit forms of Archetypes edit forms. We should extend this to work on any formlib-based form - including add forms, edit forms and standalone forms.

Proposed by
Martin Aspeli
Proposal type
Architecture
Assigned to release
Repository branch
fschulze-optilude-usw
State
completed

Definitions

 

Motivation

To make formlib-based content add/edit forms and standalone forms a viable alternative to Archetypes-based forms, we should support the same features that we get from Archetypes. Inline validation and editing is one of those features.

Assumptions

 

Proposal

Define a convention for marking up forms as inline editable and/or inline validatable, and provide a standard set of KSS handlers to support this functionality. It should be on by default for the standard form types with bases in plone.app.form.

Implementation

This is largely complete in the fschulze-optilude-usw branch of plone.app.form. Note that it is not practical to use the exact same syntax as the Archetypes implementation, since this is tied up with the Archetypes widget system.

Inline editing

The example below is taken from the (temporary) testview.pt in the branch. It makes the fields "title" and "text" inline editable, using the fields in the the form called "edit_form"  available as a view on the context.

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"
      xmlns:tal="http://xml.zope.org/namespaces/tal"
      xmlns:metal="http://xml.zope.org/namespaces/metal"
      xmlns:i18n="http://xml.zope.org/namespaces/i18n"
      lang="en"
      metal:use-macro="here/main_template/macros/master"
      i18n:domain="plone">
<body>

<div metal:fill-slot="main" kssattr:formname="edit_form">
    <tal:main-macro metal:define-macro="main">

        <div tal:replace="structure provider:plone.abovecontenttitle" />
        
        <h1 id="title-display"
            kssattr:fieldname="title"
            class="documentFirstHeading formlibInlineEditable" 
            tal:content="context/Title" /> 
 
        <div kssattr:fieldname="description"
             kssattr:renderStructure="true"
             class="documentFirstHeading formlibInlineEditable" >
             
             I say!
             <span id="description-display" tal:content="context/Description" />
            
        </div>
 
        <div tal:replace="structure provider:plone.belowcontenttitle" />
        
        <div id="text-display"
            kssattr:fieldname="text"
            kssattr:structure="true"
            class="formlibInlineEditable" 
            tal:content="structure context/getText" /> 
    
        <div tal:replace="structure provider:plone.belowcontentbody" />

    </tal:main-macro>
</div>

</body>
</html>

This relies on various conventions:

  1. The CSS class formlibInlineEditable enables inline editing
  2. The KSS attribute fieldname specifies the field in the associated form
  3. The formlib form is referenced in a "global" KSS attribute formname, defined in an outer div
  4. By convention, the element with id ${fieldname}-display (e.g. "title-display" above) is used to show the updated value after the inline edit form is saved
  5. The KSS attribute "structure" can be  used to signal that the resulting value should be rendered unescaped

Inline validation

Inline validation requires no particular action for the form writer, so long as the standard Plone forms are used. In the branch, pageform.pt and subpageform.pt set the KSS attribute "formname", which is used by the inline editing KSS actions. It also applies the class formlibInlineValidation to each widget that is rendered, thus enabling inline validation.

 

Deliverables

 

Risks

 

Progress log

This work is largely complete, although it needs to be bundled up into a review bundle. There is also a problem with portlets and content rules, which are addressed by namespace traversal adapters. KSS seems to lose the context here, which means that the validation will not kick in. This may require a workaround.

Participants

Martin Aspeli, Balazs Ree

Framework team vote

Posted by Martijn Pieters at Dec 13, 2007 10:17 PM
+1

Framework team vote

Posted by Andreas Zeidler at Dec 13, 2007 11:01 PM

Framework team vote

Posted by Raphael Ritz at Dec 17, 2007 01:25 PM
+1

Framework team vote

Posted by Tom Lazar at Dec 20, 2007 01:04 PM
+1

Framework team vote

Posted by Danny Bloemendaal at Dec 22, 2007 05:38 PM
+1