Re: Ideas about in-place editing with datamanager

On Tue, January 3, 2006 11:10 am, Torben Nehmer wrote:
> Right now, the only AJAX interface I find intuitive is the search dropdown
> of Google.

...which is quite obviously the best "low hanging fruit" of using AJAX
with MidCOM. We've implemented it to some degree already with
contactchooser, but that still needs to be moved to Script.aculo.us to
provide support for key browsing the list, etc.

Anyway, such "choosers" are a great way to add performance, as in many
cases we now use dropdowns in places where there can be hundreds or
thousands of results. Those dropdowns will bog down page loads, where a
simple AJAX-powered search would be very fast:

  * User or group selections (we have several SGs with thousands of each)
  * Topic selections (like "Symlink topic" in taviewer config)

But still, AJAX should be an optional enhancement. Like with
contactchooser, the user can still utilize a select instead by editing the
DM schemas.

> (Besides missing, easily visible cues in the UI).

That is something we will still address.

> Also, what often confuses me is the fact that AJAX updates information
> without visual feedback (except perhaps dropping the form field again).

In OpenPsa we're now handling this by showing some status icons next to
the fields being saved:

* While save is in progress: a disk image (maybe a "hourglass" could be
better)
* If save succeeded: Green tickmark that slowly fades away
* If save failed: Red X, and a message to the OpenPsa message area (same
place and styling as used by PHP-generated messages)

> To sum up: I strongly suggest to use AJAX to *enrich* existing user
> interfaces, not *replace* them. Stuff like the BLOB (sub)types can be
> greatly improved by AJAX.

Fully agreed, but in-place editing can enhance the user experience in lots
of places. Case in point here would be n.s.photos where photo management
would be *much* faster and easier if you could edit photo titles and
rearrange photos on-site using AJAX.

> * The implementation proposal breaks DMs event handling (component no
> longer get notified of changes). This already makes any notion of "full
> transparency" impossible.

In MidCOM 2.5, shouldn't update notices be passed to the on_updating and
on_updated event handlers of the DBA class instead of the component
handler anyway?

If so, then as DM calls $object->update on the DBA objects, this will
happen anyway.

> * For a general note: Implementation is a bit on the hacky side; hacking
> an already hacky piece of code is dangerous. This is an old problem of the
> DM1, which is why I decided to deprecate it and started to work on DM2.

Agreed, but then again, see the reasoning why I first started doing this
for DM1. This is a new concept, and working on it on top of familiar code
base is simply easier.

> * Object locking is now no longer consistent. Either it has to be dropped,
> or a whole new way of locking objects should be introduced.

I think my spec says that when you start editing something, the lock will
be requested (and the edit declined if it can't be acquired).

I think the cycle here will be:

* Load object in DM -> dm::init()
  - Here we check if user should be allowed to edit at all (based on locks
    and ACL), and include the "in-place editing" JS library as needed, and
    register an onLoad event handler that will make the output of the DM
    instance editable if needed

* Load data for display -> dm::get_array()
  - Here we add the spans to all editable data fields

* Browser loads the page
  - onLoad event handler adds the "editable" visual cues to fields and
    adds the appropriate onClick and other listeners

* User clicks (or double clicks?) an editable field
  - We make AJAX POST request to the same page which is caught by dm::init()
  - dm::init() tries to acquire lock
  - If lock was acquired, it returns XML message containing HTML code of
    each widget needed for that object
    - The content fields are replaced by the form elements
  - If lock couldn't be acquired, we display a message and change the class
    of the fields from "editable" to "locked"

* User edits
  - We display hovering Save and Cancel buttons on the screen

* User clicks save
  - We submit all fields of the DM instance via AJAX POST, it is caught by
    dm::init()
  - dm::init() updates the appropriate fields of the _storage object
    and calls _storage::update()
  - We free the lock and return appropriate status message
  - The browser screen refreshes (or just pulls updated and processed
    content of the fields via AJAX?)

* User clicks cancel
  - We submit AJAX POST to dm::init() that clears the lock
  - We return from editable fields into the original content

> Torben Nehmer

/Henri

-- 
Henri Bergius
Consultant Partner, Nemein
henri.bergius-ZpG/[email protected]

Midgard CMS
www.midgard-project.org