Readme for Inplace-Editing Package

Author: Brad Neuberg
Email: bkn3@columbia.edu, brad@basesystem.com
Last Updated: 4/29/99
License of package: GPL (GNU Public License) - other licenses available - email the author
Requirements: Internet Explorer 4
Tested on: IE 4 for PC

Introduction

This package makes it possible to do in-place editing of onscreen items in a web browser. The data items which can be edited are structured, such as a business card or an article, so that specific fields in the data item can be clicked on for in-place editing of that field. These structured data components are called weblets. Since the editing is completely open, this allows communal and group creation of structured documents through the web. Further possibilities such as annotation are also possible. The technology that is used to achieve this package is JavaScript 1.2, the Document Object Model (DOM) level one, and HTML 4.

Note that all of the techniques used in this package try to stay as close as possible to the W3C (World Wide Web Consortium)'s HTML 4, DOM, and EcmaScript 1.2 standards (EcmaScript is another name for JavaScript). Unfortunately, the only browser that fully supports the standards needed to do the above is Internet Explorer 4, so the code will only work in IE 4 right now (Netscape Navigator 4 actually tried to introduce its own proprietary alternatives to the W3C's standards!). However, Mozilla 5 will have full compliance with XML, DOM, and EcmaScript 1.2, and so the code should work when Mozilla comes out. Since IE 4 doesn't have strict conformance with the standards, one or two small IE 4 abilities might be necessary for now, but should be removable in the future for cross-browser compatibility.

The motivation for this project is to combine the acts of browsing the web and changing the web together seamlessly. It makes sense to put editing together with browsing, since this can lead to new forms of interaction and higher levels of participation by members. The eventual goal is to build the Editable Web, so that working with the web becomes more like interacting with a computer spreadsheet, where values can be directly changed and manipulated, rather than like interacting with a magazine or an old batch-computer system. Both magazines and batch-computer systems have a long delay between reading information and then changing this information. A system gets far more interesting when changing and reading information can happen at a very fast velocity, because you get entirely new phenomena and new forms of organization that were not possible before. Just as high-speed graphical interaction with computers gave rise to the personal computer, which itself created new forms of art, business, and social organization, high-speed interaction with web pages should help to create some fascinating phenomena on the World Wide Web.

OpenPortal is a broad description for a collection of technologies that help foster collaborative and component-based websites. It is an open-source project run by Brad Neuberg, and some of the modules were produced as a result of school projects, such as the inplace-editing package you are reading right now. For more information on OpenPortal see http://www.openportal.org.


Samples & Examples

The first example is in the file inline1.html. It shows an example page from an OpenPortal system. This example page has an Article weblet. You can click on the article's summary, which says "An analysis of the similarities between major commercial portals," in the upper left-hand side of the window. You can also click on the article's title, "Why do portals all look alike?"; the author, "Brad Neuberg"; and the full-text of the article. These properties will change into in-place editing fields.


How a weblet's properties are changed into SPAN elements

A weblet has an id and properties. For example, an article weblet might have the id Element1 and the properties summary, category, author, date, and article text. When the user interface for this weblet is constructed, each of these properties becomes a region of the user interface with a SPAN element around the particular property. For example, a particular weblet's summary property would exist on the server side as the following XML:


<weblet:SUMMARY>This is the summary</weblet:SUMMARY>

This XML tag is transformed into an HTML tag before being sent to the client, as follows:


<SPAN ID="Element1:summary" CLASS="WebletProperty">This is the summary</SPAN>   

All SPAN section's IDs are constructed as following:


<SPAN ID="Weblet ID:property type">

So for the above example the property type is SUMMARY, taken from the XML tag weblet:SUMMARY, while the Weblet ID actually comes from the main weblet tag around all of the properties.

If some property includes a hyperlink within it to the specified resource, such as to an authors name, the span _includes_ the hyperlink as well. For example,


<SPAN ID="Element1:author" CLASS="WebletProperty"><A HREF="http://somehost.com/Brad+Neuberg">Brad Neuberg</A></SPAN>

The idea behind this is if some javascript needs to manipulate this span, that it can also manipulate the hyperlink if the property value changes, since the hyperlink probably takes the person to the same resource as specified by the property value (i.e. if the author is 'Brad Neuberg', then the hyperlink would take the user to "Brad Neuberg's" homepage).

Why colons between the ID name and the property type (i.e. "Element1:summary")? Java Server Pages uses colons for accessing a JavaBean's properties, and since weblets will probably be transformed from JSP elements on the server side into the DHTML user interface for the client side, colons are used for compatibility and simplicity.

Also note that onLoad="initialize()" is added to the BODY tag of the HTML document. All XML tags that declare a weblet itself, and not its properties, such as


<weblet:BUSINESS-CARD id="Element1">

are transformed into SPAN tags as follows:


<SPAN id="Weblet ID" class="weblet:Weblet Type">

For the example above the SPAN tag would be:


<SPAN id="Element1" class="weblet:BUSINESS-CARD">

Overriding default weblet form behavior

When a weblet property is clicked on, a method called replaceWithForm(somePropertyElem) is called. This method simply replaces the SPAN tag with the weblet property with an edit field, which is a simple TEXT field of one line. It also checks to see if the SPAN tag has a method named replaceWithForm defined; if so, then it it calls this method instead of the default one. To add your own replaceWithForm method to a particular weblet property, you would use the following:


document.all["Element ID:property Name"].replaceWithForm = newFormBehavior;

where newFormBehavior() is the name of some new method that overrides the default replaceWithForm method. For example, the newFormBehavior method could be defined as follows


function newFormBehavior(somePropertyElem) {
		 this.innerHTML = "some new form stuff here";
}

There is an analogous method to replaceWithForm() for when an edit field is saved; it is named saveProperty(). This method merely saves the value of the single INPUT form. If you want to override this behavior, do it in the same manner as with replaceWithForm(). the saveProperty() method checks to see if a given SPAN replaced the default saveProperty() method, and runs it accordingly.

Note that you must place all attempts to override the default methods, such as


document.all["Element ID:property Name"].replaceWithForm = newFormBehavior;

into an initialize() method which is called when the HTML document is loaded (an onLoad is added to the BODY tag).


Properties for Article Weblet

An article weblet has the following properties.

Property NameIn-Place Editable?
summaryyes
titleyes
authoryes
article_textyes
created_byno
originalno
last_updatedno
created_onno

Interaction between the client and the server

When the user has pressed the SAVE button for an edit field, a method called saveNewValueToServer() is called which sends the new value from the client to the server. This value is sent using a POST request with the following name/value pairs. Anyone trying to create a server that works with the inplace-editing DHTML package needs to have their server able to capture these name/value pairs. They are as follows:

name value
---- -----
action save
action_type single_field
weblet_name the name in the ID attribute before the colon (i.e. id='Element1:someProperty' would have the weblet_name Element1) specific property name specific property value (ex. "organization") (ex. "OpenPortal")

Reserved ID names for properties

No property name should be used that ends with the string _Input or _Submit . These are added to the end of some of the ID names for internal purposes.


Issues, Known Problems, & Bugs


Todo


Impact on other OpenPortal modules