Personal tools
You are here: Home Products Plone Roadmap #202: Support inline validation and editing for formlib forms
Document Actions

#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 March 2, 2008 - 13:50
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 December 13, 2007 - 22:17
+1

Framework team vote

Posted by Andreas Zeidler at December 13, 2007 - 23:01
+1 (see http://lists.plone.org/pipermail/framework-team/2007-December/001484.html)

Framework team vote

Posted by Raphael Ritz at December 17, 2007 - 13:25
+1

Framework team vote

Posted by Tom Lazar at December 20, 2007 - 13:04
+1

Framework team vote

Posted by Danny Bloemendaal at December 22, 2007 - 17:38
+1

For any issues with the web site functionality, please file a ticket.

Please consult the policy on plone.org content if you want your content published on this site.

Servers and hosting by