Let me make it clear. I cleaned up the TrainModel API. In fact I don't think we
need methods like enterSubTrain, exitSubtrain. All we need is a way to get to
the parent level and the child level.
The essential difference between a tree component and the train is that tree
always (or most often) shows multiple levels of data at the same time, but the
train will not. It only shows one level (or a list of nodes) at a time. Any
time the user wants to go up or down one level, the model simply returns a new
list. Most often users may have only one level in the train, in which case
using a TreeModel is an overkill as most methods will be a no-op.
public abstract class TrainModel extends CollectionModel
{
// True if the current train has a child train
public abstract boolean hasSubTrain();
// True if the current train has a parent train
public abstract boolean hasParent();
// Returns the subTrain if the current train is a container of another train
public abstract TrainModel getSubTrain();
// Returns the parent train and possibly sets the focusRowKey
public abstract TrainModel getParentTrain();
// (I meant to write focusRowKey not viewId)
public abstract Object getFocusRowKey ();
}
- Pavitra
________________________________
From: Gabrielle Crawford [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 28, 2006 7:51 PM
To: [email protected]
Subject: Re: [Proposal] ProcessModel changes
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
