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; by the way, this is a perfect open-source thing to do - if you can identify what is IE 4 specific, defen 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: This is the summary This XML tag is transformed into an HTML tag before being sent to the client, as follows: This is the summary All SPAN section's IDs are constructed as following: 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, Brad Neuberg 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 are transformed into SPAN tags as follows: For the example above the SPAN tag would be: 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 Name In-Place Editable? ------------------------------------------ summary yes title yes author yes article_text yes created_by no original no last_updated no created_on no 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 ------------------------------ *How to handle inplace editing of a property that is a hyperlink? When the user clicks on the link, should we follow the link or go into inplace edit mode? Currently unresolved. *The Mac version of IE 4 seems to drop the SAVE button for the large TEXTAREA. *The browser seems to lock up when one scrolls down and lets the text for the article_text portion go up past the top of the screen, and then clicks on the area to turn it into a TEXTAREA. Todo ---- *Define simple XML syntax and server-side java classes to convert an html file that is interleaved with XML descriptions for the weblet, such as a business card weblet:

Business Card for Brad Neuberg

Organization: OpenPortal
Phone-Number: 212-853-7201
Email: bkn3@columbia.edu

The java classes should convert each of the tags in the 'weblet' namespace, such as , into appropriate SPAN tags according to the section in this document titled 'How a weblet's properties are changed into SPAN elements'. There will also be an attribute called inplace_edit="true|false" which specifies whether this attribute can be inplace-edited. Another attribute will be replaceWithForm="javascript_method" and saveProperty="javascript_method", which will give the name of the javascript method that is to override the default implementations of the replaceWithForm and saveProperty methods, as described in the section 'Overriding default weblet form behavior'; the new methods referred to by these attributes should be somewhere in the html file already. *Add EDIT EVERYTHING button on button for those people who don't have DHTML browsers. *Detect whether DHTML browser is being used *Add Netscape support? Is it possible with Netscape Layers? *Give some UI indication that a property is editable (rollovers, tooltips, etc.). *Get persistance working by trying to figure out how to send values back to the server using saveNewValueToServer() and a POST method. How do you open an URL from JavaScript? Impact on other OpenPortal modules ---------------------------------- *Update the org.openportal.weblet JSP syntax to reflect the new flexibility described in the section 'Interaction between the client and the server'