#53: Improve/speedup Plone editing

Contents

1. Motivation
2. Proposal
3. Implementation

Proposed by

batlogg

Proposal type

State

rejected

Motivation

We're thinking of a more flexible editing screen. for better understanding here is a usecase:

user wants to edit a folderish object with several references to other objects. in our use case the object is a plan of a historic building. the object contains (folderish) other objects like the front page (recto) and the backside of the sheet (verso). the object itself, recto and verso are referencing to multiple other objects (person that created the drawing, the museum where it is located, the owner of the drawing,...).

the user needs both: a kind of power_edit with automatic ordering of the fields. e.g. first all property fields, then all reference / relation fields of this type and finally all contained objects. but we need to support custom order too.

user has the possibility to edit the object itself. if we wants to follow a reference or edit a contained object, he simply opens it inside the original document.

Proposal

all modern browsers are able to do reliable runtime DOM modification via JavaScript. we'd like to use the new possibilities to improve and speedup the editing part of plone.

Two main things:

• avoid page reloads on validation errors, save of objects
• allow multiple object edits on one page

Implementation

decisions we need to take

Decision 1: multiple forms / single form?

• multiple forms for batch-editing

  advantages

  • no problems with duplicate <input name=""

  disadvantages

  • problem with nested forms
  • if we save all objects together, the savings are async
• single form for multiple objects:

  advantages

  • rollback possible (dependencies)
  • nested forms not neccessary. only single form required

  disadvantages

  • need intelligence for defining form names and ids. (edit_macros)

Decision 2: XMLRPC/no forms, or forms/iframes

• XMLRPC / no frames

  we could make all server communications via XML RPC. JavaScript could read the content of the forms and send it via XML RPC to the Server. the server responses the results (updated form data). JavaScript could replace the existing Forms with the new one.

  disadvantages

  • no way to upload files via XML RPC
• iframe

  with using a iframe, we could send the complete form into an iframe (including files). when the frame is loaded, we replace all of the widgets with the new one.

  advantages

  • possible to send binary data.

  disadvantages

  • iframe sucks ;-)
  • IE for win doas not allow to move a dom node from one iframe to another. maybe we need to serialize the dom node.

small mockup showing how dynamic loading can work

general conditions

• we do not want to touch the widgets
• should run on all important browsers (state of the art).