Comments below - Pavitra
> -----Original Message----- > From: Gabrielle Crawford [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 27, 2006 6:20 PM > To: [email protected] > Subject: Re: [Proposal] ProcessModel changes > > > > Pavitra Subramaniam wrote: > > >Comments below > > > >- Pavitra > > > > > >- Whatever we decide to do about the autobind or rowData > interface is ok with me. > >- But I believe that the train component should not be bound > to a MenuModel for various reasons. One a train is not a menu. > > > The name menuModel should have been changed, but there is > nothing menu specific about it. > > >Two, there are cases (internally @ Oracle) where people want > to define train metadata using structures, other than > MenuModel & that has information that can help determine, > say, the visited state of a stop. > > > > > Can you explain > 1] What this new api you are proposing looks like? - (This is just an idea and I have not thought through this completely. So read on.) - It probably will be very close to the list of all abstract methods defined in MenuModel -> TreeModel -> CollectionModel -> DataModel (and interface RowKeyIndex). But it will be simpler and specific to the train and makes no assumptions about the underlying data structure that backs the model. - Currently, if a consumer of train defines their train metadata in a structure (other than an XmlMenuModel or MenuModel), like their own XML metadata, they would have to implement the following methods to get a model that the train expects. The methods below are very treeModel specific, as one can argue that the train ultimately is a tree. Although in reality it is most likely to be a graph. abstract class MenuModel extends TreeModel { public abstract Object getFocusRowKey(); // from TreeModel extends CollectionModel public abstract boolean isContainer(); public abstract void enterContainer(); public abstract void exitContainer(); public abstract Object getContainerRowKey(Object childRowKey); // from CollectionModel extends DataModel public abstract Object getRowKey(); public abstract void setRowKey(Object key); // from RowKeyIndex - methods from RowKeyIndex as well // from DataModel public abstract int getRowCount() { } public abstract java.lang.Object getRowData() { } public abstract int getRowIndex() { } public abstract java.lang.Object getWrappedData() { } public abstract boolean isRowAvailable() { } public abstract void setRowIndex(int p1) { } public abstract void setWrappedData(java.lang.Object p1) { } } - Moreover the current TreeModel does not provide us a way to associate a label to a collection of nodes at the root level (or for that matter at every sub-level). For instance, we need to display a label of the train or parent train as we go deeper into the train hierarchy. It would be nice if the model can support this, especially if the train metadata already has a way to define this. - Having a TrainModel that makes no assumptions about the underlying data structure of the train data, makes it convenient for consumers that don't necessarily use the TreeModel. For instance, if I represent my train metadata using DataSets (or SDO for that matter) or some XML metadata structure, then all the consumer of the TrainModel needs to do is provide a list a train nodes for every level, and ability to go the parent or sublevel of the train, get the current node (or focusRowKey). For instance, if I had a TrainModel like below, the consumer who uses MenuModel to define their train metadata would create a MenuTrainModel implementation that internally uses the ProcessMenuModel. And the consumer who uses a custom XML structure or a DataObject to represent their train metadata, will define a XmlTrainModel, or DataSetTrainModel and internally use their own data structures to serve up information to the train. The APIs below are by no means complete, it's just an example. public abstract class TrainModel extends DataModel { // True if the current train has a child train public abstract boolean hasSubTrain(); // Enter the subTrain if the current train is a container of another train public abstract void enterSubTrain(); // Leave the subTrain to return to the parent train level public abstract void exitSubTrain(); // public abstract Object getParentNode(Object childNode); // gets the number of nodes at a level public abstract int getNodeCount(); // gets the rowData public abstract Object getNode(Object key); // gets the node key. Key identifies a node uniquely public abstract Object getNodeKey (); public abstract Object getViewId (); } - Finally, in combination with the rowData interface or the autoBind feature, they can provide custom implementations for behavior of states (visited/selected/disabled) etc. - What do you think? > > Gab > > >
