You are here: Home Plone products Products.ExternalEditor

Products.ExternalEditor (1.1.0)

1
by Olha Pelishok last modified 2010-12-06
0.0
0.0
0.0
0.0
Released on 2010-12-01 by Casey Duncan under Zope Public License (ZPL) available for All platforms.
Software development stage: stable
A product that allows you to edit zope objects in the editor of your choice

The Zope External Editor is a new way to integrate Zope more seamlessly with client-side tools. It has the following features:

  • Edit objects locally, directly from the ZMI.
  • Works with any graphical editor application that can open a file from the command line, including: emacs, gvim, xemacs, nedit, gimp, etc.
  • Automatically saves changes back to Zope without ending the editing session.
  • Associate any client-side editor application with any Zope object by meta-type or content-type. Both text and binary object content can be edited.
  • Locks objects while they are being edited. Automatically unlocks them when the editing session ends.
  • Can add file extensions automatically to improve syntax highlighting or file type detection.
  • Works with basic auth, cookie auth and Zope versions. Credentials are automatically passed down to the helper application. No need to reauthenticate.
  • https support (untested)

Using It

Use of the application is about as easy as using the ZMI once your browser is configured (see the installation instructions). To edit an object externally, just click on the pencil icon next to the object in the ZMI. The object will be downloaded and opened using the editor application you have chosen (you will be prompted the first time to choose an editor).

You edit the object just like any other file. When you save the changes in your editor, they are automatically uploaded back to Zope in the background. While the object is open in your editor, it is locked in Zope to prevent concurrent editing. When you end your editing session (ie you close your editor) the object is unlocked.

How it Works

Ok, so this all sounds a bit too good to be true, no? So how the heck does it work anyway? First I'll give you a block diagram::

+------------+ +------------+ +---------+ +------+
| Editor App | <-- | Helper App | <-- | Browser | <-/ /- | Zope |
+------------+ +------------+ +---------+ +------+
^ ^ ^ ^
\ / \ /
v v -----------------------/ /----
-------
/ Local \
\ File /
-------

Now the key to getting this to work is solving the problem that the editor cannot know about Zope, and must only deal with local files. Also, there is no standard way to communication with editors, so the only communication channel can be the local file which contains the object's content or code.

It is trivial to get the browser to fire up your editor when you download a particular type of data with your browser. But that does you little good, since the browser no longer involves itself once the data is downloaded. It just creates a temp file and fires off the registered application, passing it the file path. Once the editor is running, it is only aware of the local file, and has no concept of where it originated from.

To solve this problem, I have developed a helper application whose job is essentially two-fold:

  • Determine the correct editor to launch for a given Zope object
  • Get the data back into Zope when the changes are saved

So, let's take a step by step look at how it works:

  1. You click on the external editor link (the pencil icon) in the Zope management interface.
  2. The product code on the server creates a response that encapsulates the necessary meta-data (URL, meta-type, content-type, cookies, etc) and the content of the Zope object, which can be text or binary data. The response has the contrived content-type "application/x-zope-edit".
  3. The browser receives the request, and finds our helper application registered for "application/x-zope-edit". It saves the response data  locally to disk and spawns the helper app to process it.
  4. The helper app, reads its config file and the response data file. The meta-data from the file is parsed and the content is copied to a new temporary file. The appropriate editor program is determined based on the data file and the configuration (or alternately by asking the user).
  5. The editor is launched as a sub-process of the helper app, passing it the file containing the content data.
  6. If so configured, the helper app sends a WebDAV lock request back to Zope to lock the object.
  7. Every so often (if so configured), the helper app stats the content file to see if it has been changed. If so, it sends an HTTP PUT request back to Zope containing the new data.
  8. When the editor is closed, the content file is checked one more time and uploaded if it has changed. Then a WebDAV unlock request is sent to Zope.
  9. The helper application exits.

 

Document Actions
Powered by Plone