Re: [Proposal] ProcessModel changes

[Gabrielle Crawford]

Hi, Pavitra Subramaniam wrote: 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. Agreed that this data isn't currently available anywhere. - 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). Getting the parents and children sounds like a treeModel to me, so I'm not sure I understand why they can't just be implementations of the treeModel. Why can't you implement a treeModel if you're using xml, etc? I don't know about DataSets, but when I look at your proposal below it looks a lot like the treeModel api, so I'm not sure why it's an improvement. 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. I think in the end they are going to end up with something suspiciously like the tree model. The APIs below are by no means complete, it's just an example. You are extending DataModel below, so you have to implement all of: 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) { } As for the rest you've swapped the word "Node" for "Row", but you've basically renamed many of the methods on TreeModel and collectionModel. public abstract class TrainModel extends DataModel { // True if the current train has a child train public abstract boolean hasSubTrain(); isn't this just like isContainer on TreeModel? // Enter the subTrain if the current train is a container of another train public abstract void enterSubTrain(); isn't this just like enterContainer on TreeModel? // Leave the subTrain to return to the parent train level public abstract void exitSubTrain(); isn't this just like exitContainer on TreeModel? // public abstract Object getParentNode(Object childNode); isn't this just like getContainerRowKey(Object childRowKey) on TreeModel // gets the number of nodes at a level public abstract int getNodeCount(); isn't this just like getRowCount on DataModel, which you're already extending? // gets the rowData public abstract Object getNode(Object key); isn't this just like getRowData() on DataModel, which you're already extending? // gets the node key. Key identifies a node uniquely public abstract Object getNodeKey (); isn't this just like getRowKey() on CollectionModel? public abstract Object getViewId (); There's nothing in the current model that says anything about view id's and I don't think there should be. You should be able to write a train without navigating to a different viewId. But I'm confused why viewId is on here? Aren't you still using a command child, outcomes, and jsf navigation? Is there a focusPath method? Is there a setRowKey method? } - 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? So maybe I'm not understanding this, but in general so far it seems like it's renaming methods, plus one viewId method that I don't understand. So I would assume you're going to say it has fewer methods, can you point to specific methods on menuModel that are a burden to implement? In some cases, like isSortable, or getSortCriteria it's kinda weird, but it seems like you're reinventing tree model for the most part, which doesn't seem all that useful.  Again, maybe I'm not understanding the problem.... Thanks, Gab