jump to navigation

Making editing in eZ publish more user friendly and effective December 29, 2005

Posted by Paul Borgermans in Ajax, eZ publish, User interface.

Not only the creation of “internal drafts” bothers me when you have collaborative solutions built on eZ publish, also the ability to quickly change some attributes on one or more objects is more than desirable. Ajax may be part of the solution, provided some security can be implemented. This post essentially outlines an extension architecture to do the job.

The problems

  • The editing workflow for small changes is too time consuming
  • For some applications (think of an issue tracking system), quickly edit some attributes of multiple objects is even more time consuming
  • The creation of stale “internal drafts” leaves the status of an object confusing for other editors (and even the original owner)

Solution scenarios

Best way to proceed is to write an extension which contains new template functions and a module to handle Ajax requests from the client with a fallback to “hit the server with a page reload”.

  • Editing with Ajax – the user side

A nice example of what I would like to see happening one day is over here. Ok, it is very basic but shows the point. For robustness towards client-side accidental typing, an edit enable/disable button is desirable. And an explicit save button too 🙂

  • Security

Ajax calls to the server may be intercepted and measures against XSS should be taken.

  • Avoiding stale drafts, yet prevent “corruption” or unexpected double editing

The system should keep track of what is happening, but something more leightweight should be implemented server side.

Implementation ideas

  • A unique token should be generated server side and stored as a cookie upon entering an editable page (or when the “enable edit” button is clicked). A copy of this token is kept in the server database. This token should be deleted upon succesful saving of the content server-side and should provide the following details
    • a timestamp
    • the current userid
    • the current objectid and nodeid
    • the current published object version
    • the current object class id
    • current site-access
  • Ini settings determine the behaviour when a second request to edit content is made:
    • the current behaviour may be maintained (user gets a warning that someone else is already editing the page — yes I mean page, see further on multiple object editing)
    • if the edit token is there, but content has not yet been updated, a small warning is given, but the second user may continue (competition of who saves first). When the original user hits the save button, he/she gets a warning and an updated page is presented, possibly highlighting what has changed with respect to his/her intention to change.
  • Keeping the current url friendly views, which means embedding a form-like structure in view templates, with DHTML activation. To make life nice for template developers, some associated template functions should be created. For example
    • {attribute_view_ajax_gui $attribute=$node.data_map.intro}
    • {node_view_ajax_gui $content_node=$node $editable_attribs=array(status, category)}
  • Multiple object editing should be supported
    • even mixing classes

That’s it for now, follow-ups will be made in new posts



No comments yet — be the first.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: