Home   Info   DevZone   Wiki   UsersWeb  |  MainWeb  |  InfoWeb  |  DevZoneWeb  |  SupportWeb
[ XMLApplicationDraft ] [ not logged in ] [ Web: Imported ] goto:  options [ get info on or edit ] [ login or new user ] [ list of topics, hubs & nodes, or recent changes ]

It would be very nice if building XML based applications was as easy as glueing together different JavaBeans. Wouldn't it be great if you could tie different XML Elements with already existant display, edit, and control classes, letting the framework do most of the hardwork for you? This is the goal of the XMLApplicationFramework (which used to be called the XMLBrowserFramework). XML documents also have structure, where one Element can 'hold' another Element. The XMLApplicationFramework tries to take this into account by allowing one Element to become an aggregate of another element. Another goal of the XMLApplicationFramework is to allow for ApplicationNodes to have multiple Identities at different times; in a way, it's like letting ApplicationNodes wear different 'hats' at different times. Here is a skeleton draft of the Interfaces that will be used for the XMLApplicationFramework; feedback is definently encouraged and very much appreciated (you'll earn an entry on my Kudo list at BradNeuberg!)

Uhhh... I had deleted everything below this, since I'm working on a new approach, but someone seems to have restored it. Keep in mind that the draft below is not the one I'm working on anymore.

--BradNeuberg, 2/22/98

(Are you aware that three days worth of changes to the JOS site were lost (Feb. 19-21)? The reappearance of this material is probably just a reversion to the state of the page on Feb. 18. You should probably just delete it again. LestonBuell 2/23/98)

/* XMLApplication framework draft - used to build an XML
	application by glueing together JavaBeans, with arbitrary
	ApplicationNode behaviors, Edit behaviours, and Display behaviours,
	simulating the Model-View-Control (Edit?) Pattern */
/* @version 0.1, very very Alpha */
/* @date 2/16/98 */
/* @author bkn3@columbia.edu, Brad Neuberg */
/* @organization JOS at http://www.jos.org */
/* @license Public-License */

/** An aggregate holds other elements.  Right now, all
  * aggregates hold 'lesser' objects, in the sense that
  * the aggregate acts as a hierarchical container of 
  * objects below it */ 
Interface Aggregate {
	Object getInstanceOf(Class class);
	Object putInstanceOf(Class class);
	Object isInstanceOf(Class class);
	Enumeration getEnumerationFor(Class class);
	}

/** Used to dynamically get, put, and check the different
  * identities that a given object can have.  An attempt
  * to simulate composition.  Could be used to give Nodes
  * dynamic Identities; right now the Identity of a Node is
  * hard-coded as Edit, Display, XMLElement, etc., but in
  * the future a Node could have run-time Identities, providing
  * a sophisticated file system/object store based on
  * fluid Identities.
  * Currently not used */
Interface Identity {
	getIdentityOf(Class class);
	putIdentityOf(Class class);
	hasIdentityOf(Class class);
	}

/** An interface for dealing with the presentation
  * of a node */
Interace Display {
	void display();
}

/** An interface for dealing with the editing of a node.  Used to
  * give Wiki-like editing to ApplicationNodes */ 
Interface Edit {
	Object getEditBean();
}

/** An interface that treats a node like an XML element;
  * used to seperate the implementation of nodes from
  * the XML standard itself, so that we can use future
  * non-XML standards and still retain the Edit, Display, 
  * etc. code */
Interface XMLElement {
	void setAttributeName(String name, String value);
	String getAttributeName();
	void setElementName(String name);
	String getElementName();
	void setElementType(String type);
	String getElementType();
	/* maybe add future DTD support or a seperate DTD
			  interface */
}

/** An XMLObjectManager that takes care of parsing an XML
  * file, initializes the different ApplicationNodes, and adds the correct aggregates and identites (Edit, Display, etc.) to the Nodes. */ 
Interface XMLObjectManager {
	/* I currently have no idea how such an interface 
		would be put together */
}

public class ApplicationNode implements Aggregation, Edit, Display, XMLElement {
	/* stuff here */
}

I think maybe that the Edit, Display, and XMLElement interfaces can be collapsed onto the Identity interface, in which case the XMLObjectManager would add new Identities to the Node at run-time, in this case an EditIdentity, a DisplayIdentity, and an XMLIdentity. Am I breaking any OOP-design stuff here?

--BradNeuberg, 2-16-98

You should change:

I agree with:

I disagree with:

A framework is supposed to make a coder's life easier. To make the XMLApplicationFramework easier on the back's of coders, you should:

Content of these pages are owned and copyrighted by the poster.
Hosted by: