[Proposal] ProcessModel changes

[Simon Lessard <si...@gmail.com>]

Good morning everyone,

While making the infamous train renderer, it was difficult to determine if a
step was visited or not. So, in the end, visited became "before current
step" and unvisited "after current step". Also, most of the times, the
commandNavigationItem placed in the stamp has the same attribute values, all
linked to the model.

Therefore, I was wondering if it would be acceptable to move all attributes
to the ProcessModel class and remove the node stamp from process train
component. Using a processTrain would require only the following then:
<tr:train value="#{process.model}" action="#{process.onAction}" />.

I place the action separated from the model because linking it directly
would be against JSF soul imho. However, nothing would prevent the end user
to place the action method directly on the model if he wanted with that
method either. The only prerequisite is that the train renderer use a
setRowKey on the right step during processDecode, but it already does that.

I would use following signatures inside ProcessModel to support this
feature:

public abstract class ProcessModel extends MenuModel
{
  /* Get the amount of of rendered stations in the process */
  public abstract ProcessModel.Train getTrain();

  public abstract class Train
  {
    /* Get the rendered steps of the train*/
    public abstract Station getStations();

    /* Determine if this train is the child of another */
    public abstract boolean isSubTrain();
  }

  public abstract class Station
  {
    /* Get this step's label */
    public abstract String getLabel();

    /* Get the rowKey for this station */
    public abstract Object getRowKey();

    /* Determines if the link to this step is disabled*/
    public abstract boolean isDisabled();

    /* Determines if the link to this step is immediate */
    public abstract boolean isImmediate();

    /* Determines if the link to this step is read only */
    public abstract boolean isReadOnly();

    /* Determines if the link to this step is the current one */
    public abstract boolean isSelected();

    /* Determines if this station is visited */
    public abstract boolean isVisited();
  }
}

At first, this may look like a decrease in the flexibility, but it's
actually improving it by giving the full power on the station's state to the
user, rather than having it deduced by the renderer in a hard coded way. The
only con I see is the inclusion of some view layer data in the model, namely
label, immediate and readOnly.

Anyone has a reason I didn't think about to veto that proposition?


Regards,

~ Simon

Re: [Proposal] ProcessModel changes

[Gabrielle Crawford <ga...@oracle.com>]

`I apologize, the link I sent is to an internal Oracle server. The Trinidad
javadoc is still not up, so I am using an internally generated copy of the
doc. Sorry about that!  
  
Thanks,  
  
Gab  
`  
Gabrielle Crawford wrote:

>  
>  Pavitra Subramaniam wrote:
>

>>

>>     Come to think of it, we do not require getParentTrain() and
getSubTrain(). Because if the user wants to navigate to the parentTrain, they
are most likely going to hit a command outside of the train (or even the
parent icon), that will simply position whatever datastructure that stores the
train data, to the right level (based of the focusRowKey). I am assuming that
this data structure is page-flow or session scoped. Same goes for the
navigating to the subTrain.

>>  
>>     This way the model will only have to be list and the model implementor,
can store their complicated train metadata in their own structures. I see no
reason to load the entire tree of data into the model. A list can be served up
whenever it's needed by a managed bean.

>>  
>
> `It's possible to create a treeModel from a list``, for example I believe
> you can use ModelUtils to do this:  
>  [http://bali.us.oracle.com:2020/releases/adf.faces/jm7/multiproject/adf-
> faces-
> api/apidocs/org/apache/myfaces/trinidad/model/ModelUtils.html#toTreeModel(java.lang.Object](http://bali.us.oracle.com:2020/releases/adf.faces/jm7/multiproject/adf-
> faces-
> api/apidocs/org/apache/myfaces/trinidad/model/ModelUtils.html#toTreeModel%28java.lang.Object))  
>  
>  The underlying data the model is built on is often shared, even if the
> model is not, so I'm not sure how big a concern this is. ``Anyway, I would
> think whether you pull all the data at once has to do with the tree
> implementation, not the tree model api.`  
>  `  
>  ``  
>  `
>

>>

>>     public abstract class TrainModel extends CollectionModel

>>     {

>>       // True if the current train has a child train

>>       public abstract boolean isSubTrain();

>>  
>>       // gets the parent train label if I am a subTrain

>>       public abstract String getParentTrainLabel ()

>>  
>>       // (I meant to write focusRowKey not viewId)

>>       public abstract Object getFocusRowKey ();

>>     }

>>  
>>     Isn't this much simpler? What do you think?

>>  
>
> `It's a bit simpler, but with the design above the methods you're saving are
> now down to the tree methods, and getDepth can be used to determine if it's
> a subtrain.  
>  ``  
>  I guess my overall concern is that although the current train design only
> shows a single level, I have seen train designs in the past that show parent
> and subtrains at once, in a vertical tree structure that goes on the side of
> the page. Or someone might want to make the icon that goes up to the parent
> train a link, or maybe even render something for all the parent levels in
> that spot. Having a tree model supports these designs.  
>  
>  However ``I don't know that the train is built to support this now, meaning
> I'm not sure decoding nodes that aren't siblings with the focus row key node
> would work. If it doesn't maybe it should.`  
>  `  
>  For the train label, I assume you mean something more general than the text
> attribute on the parent node. Really even if you have a flat list you might
> want an overall name for the group of nodes. Like "Checkout" for an app
> where the nodes are "billing address", "shipping address", etc. So with an
> api like "getGroupName", the implementation can get the name from wherever
> it wants, from the parent or not. I'm not sure I love this, but it seems
> more general than forcing a parent node. To get the parents group name you'd
> do exitContainer() and then getGroupName(). You could use this to render the
> names of all the parent groups, not just up a single level.  
>  
>  Thanks,  
>  
>  Gab  
>  `
>

>>

>>     - Pavitra

>>  
>>  
>>  
>>

>>>

>>>     -----Original Message-----

>>>     From: Pavitra Subramaniam
[[mailto:pavitra.subramaniam@oracle.com](mailto:pavitra.subramaniam@oracle.com)]

>>>     Sent: Thursday, September 28, 2006 9:09 PM

>>>     To: [adffaces-dev@incubator.apache.org](mailto:adffaces-
dev@incubator.apache.org)

>>>     Subject: RE: [Proposal] ProcessModel changes

>>>  
>>>     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:gabrielle.crawford@oracle.com](mailto:gabrielle.crawford@oracle.com)]

>>>             Sent: Thursday, September 28, 2006 7:51 PM

>>>             To: [adffaces-dev@incubator.apache.org](mailto:adffaces-
dev@incubator.apache.org)

>>>             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

>>>

>>>  
>>>  
>>>  
>>>  
>>  
>>  
>>  

Re: [Proposal] ProcessModel changes

[Gabrielle Crawford <ga...@oracle.com>]

  
Pavitra Subramaniam wrote:

>
>     Come to think of it, we do not require getParentTrain() and
> getSubTrain(). Because if the user wants to navigate to the parentTrain,
> they are most likely going to hit a command outside of the train (or even
> the parent icon), that will simply position whatever datastructure that
> stores the train data, to the right level (based of the focusRowKey). I am
> assuming that this data structure is page-flow or session scoped. Same goes
> for the navigating to the subTrain.
>  
>     This way the model will only have to be list and the model implementor,
> can store their complicated train metadata in their own structures. I see no
> reason to load the entire tree of data into the model. A list can be served
> up whenever it's needed by a managed bean.
>  

`It's possible to create a treeModel from a list``, for example I believe you
can use ModelUtils to do this:  
<http://bali.us.oracle.com:2020/releases/adf.faces/jm7/multiproject/adf-faces-
api/apidocs/org/apache/myfaces/trinidad/model/ModelUtils.html#toTreeModel(java.lang.Object>)  
  
The underlying data the model is built on is often shared, even if the model
is not, so I'm not sure how big a concern this is. ``Anyway, I would think
whether you pull all the data at once has to do with the tree implementation,
not the tree model api.`  
`  
````  
`

>
>     public abstract class TrainModel extends CollectionModel
>     {
>       // True if the current train has a child train
>       public abstract boolean isSubTrain();
>  
>       // gets the parent train label if I am a subTrain
>       public abstract String getParentTrainLabel ()
>  
>       // (I meant to write focusRowKey not viewId)
>       public abstract Object getFocusRowKey ();
>     }
>  
>     Isn't this much simpler? What do you think?
>  

`It's a bit simpler, but with the design above the methods you're saving are
now down to the tree methods, and getDepth can be used to determine if it's a
subtrain.  
``  
I guess my overall concern is that although the current train design only
shows a single level, I have seen train designs in the past that show parent
and subtrains at once, in a vertical tree structure that goes on the side of
the page. Or someone might want to make the icon that goes up to the parent
train a link, or maybe even render something for all the parent levels in that
spot. Having a tree model supports these designs.  
  
However ``I don't know that the train is built to support this now, meaning
I'm not sure decoding nodes that aren't siblings with the focus row key node
would work. If it doesn't maybe it should.`  
`  
For the train label, I assume you mean something more general than the text
attribute on the parent node. Really even if you have a flat list you might
want an overall name for the group of nodes. Like "Checkout" for an app where
the nodes are "billing address", "shipping address", etc. So with an api like
"getGroupName", the implementation can get the name from wherever it wants,
from the parent or not. I'm not sure I love this, but it seems more general
than forcing a parent node. To get the parents group name you'd do
exitContainer() and then getGroupName(). You could use this to render the
names of all the parent groups, not just up a single level.  
  
Thanks,  
  
Gab  
`

>
>     - Pavitra
>  
>  
>  
>

>>

>>     -----Original Message-----

>>     From: Pavitra Subramaniam
[[mailto:pavitra.subramaniam@oracle.com](mailto:pavitra.subramaniam@oracle.com)]

>>     Sent: Thursday, September 28, 2006 9:09 PM

>>     To: [adffaces-dev@incubator.apache.org](mailto:adffaces-
dev@incubator.apache.org)

>>     Subject: RE: [Proposal] ProcessModel changes

>>  
>>     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:gabrielle.crawford@oracle.com](mailto:gabrielle.crawford@oracle.com)]

>>      Sent: Thursday, September 28, 2006 7:51 PM

>>      To: [adffaces-dev@incubator.apache.org](mailto:adffaces-
dev@incubator.apache.org)

>>      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

>>

>>  
>>  
>>  
>>  
>  
>  
>  

RE: [Proposal] ProcessModel changes

[Pavitra Subramaniam <pa...@oracle.com>]

Come to think of it, we do not require getParentTrain() and getSubTrain(). Because if the user wants to navigate to the parentTrain, they are most likely going to hit a command outside of the train (or even the parent icon), that will simply position whatever datastructure that stores the train data, to the right level (based of the focusRowKey). I am assuming that this data structure is page-flow or session scoped. Same goes for the navigating to the subTrain. 

This way the model will only have to be list and the model implementor, can store their complicated train metadata in their own structures. I see no reason to load the entire tree of data into the model. A list can be served up whenever it's needed by a managed bean. 

public abstract class TrainModel extends CollectionModel 
{
  // True if the current train has a child train
  public abstract boolean isSubTrain();

  // gets the parent train label if I am a subTrain
  public abstract String getParentTrainLabel ()

  // (I meant to write focusRowKey not viewId)
  public abstract Object getFocusRowKey (); 
}

Isn't this much simpler? What do you think?

- Pavitra
 

> -----Original Message-----
> From: Pavitra Subramaniam [mailto:pavitra.subramaniam@oracle.com] 
> Sent: Thursday, September 28, 2006 9:09 PM
> To: adffaces-dev@incubator.apache.org
> Subject: RE: [Proposal] ProcessModel changes
> 
> 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:gabrielle.crawford@oracle.com] 
> 	Sent: Thursday, September 28, 2006 7:51 PM
> 	To: adffaces-dev@incubator.apache.org
> 	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
> 	
> 
> 
> 

RE: [Proposal] ProcessModel changes

[Pavitra Subramaniam <pa...@oracle.com>]

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:gabrielle.crawford@oracle.com] 
	Sent: Thursday, September 28, 2006 7:51 PM
	To: adffaces-dev@incubator.apache.org
	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
	

Re: [Proposal] ProcessModel changes

[Gabrielle Crawford <ga...@oracle.com>]

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  

RE: [Proposal] ProcessModel changes

[Pavitra Subramaniam <pa...@oracle.com>]

Comments below

- Pavitra
 

> -----Original Message-----
> From: Gabrielle Crawford [mailto:gabrielle.crawford@oracle.com] 
> Sent: Wednesday, September 27, 2006 6:20 PM
> To: adffaces-dev@incubator.apache.org
> 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
> 
> 
> 

Re: [Proposal] ProcessModel changes

[Gabrielle Crawford <ga...@oracle.com>]

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?
2] How this is better than writing a menuModel implementation with their 
data?

Thanks,

Gab

RE: [Proposal] ProcessModel changes

[Pavitra Subramaniam <pa...@oracle.com>]

Comments below

- Pavitra
 

> -----Original Message-----
> From: Simon Lessard [mailto:simon.lessard.3@gmail.com] 
> Sent: Wednesday, September 27, 2006 3:12 PM
> To: adffaces-dev@incubator.apache.org
> Subject: Re: [Proposal] ProcessModel changes
> 
> It happen in the process train renderer. The 
> commandNavigationItem does not need to know who is rendering 
> him. The best example is really how to determine if a 
> station/step/stop was already visited or not. Since the model 
> does not provide such information, the renderer has to infer them.

- 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. 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. So the rowData interface or the autoBindManager, could use this info available through the data model.

> 
> On 9/27/06, Arjuna Wijeyekoon <ar...@gmail.com> wrote:
> >
> > >
> > > > Adding a new model to your system will requires additional
> > > > > configuration.
> > > >
> > > >
> > > > IMO, small price to pay to avoid having to force all models to
> > implement
> > > > TrainStation (or some other API).
> > >
> > >
> > > It was not forcing though.
> >
> >
> > understood. it is not forcing if the page author is going 
> to bind each 
> > individual attribute by hand.
> > But it is forcing if the page author wants to auto bind.
> >
> >
> >
> >
> > > > 1. does not involve new tags.
> > > > >
> > > > >
> > > > > Row data interfaces does that
> > > > >
> > > > > 2. can be retrofitted into existing tags without having to 
> > > > > change
> > each
> > > > and
> > > > > > every tag implementation.
> > > > >
> > > > >
> > > > > Idem
> > > > >
> > > >
> > > > If I want to support outputText as well as 
> commandNavigationItem,
> > don't
> > > I
> > > > need to modify both those components?
> > >
> > >
> > > Your solution requires to add an autoBind attribute  to all those 
> > > components.
> >
> >
> > however, the change will happen up in UIXComponentBase so child 
> > component classes will be untouched.
> >
> > Interfaces on row data have nothing to do with the child
> > > component being used for purpose of states (visited, 
> unvisited, etc. 
> > > in case of proces train).
> >
> >
> > I don;t think I understand. Something needs to test and cast the 
> > rowdata to a TrainStation.
> > where does that happen?  Doesn't it happen inside the 
> > CommandNavigationItem or corresponding renderer?
> >
> > --arjuna
> >
> > However it would indeed requires some changes for
> > > UIComponent attribute autobinding.
> > >
> >
> >
> > On 9/27/06, Simon Lessard <si...@gmail.com> wrote:
> > >
> > > Hello Arjuna,
> > >
> > >
> > > On 9/27/06, Arjuna Wijeyekoon <ar...@gmail.com> wrote:
> > > >
> > > > Hi Simon,
> > > > thanks for your reply.
> > > >
> > > > Could be splitted in more than one interface
> > > > >
> > > >
> > > > Well then you could have an explosion of interfaces. My 
> point was 
> > > > not
> > to
> > > > have separate interfaces for each concept.
> > > > I just wanted it to be flexible so that different people could 
> > > > provide
> > > the
> > > > implementations for the different concepts.
> > > > So person A (non JSF guy) provides the native model.
> > > > Person B (JSF guy) provides the AutoBindManager that 
> knows how to 
> > > > pull properties from the model for various components.
> > >
> > >
> > > True
> > >
> > > > Adding a new model to your system will requires additional
> > > > > configuration.
> > > >
> > > >
> > > > IMO, small price to pay to avoid having to force all models to
> > implement
> > > > TrainStation (or some other API).
> > >
> > >
> > > It was not forcing though.
> > >
> > > > 1. does not involve new tags.
> > > > >
> > > > >
> > > > > Row data interfaces does that
> > > > >
> > > > > 2. can be retrofitted into existing tags without having to 
> > > > > change
> > each
> > > > and
> > > > > > every tag implementation.
> > > > >
> > > > >
> > > > > Idem
> > > > >
> > > >
> > > > If I want to support outputText as well as 
> commandNavigationItem,
> > don't
> > > I
> > > > need to modify both those components?
> > >
> > >
> > > Your solution requires to add an autoBind attribute  to all those 
> > > components. Interfaces on row data have nothing to do 
> with the child 
> > > component being used for purpose of states (visited, 
> unvisited, etc. 
> > > in case of proces train). However it would indeed requires some 
> > > changes for UIComponent attribute autobinding.
> > >
> > > Also, I don't know if the manager should be based on the
> > > > > component. I think it would be better to link it with 
> the data 
> > > > > model class, else using the same component with two different 
> > > > > model could lead to
> > a
> > > > > ClassCastException and/or incoherent attribute 
> values. At worst, 
> > > > > an
> > > AND
> > > > > link
> > > > > checking both the component and the data model could be used.
> > > >
> > > >
> > > > That is what I meant.  The manager would be referenced by both
> > component
> > > > class and data model class.
> > > > public static AutoBindManager getManager(Class componentClass, 
> > > > Class
> > > > dataModelClass)
> > >
> > >
> > > It works,  however, since some state attributes cannot be 
> found on 
> > > the chlid component there's still two choices. Either add all the 
> > > needed
> > attributes
> > > to
> > > the component, or support both ideas. That is row data 
> interface for
> > state
> > > if you want to overload the default behavior and autobinding for
> > component
> > > attributes. The latter is getting quite complex though.
> > >
> > >
> > > Regards,
> > >
> > > ~ Simon
> > >
> > > --arjuna
> > > >
> > > >
> > > > On 9/27/06, Simon Lessard <si...@gmail.com> wrote:
> > > > >
> > > > > Added some comments inline
> > > > >
> > > > > On 9/27/06, Arjuna Wijeyekoon <ar...@gmail.com> wrote:
> > > > > >
> > > > > > Hi,
> > > > > > So I feel a little unhappy with putting things like
> > "label/readOnly"
> > > > > > (which
> > > > > > are UI properties),
> > > > > > "visited/selected/disabled/outcome" (which is all navigation
> > > related),
> > > > > > and "immediate" (related to validation) all on a 
> single interface.
> > > > >
> > > > >
> > > > > Could be splitted in more than one interface
> > > > >
> > > > > I also feel like this solution solves a very specific 
> problem -
> > > > > > the new <tr:trainStop> only helps with 
> commandNavigationItem).
> > > Adding
> > > > > new
> > > > > > tags also bloats the number of tags in the framework.
> > > > > >
> > > > > > Also this forces MenuModel implementors to return 
> objects of a
> > > > specific
> > > > > > type
> > > > > > - so if they have a more comfortable native model, they are 
> > > > > > forced to return adaptor objects.
> > > > >
> > > > >
> > > > > The interface would be optional, if present it takes effect,  
> > > > > else
> > the
> > > > > default behavior is used.
> > > > >
> > > > > I'd like to propose a more general solution to the 
> problem of -
> > > > > >
> > > > > > > Some components (especially stamped components) 
> need a lot 
> > > > > > > of
> > > > > > boiler-plate
> > > > > > > code.
> > > > > > >
> > > > > > And I like to propose a solution that:
> > > > > > 1. does not involve new tags.
> > > > >
> > > > >
> > > > > Row data interfaces does that
> > > > >
> > > > > 2. can be retrofitted into existing tags without having to 
> > > > > change
> > each
> > > > and
> > > > > > every tag implementation.
> > > > >
> > > > >
> > > > > Idem
> > > > >
> > > > > 3. works with any model, so that the model author can 
> work with 
> > > > > any
> > > > model
> > > > > > he/she is most comfortable with.
> > > > >
> > > > >
> > > > > Semi idem
> > > > >
> > > > > 4. Easy to maintain - if someone wants to change the model 
> > > > > later,
> > > he/she
> > > > > > should be able to make the change in one place and 
> not have to 
> > > > > > touch a lot of files.
> > > > > > 5. can be used with all components, eg: 
> commandNavigationItem 
> > > > > > and
> > > the
> > > > > > menuModel.  nodeStamps in tree/treeTable.
> > > > > > 6. Does not force UI properties and validation 
> logic to all be 
> > > > > > on
> > > the
> > > > > same
> > > > > > interface.
> > > > >
> > > > >
> > > > > Using more than one interface solve that.
> > > > >
> > > > > So my thinking goes like this:
> > > > > >
> > > > > > Have an "autoBind" attribute on UIXComponentBase, so that a 
> > > > > > page
> > > > author
> > > > > > can
> > > > > > write:
> > > > > > <tr:train value="#{trainModel}" var="row"> 
> <tr:commandMenuItem  
> > > > > > autoBind="#{row}"/> </tr:train>
> > > > > >
> > > > > >
> > > > > > Have an interface called AutoBindManager:
> > > > > > public Object getProperty(FacesContext,UIComponent comp, 
> > > > > > String attributeName, Object model)
> > > > > >
> > > > > > AutoBindManagers are registered in trinidad-config, 
> and they 
> > > > > > are registered by two keys:
> > > > > > the component class (eg: CoreCommandMenuItem, or 
> UIXCommand)  
> > > > > > and the model class  (eg: Simon's  Station.class)
> > > > > >
> > > > > > When asked for a property, UIXComponentBase (or 
> FacesBeanImpl)
> > will
> > > > > first
> > > > > > look to see if there is a property (or 
> value-binding) set on 
> > > > > > the component directly. If not, it will see if there is an 
> > > > > > autoBinding
> > > set
> > > > > on
> > > > > > the component.  If so it will look up the list of 
> > > > > > AutoBindManager
> > > > sbased
> > > > > > on
> > > > > > the component and type of the autoBind object, and ask each
> > manager
> > > > for
> > > > > > the
> > > > > > property value, and stop when the first non-null property 
> > > > > > value is
> > > > > found.
> > > > > >
> > > > > > This way you can have (if you wish) different 
> AutoBindManagers 
> > > > > > for different concepts (like UI properties and validation 
> > > > > > logic).
> > > > > >
> > > > > > Does this make sense?
> > > > > > What do you all think?
> > > > >
> > > > >
> > > > > I like the idea. However, I don't know if it's a 
> better solution 
> > > > > on
> > > the
> > > > > usability side. Adding a new model to your system 
> will requires
> > > > additional
> > > > > configuration. Also, I don't know if the manager 
> should be based 
> > > > > on
> > > the
> > > > > component. I think it would be better to link it with 
> the data 
> > > > > model class, else using the same component with two different 
> > > > > model could lead to
> > a
> > > > > ClassCastException and/or incoherent attribute 
> values. At worst, 
> > > > > an
> > > AND
> > > > > link
> > > > > checking both the component and the data model could be used.
> > > > >
> > > > >
> > > > > Regards,
> > > > >
> > > > > ~ Simon
> > > > >
> > > > >
> > > > > --arjuna
> > > > > >
> > > > > > On 9/27/06, Simon Lessard <si...@gmail.com> wrote:
> > > > > > >
> > > > > > > I see it like that as well. Basically, during 
> rendering, the
> > child
> > > > > > > component
> > > > > > > properies would be altered as follow:
> > > > > > >
> > > > > > > 1. Check if the property was set explicitely by the 
> > > > > > > component
> > > (I'll
> > > > > have
> > > > > > > to
> > > > > > > check if there's an easy way to do that... I thought about
> > > checking
> > > > > for
> > > > > > a
> > > > > > > value binding but that's not exactly right, maybe the
> > FacesBean).
> > > If
> > > > > an
> > > > > > > explicit property was set, use it.
> > > > > > >
> > > > > > > 2. Check the current row data at current row key. If it
> > implements
> > > > > > > interface
> > > > > > > TrainStation (or any other name), save the 
> default attribute
> > > values
> > > > on
> > > > > > the
> > > > > > > stamp for the attribute the interface is 
> providing. Cast the 
> > > > > > > row
> > > > data
> > > > > > and
> > > > > > > extract the new attribute values and states.
> > > > > > >
> > > > > > > 3. Nothing was mentionned by the user, so apply default 
> > > > > > > behavior
> > > > > > (visited
> > > > > > > before focus, and so on).
> > > > > > >
> > > > > > >
> > > > > > > We could keep commandNavigationItem to implement that.
> > > > > > >
> > > > > > > ~ Simon
> > > > > > >
> > > > > > > On 9/27/06, Adam Winer <aw...@gmail.com> wrote:
> > > > > > > >
> > > > > > > > On 9/26/06, Pavitra Subramaniam <
> > pavitra.subramaniam@oracle.com>
> > > > > > wrote:
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > <tr:train value="#{trainModel}" var="row">
> > > > > > > > >   <tr:stop text="#{row.label}"
> > > > > > > > >            action="#{row.outcome}"
> > > > > > > > >            immediate="#{row.immediate}"
> > > > > > > > >            readOnly="#{row.readOnly}"
> > > > > > > > >            visited="#{row.visited}"
> > > > > > > > >            selected="#{row.selected}"
> > > > > > > > >            disabled="#{row.disabled}"/> </tr:train>
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > So how is this better than the existing 
> > > > > > > > <af:commandMenuItem>?  Seems like the same 
> amount of code.
> > > > > > > >
> > > > > > > > I was imagining an intermediate step, where 
> *if* the model 
> > > > > > > > points at instances of a specific model type, 
> and you use 
> > > > > > > > a simple template-ish tag, then you don't have 
> to set any 
> > > > > > > > EL, so just:
> > > > > > > >
> > > > > > > > <tr:train value="#{trainModel}" var="row">
> > > > > > > >   <tr:trainStop/>
> > > > > > > > </tr:train>
> > > > > > > >
> > > > > > > > -- Adam
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
> 
> 
> 

Re: [Proposal] ProcessModel changes

[Simon Lessard <si...@gmail.com>]

It happen in the process train renderer. The commandNavigationItem does not
need to know who is rendering him. The best example is really how to
determine if a station/step/stop was already visited or not. Since the model
does not provide such information, the renderer has to infer them.

On 9/27/06, Arjuna Wijeyekoon <ar...@gmail.com> wrote:
>
> >
> > > Adding a new model to your system will requires additional
> > > > configuration.
> > >
> > >
> > > IMO, small price to pay to avoid having to force all models to
> implement
> > > TrainStation (or some other API).
> >
> >
> > It was not forcing though.
>
>
> understood. it is not forcing if the page author is going to bind each
> individual attribute by hand.
> But it is forcing if the page author wants to auto bind.
>
>
>
>
> > > 1. does not involve new tags.
> > > >
> > > >
> > > > Row data interfaces does that
> > > >
> > > > 2. can be retrofitted into existing tags without having to change
> each
> > > and
> > > > > every tag implementation.
> > > >
> > > >
> > > > Idem
> > > >
> > >
> > > If I want to support outputText as well as commandNavigationItem,
> don't
> > I
> > > need to modify both those components?
> >
> >
> > Your solution requires to add an autoBind attribute  to all those
> > components.
>
>
> however, the change will happen up in UIXComponentBase so child component
> classes will be untouched.
>
> Interfaces on row data have nothing to do with the child
> > component being used for purpose of states (visited, unvisited, etc. in
> > case
> > of proces train).
>
>
> I don;t think I understand. Something needs to test and cast the rowdata
> to
> a TrainStation.
> where does that happen?  Doesn't it happen inside the
> CommandNavigationItem
> or corresponding renderer?
>
> --arjuna
>
> However it would indeed requires some changes for
> > UIComponent attribute autobinding.
> >
>
>
> On 9/27/06, Simon Lessard <si...@gmail.com> wrote:
> >
> > Hello Arjuna,
> >
> >
> > On 9/27/06, Arjuna Wijeyekoon <ar...@gmail.com> wrote:
> > >
> > > Hi Simon,
> > > thanks for your reply.
> > >
> > > Could be splitted in more than one interface
> > > >
> > >
> > > Well then you could have an explosion of interfaces. My point was not
> to
> > > have separate interfaces for each concept.
> > > I just wanted it to be flexible so that different people could provide
> > the
> > > implementations for the different concepts.
> > > So person A (non JSF guy) provides the native model.
> > > Person B (JSF guy) provides the AutoBindManager that knows how to pull
> > > properties from the model for various components.
> >
> >
> > True
> >
> > > Adding a new model to your system will requires additional
> > > > configuration.
> > >
> > >
> > > IMO, small price to pay to avoid having to force all models to
> implement
> > > TrainStation (or some other API).
> >
> >
> > It was not forcing though.
> >
> > > 1. does not involve new tags.
> > > >
> > > >
> > > > Row data interfaces does that
> > > >
> > > > 2. can be retrofitted into existing tags without having to change
> each
> > > and
> > > > > every tag implementation.
> > > >
> > > >
> > > > Idem
> > > >
> > >
> > > If I want to support outputText as well as commandNavigationItem,
> don't
> > I
> > > need to modify both those components?
> >
> >
> > Your solution requires to add an autoBind attribute  to all those
> > components. Interfaces on row data have nothing to do with the child
> > component being used for purpose of states (visited, unvisited, etc. in
> > case
> > of proces train). However it would indeed requires some changes for
> > UIComponent attribute autobinding.
> >
> > Also, I don't know if the manager should be based on the
> > > > component. I think it would be better to link it with the data model
> > > > class,
> > > > else using the same component with two different model could lead to
> a
> > > > ClassCastException and/or incoherent attribute values. At worst, an
> > AND
> > > > link
> > > > checking both the component and the data model could be used.
> > >
> > >
> > > That is what I meant.  The manager would be referenced by both
> component
> > > class and data model class.
> > > public static AutoBindManager getManager(Class componentClass, Class
> > > dataModelClass)
> >
> >
> > It works,  however, since some state attributes cannot be found on the
> > chlid
> > component there's still two choices. Either add all the needed
> attributes
> > to
> > the component, or support both ideas. That is row data interface for
> state
> > if you want to overload the default behavior and autobinding for
> component
> > attributes. The latter is getting quite complex though.
> >
> >
> > Regards,
> >
> > ~ Simon
> >
> > --arjuna
> > >
> > >
> > > On 9/27/06, Simon Lessard <si...@gmail.com> wrote:
> > > >
> > > > Added some comments inline
> > > >
> > > > On 9/27/06, Arjuna Wijeyekoon <ar...@gmail.com> wrote:
> > > > >
> > > > > Hi,
> > > > > So I feel a little unhappy with putting things like
> "label/readOnly"
> > > > > (which
> > > > > are UI properties),
> > > > > "visited/selected/disabled/outcome" (which is all navigation
> > related),
> > > > > and "immediate" (related to validation) all on a single interface.
> > > >
> > > >
> > > > Could be splitted in more than one interface
> > > >
> > > > I also feel like this solution solves a very specific problem -
> > > > > the new <tr:trainStop> only helps with commandNavigationItem).
> > Adding
> > > > new
> > > > > tags also bloats the number of tags in the framework.
> > > > >
> > > > > Also this forces MenuModel implementors to return objects of a
> > > specific
> > > > > type
> > > > > - so if they have a more comfortable native model,
> > > > > they are forced to return adaptor objects.
> > > >
> > > >
> > > > The interface would be optional, if present it takes effect,  else
> the
> > > > default behavior is used.
> > > >
> > > > I'd like to propose a more general solution to the problem of -
> > > > >
> > > > > > Some components (especially stamped components) need a lot of
> > > > > boiler-plate
> > > > > > code.
> > > > > >
> > > > > And I like to propose a solution that:
> > > > > 1. does not involve new tags.
> > > >
> > > >
> > > > Row data interfaces does that
> > > >
> > > > 2. can be retrofitted into existing tags without having to change
> each
> > > and
> > > > > every tag implementation.
> > > >
> > > >
> > > > Idem
> > > >
> > > > 3. works with any model, so that the model author can work with any
> > > model
> > > > > he/she is most comfortable with.
> > > >
> > > >
> > > > Semi idem
> > > >
> > > > 4. Easy to maintain - if someone wants to change the model later,
> > he/she
> > > > > should be able to make the change in one place and not
> > > > > have to touch a lot of files.
> > > > > 5. can be used with all components, eg: commandNavigationItem and
> > the
> > > > > menuModel.  nodeStamps in tree/treeTable.
> > > > > 6. Does not force UI properties and validation logic to all be on
> > the
> > > > same
> > > > > interface.
> > > >
> > > >
> > > > Using more than one interface solve that.
> > > >
> > > > So my thinking goes like this:
> > > > >
> > > > > Have an "autoBind" attribute on UIXComponentBase, so that a page
> > > author
> > > > > can
> > > > > write:
> > > > > <tr:train value="#{trainModel}" var="row">
> > > > > <tr:commandMenuItem  autoBind="#{row}"/>
> > > > > </tr:train>
> > > > >
> > > > >
> > > > > Have an interface called AutoBindManager:
> > > > > public Object getProperty(FacesContext,UIComponent comp, String
> > > > > attributeName, Object model)
> > > > >
> > > > > AutoBindManagers are registered in trinidad-config, and they are
> > > > > registered
> > > > > by two keys:
> > > > > the component class (eg: CoreCommandMenuItem, or UIXCommand)  and
> > > > > the model class  (eg: Simon's  Station.class)
> > > > >
> > > > > When asked for a property, UIXComponentBase (or FacesBeanImpl)
> will
> > > > first
> > > > > look to see if there is a property (or value-binding) set on the
> > > > > component directly. If not, it will see if there is an autoBinding
> > set
> > > > on
> > > > > the component.  If so it will look up the list of AutoBindManager
> > > sbased
> > > > > on
> > > > > the component and type of the autoBind object, and ask each
> manager
> > > for
> > > > > the
> > > > > property value, and stop when the first non-null property value is
> > > > found.
> > > > >
> > > > > This way you can have (if you wish) different AutoBindManagers for
> > > > > different
> > > > > concepts (like UI properties and validation logic).
> > > > >
> > > > > Does this make sense?
> > > > > What do you all think?
> > > >
> > > >
> > > > I like the idea. However, I don't know if it's a better solution on
> > the
> > > > usability side. Adding a new model to your system will requires
> > > additional
> > > > configuration. Also, I don't know if the manager should be based on
> > the
> > > > component. I think it would be better to link it with the data model
> > > > class,
> > > > else using the same component with two different model could lead to
> a
> > > > ClassCastException and/or incoherent attribute values. At worst, an
> > AND
> > > > link
> > > > checking both the component and the data model could be used.
> > > >
> > > >
> > > > Regards,
> > > >
> > > > ~ Simon
> > > >
> > > >
> > > > --arjuna
> > > > >
> > > > > On 9/27/06, Simon Lessard <si...@gmail.com> wrote:
> > > > > >
> > > > > > I see it like that as well. Basically, during rendering, the
> child
> > > > > > component
> > > > > > properies would be altered as follow:
> > > > > >
> > > > > > 1. Check if the property was set explicitely by the component
> > (I'll
> > > > have
> > > > > > to
> > > > > > check if there's an easy way to do that... I thought about
> > checking
> > > > for
> > > > > a
> > > > > > value binding but that's not exactly right, maybe the
> FacesBean).
> > If
> > > > an
> > > > > > explicit property was set, use it.
> > > > > >
> > > > > > 2. Check the current row data at current row key. If it
> implements
> > > > > > interface
> > > > > > TrainStation (or any other name), save the default attribute
> > values
> > > on
> > > > > the
> > > > > > stamp for the attribute the interface is providing. Cast the row
> > > data
> > > > > and
> > > > > > extract the new attribute values and states.
> > > > > >
> > > > > > 3. Nothing was mentionned by the user, so apply default behavior
> > > > > (visited
> > > > > > before focus, and so on).
> > > > > >
> > > > > >
> > > > > > We could keep commandNavigationItem to implement that.
> > > > > >
> > > > > > ~ Simon
> > > > > >
> > > > > > On 9/27/06, Adam Winer <aw...@gmail.com> wrote:
> > > > > > >
> > > > > > > On 9/26/06, Pavitra Subramaniam <
> pavitra.subramaniam@oracle.com>
> > > > > wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > > <tr:train value="#{trainModel}" var="row">
> > > > > > > >   <tr:stop text="#{row.label}"
> > > > > > > >            action="#{row.outcome}"
> > > > > > > >            immediate="#{row.immediate}"
> > > > > > > >            readOnly="#{row.readOnly}"
> > > > > > > >            visited="#{row.visited}"
> > > > > > > >            selected="#{row.selected}"
> > > > > > > >            disabled="#{row.disabled}"/>
> > > > > > > > </tr:train>
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > So how is this better than the existing
> > > > > > > <af:commandMenuItem>?  Seems like the
> > > > > > > same amount of code.
> > > > > > >
> > > > > > > I was imagining an intermediate step, where *if*
> > > > > > > the model points at instances of a specific model
> > > > > > > type, and you use a simple template-ish tag, then you
> > > > > > > don't have to set any EL, so just:
> > > > > > >
> > > > > > > <tr:train value="#{trainModel}" var="row">
> > > > > > >   <tr:trainStop/>
> > > > > > > </tr:train>
> > > > > > >
> > > > > > > -- Adam
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>

Re: [Proposal] ProcessModel changes

[Arjuna Wijeyekoon <ar...@gmail.com>]

> 
> > Adding a new model to your system will requires additional
> > > configuration.
> >
> >
> > IMO, small price to pay to avoid having to force all models to implement
> > TrainStation (or some other API).
>
>
> It was not forcing though.


understood. it is not forcing if the page author is going to bind each
individual attribute by hand.
But it is forcing if the page author wants to auto bind.




> > 1. does not involve new tags.
> > >
> > >
> > > Row data interfaces does that
> > >
> > > 2. can be retrofitted into existing tags without having to change each
> > and
> > > > every tag implementation.
> > >
> > >
> > > Idem
> > >
> >
> > If I want to support outputText as well as commandNavigationItem, don't
> I
> > need to modify both those components?
>
>
> Your solution requires to add an autoBind attribute  to all those
> components.


however, the change will happen up in UIXComponentBase so child component
classes will be untouched.

Interfaces on row data have nothing to do with the child
> component being used for purpose of states (visited, unvisited, etc. in
> case
> of proces train).


I don;t think I understand. Something needs to test and cast the rowdata to
a TrainStation.
where does that happen?  Doesn't it happen inside the CommandNavigationItem
or corresponding renderer?

--arjuna

However it would indeed requires some changes for
> UIComponent attribute autobinding.
>


On 9/27/06, Simon Lessard <si...@gmail.com> wrote:
>
> Hello Arjuna,
>
>
> On 9/27/06, Arjuna Wijeyekoon <ar...@gmail.com> wrote:
> >
> > Hi Simon,
> > thanks for your reply.
> >
> > Could be splitted in more than one interface
> > >
> >
> > Well then you could have an explosion of interfaces. My point was not to
> > have separate interfaces for each concept.
> > I just wanted it to be flexible so that different people could provide
> the
> > implementations for the different concepts.
> > So person A (non JSF guy) provides the native model.
> > Person B (JSF guy) provides the AutoBindManager that knows how to pull
> > properties from the model for various components.
>
>
> True
>
> > Adding a new model to your system will requires additional
> > > configuration.
> >
> >
> > IMO, small price to pay to avoid having to force all models to implement
> > TrainStation (or some other API).
>
>
> It was not forcing though.
>
> > 1. does not involve new tags.
> > >
> > >
> > > Row data interfaces does that
> > >
> > > 2. can be retrofitted into existing tags without having to change each
> > and
> > > > every tag implementation.
> > >
> > >
> > > Idem
> > >
> >
> > If I want to support outputText as well as commandNavigationItem, don't
> I
> > need to modify both those components?
>
>
> Your solution requires to add an autoBind attribute  to all those
> components. Interfaces on row data have nothing to do with the child
> component being used for purpose of states (visited, unvisited, etc. in
> case
> of proces train). However it would indeed requires some changes for
> UIComponent attribute autobinding.
>
> Also, I don't know if the manager should be based on the
> > > component. I think it would be better to link it with the data model
> > > class,
> > > else using the same component with two different model could lead to a
> > > ClassCastException and/or incoherent attribute values. At worst, an
> AND
> > > link
> > > checking both the component and the data model could be used.
> >
> >
> > That is what I meant.  The manager would be referenced by both component
> > class and data model class.
> > public static AutoBindManager getManager(Class componentClass, Class
> > dataModelClass)
>
>
> It works,  however, since some state attributes cannot be found on the
> chlid
> component there's still two choices. Either add all the needed attributes
> to
> the component, or support both ideas. That is row data interface for state
> if you want to overload the default behavior and autobinding for component
> attributes. The latter is getting quite complex though.
>
>
> Regards,
>
> ~ Simon
>
> --arjuna
> >
> >
> > On 9/27/06, Simon Lessard <si...@gmail.com> wrote:
> > >
> > > Added some comments inline
> > >
> > > On 9/27/06, Arjuna Wijeyekoon <ar...@gmail.com> wrote:
> > > >
> > > > Hi,
> > > > So I feel a little unhappy with putting things like "label/readOnly"
> > > > (which
> > > > are UI properties),
> > > > "visited/selected/disabled/outcome" (which is all navigation
> related),
> > > > and "immediate" (related to validation) all on a single interface.
> > >
> > >
> > > Could be splitted in more than one interface
> > >
> > > I also feel like this solution solves a very specific problem -
> > > > the new <tr:trainStop> only helps with commandNavigationItem).
> Adding
> > > new
> > > > tags also bloats the number of tags in the framework.
> > > >
> > > > Also this forces MenuModel implementors to return objects of a
> > specific
> > > > type
> > > > - so if they have a more comfortable native model,
> > > > they are forced to return adaptor objects.
> > >
> > >
> > > The interface would be optional, if present it takes effect,  else the
> > > default behavior is used.
> > >
> > > I'd like to propose a more general solution to the problem of -
> > > >
> > > > > Some components (especially stamped components) need a lot of
> > > > boiler-plate
> > > > > code.
> > > > >
> > > > And I like to propose a solution that:
> > > > 1. does not involve new tags.
> > >
> > >
> > > Row data interfaces does that
> > >
> > > 2. can be retrofitted into existing tags without having to change each
> > and
> > > > every tag implementation.
> > >
> > >
> > > Idem
> > >
> > > 3. works with any model, so that the model author can work with any
> > model
> > > > he/she is most comfortable with.
> > >
> > >
> > > Semi idem
> > >
> > > 4. Easy to maintain - if someone wants to change the model later,
> he/she
> > > > should be able to make the change in one place and not
> > > > have to touch a lot of files.
> > > > 5. can be used with all components, eg: commandNavigationItem and
> the
> > > > menuModel.  nodeStamps in tree/treeTable.
> > > > 6. Does not force UI properties and validation logic to all be on
> the
> > > same
> > > > interface.
> > >
> > >
> > > Using more than one interface solve that.
> > >
> > > So my thinking goes like this:
> > > >
> > > > Have an "autoBind" attribute on UIXComponentBase, so that a page
> > author
> > > > can
> > > > write:
> > > > <tr:train value="#{trainModel}" var="row">
> > > > <tr:commandMenuItem  autoBind="#{row}"/>
> > > > </tr:train>
> > > >
> > > >
> > > > Have an interface called AutoBindManager:
> > > > public Object getProperty(FacesContext,UIComponent comp, String
> > > > attributeName, Object model)
> > > >
> > > > AutoBindManagers are registered in trinidad-config, and they are
> > > > registered
> > > > by two keys:
> > > > the component class (eg: CoreCommandMenuItem, or UIXCommand)  and
> > > > the model class  (eg: Simon's  Station.class)
> > > >
> > > > When asked for a property, UIXComponentBase (or FacesBeanImpl) will
> > > first
> > > > look to see if there is a property (or value-binding) set on the
> > > > component directly. If not, it will see if there is an autoBinding
> set
> > > on
> > > > the component.  If so it will look up the list of AutoBindManager
> > sbased
> > > > on
> > > > the component and type of the autoBind object, and ask each manager
> > for
> > > > the
> > > > property value, and stop when the first non-null property value is
> > > found.
> > > >
> > > > This way you can have (if you wish) different AutoBindManagers for
> > > > different
> > > > concepts (like UI properties and validation logic).
> > > >
> > > > Does this make sense?
> > > > What do you all think?
> > >
> > >
> > > I like the idea. However, I don't know if it's a better solution on
> the
> > > usability side. Adding a new model to your system will requires
> > additional
> > > configuration. Also, I don't know if the manager should be based on
> the
> > > component. I think it would be better to link it with the data model
> > > class,
> > > else using the same component with two different model could lead to a
> > > ClassCastException and/or incoherent attribute values. At worst, an
> AND
> > > link
> > > checking both the component and the data model could be used.
> > >
> > >
> > > Regards,
> > >
> > > ~ Simon
> > >
> > >
> > > --arjuna
> > > >
> > > > On 9/27/06, Simon Lessard <si...@gmail.com> wrote:
> > > > >
> > > > > I see it like that as well. Basically, during rendering, the child
> > > > > component
> > > > > properies would be altered as follow:
> > > > >
> > > > > 1. Check if the property was set explicitely by the component
> (I'll
> > > have
> > > > > to
> > > > > check if there's an easy way to do that... I thought about
> checking
> > > for
> > > > a
> > > > > value binding but that's not exactly right, maybe the FacesBean).
> If
> > > an
> > > > > explicit property was set, use it.
> > > > >
> > > > > 2. Check the current row data at current row key. If it implements
> > > > > interface
> > > > > TrainStation (or any other name), save the default attribute
> values
> > on
> > > > the
> > > > > stamp for the attribute the interface is providing. Cast the row
> > data
> > > > and
> > > > > extract the new attribute values and states.
> > > > >
> > > > > 3. Nothing was mentionned by the user, so apply default behavior
> > > > (visited
> > > > > before focus, and so on).
> > > > >
> > > > >
> > > > > We could keep commandNavigationItem to implement that.
> > > > >
> > > > > ~ Simon
> > > > >
> > > > > On 9/27/06, Adam Winer <aw...@gmail.com> wrote:
> > > > > >
> > > > > > On 9/26/06, Pavitra Subramaniam <pa...@oracle.com>
> > > > wrote:
> > > > > > >
> > > > > > >
> > > > > > > <tr:train value="#{trainModel}" var="row">
> > > > > > >   <tr:stop text="#{row.label}"
> > > > > > >            action="#{row.outcome}"
> > > > > > >            immediate="#{row.immediate}"
> > > > > > >            readOnly="#{row.readOnly}"
> > > > > > >            visited="#{row.visited}"
> > > > > > >            selected="#{row.selected}"
> > > > > > >            disabled="#{row.disabled}"/>
> > > > > > > </tr:train>
> > > > > >
> > > > > >
> > > > > >
> > > > > > So how is this better than the existing
> > > > > > <af:commandMenuItem>?  Seems like the
> > > > > > same amount of code.
> > > > > >
> > > > > > I was imagining an intermediate step, where *if*
> > > > > > the model points at instances of a specific model
> > > > > > type, and you use a simple template-ish tag, then you
> > > > > > don't have to set any EL, so just:
> > > > > >
> > > > > > <tr:train value="#{trainModel}" var="row">
> > > > > >   <tr:trainStop/>
> > > > > > </tr:train>
> > > > > >
> > > > > > -- Adam
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>

Re: [Proposal] ProcessModel changes

[Simon Lessard <si...@gmail.com>]

Hello Arjuna,


On 9/27/06, Arjuna Wijeyekoon <ar...@gmail.com> wrote:
>
> Hi Simon,
> thanks for your reply.
>
> Could be splitted in more than one interface
> >
>
> Well then you could have an explosion of interfaces. My point was not to
> have separate interfaces for each concept.
> I just wanted it to be flexible so that different people could provide the
> implementations for the different concepts.
> So person A (non JSF guy) provides the native model.
> Person B (JSF guy) provides the AutoBindManager that knows how to pull
> properties from the model for various components.


True

> Adding a new model to your system will requires additional
> > configuration.
>
>
> IMO, small price to pay to avoid having to force all models to implement
> TrainStation (or some other API).


It was not forcing though.

> 1. does not involve new tags.
> >
> >
> > Row data interfaces does that
> >
> > 2. can be retrofitted into existing tags without having to change each
> and
> > > every tag implementation.
> >
> >
> > Idem
> >
>
> If I want to support outputText as well as commandNavigationItem, don't I
> need to modify both those components?


Your solution requires to add an autoBind attribute  to all those
components. Interfaces on row data have nothing to do with the child
component being used for purpose of states (visited, unvisited, etc. in case
of proces train). However it would indeed requires some changes for
UIComponent attribute autobinding.

Also, I don't know if the manager should be based on the
> > component. I think it would be better to link it with the data model
> > class,
> > else using the same component with two different model could lead to a
> > ClassCastException and/or incoherent attribute values. At worst, an AND
> > link
> > checking both the component and the data model could be used.
>
>
> That is what I meant.  The manager would be referenced by both component
> class and data model class.
> public static AutoBindManager getManager(Class componentClass, Class
> dataModelClass)


It works,  however, since some state attributes cannot be found on the chlid
component there's still two choices. Either add all the needed attributes to
the component, or support both ideas. That is row data interface for state
if you want to overload the default behavior and autobinding for component
attributes. The latter is getting quite complex though.


Regards,

~ Simon

--arjuna
>
>
> On 9/27/06, Simon Lessard <si...@gmail.com> wrote:
> >
> > Added some comments inline
> >
> > On 9/27/06, Arjuna Wijeyekoon <ar...@gmail.com> wrote:
> > >
> > > Hi,
> > > So I feel a little unhappy with putting things like "label/readOnly"
> > > (which
> > > are UI properties),
> > > "visited/selected/disabled/outcome" (which is all navigation related),
> > > and "immediate" (related to validation) all on a single interface.
> >
> >
> > Could be splitted in more than one interface
> >
> > I also feel like this solution solves a very specific problem -
> > > the new <tr:trainStop> only helps with commandNavigationItem). Adding
> > new
> > > tags also bloats the number of tags in the framework.
> > >
> > > Also this forces MenuModel implementors to return objects of a
> specific
> > > type
> > > - so if they have a more comfortable native model,
> > > they are forced to return adaptor objects.
> >
> >
> > The interface would be optional, if present it takes effect,  else the
> > default behavior is used.
> >
> > I'd like to propose a more general solution to the problem of -
> > >
> > > > Some components (especially stamped components) need a lot of
> > > boiler-plate
> > > > code.
> > > >
> > > And I like to propose a solution that:
> > > 1. does not involve new tags.
> >
> >
> > Row data interfaces does that
> >
> > 2. can be retrofitted into existing tags without having to change each
> and
> > > every tag implementation.
> >
> >
> > Idem
> >
> > 3. works with any model, so that the model author can work with any
> model
> > > he/she is most comfortable with.
> >
> >
> > Semi idem
> >
> > 4. Easy to maintain - if someone wants to change the model later, he/she
> > > should be able to make the change in one place and not
> > > have to touch a lot of files.
> > > 5. can be used with all components, eg: commandNavigationItem and the
> > > menuModel.  nodeStamps in tree/treeTable.
> > > 6. Does not force UI properties and validation logic to all be on the
> > same
> > > interface.
> >
> >
> > Using more than one interface solve that.
> >
> > So my thinking goes like this:
> > >
> > > Have an "autoBind" attribute on UIXComponentBase, so that a page
> author
> > > can
> > > write:
> > > <tr:train value="#{trainModel}" var="row">
> > > <tr:commandMenuItem  autoBind="#{row}"/>
> > > </tr:train>
> > >
> > >
> > > Have an interface called AutoBindManager:
> > > public Object getProperty(FacesContext,UIComponent comp, String
> > > attributeName, Object model)
> > >
> > > AutoBindManagers are registered in trinidad-config, and they are
> > > registered
> > > by two keys:
> > > the component class (eg: CoreCommandMenuItem, or UIXCommand)  and
> > > the model class  (eg: Simon's  Station.class)
> > >
> > > When asked for a property, UIXComponentBase (or FacesBeanImpl) will
> > first
> > > look to see if there is a property (or value-binding) set on the
> > > component directly. If not, it will see if there is an autoBinding set
> > on
> > > the component.  If so it will look up the list of AutoBindManager
> sbased
> > > on
> > > the component and type of the autoBind object, and ask each manager
> for
> > > the
> > > property value, and stop when the first non-null property value is
> > found.
> > >
> > > This way you can have (if you wish) different AutoBindManagers for
> > > different
> > > concepts (like UI properties and validation logic).
> > >
> > > Does this make sense?
> > > What do you all think?
> >
> >
> > I like the idea. However, I don't know if it's a better solution on the
> > usability side. Adding a new model to your system will requires
> additional
> > configuration. Also, I don't know if the manager should be based on the
> > component. I think it would be better to link it with the data model
> > class,
> > else using the same component with two different model could lead to a
> > ClassCastException and/or incoherent attribute values. At worst, an AND
> > link
> > checking both the component and the data model could be used.
> >
> >
> > Regards,
> >
> > ~ Simon
> >
> >
> > --arjuna
> > >
> > > On 9/27/06, Simon Lessard <si...@gmail.com> wrote:
> > > >
> > > > I see it like that as well. Basically, during rendering, the child
> > > > component
> > > > properies would be altered as follow:
> > > >
> > > > 1. Check if the property was set explicitely by the component (I'll
> > have
> > > > to
> > > > check if there's an easy way to do that... I thought about checking
> > for
> > > a
> > > > value binding but that's not exactly right, maybe the FacesBean). If
> > an
> > > > explicit property was set, use it.
> > > >
> > > > 2. Check the current row data at current row key. If it implements
> > > > interface
> > > > TrainStation (or any other name), save the default attribute values
> on
> > > the
> > > > stamp for the attribute the interface is providing. Cast the row
> data
> > > and
> > > > extract the new attribute values and states.
> > > >
> > > > 3. Nothing was mentionned by the user, so apply default behavior
> > > (visited
> > > > before focus, and so on).
> > > >
> > > >
> > > > We could keep commandNavigationItem to implement that.
> > > >
> > > > ~ Simon
> > > >
> > > > On 9/27/06, Adam Winer <aw...@gmail.com> wrote:
> > > > >
> > > > > On 9/26/06, Pavitra Subramaniam <pa...@oracle.com>
> > > wrote:
> > > > > >
> > > > > >
> > > > > > <tr:train value="#{trainModel}" var="row">
> > > > > >   <tr:stop text="#{row.label}"
> > > > > >            action="#{row.outcome}"
> > > > > >            immediate="#{row.immediate}"
> > > > > >            readOnly="#{row.readOnly}"
> > > > > >            visited="#{row.visited}"
> > > > > >            selected="#{row.selected}"
> > > > > >            disabled="#{row.disabled}"/>
> > > > > > </tr:train>
> > > > >
> > > > >
> > > > >
> > > > > So how is this better than the existing
> > > > > <af:commandMenuItem>?  Seems like the
> > > > > same amount of code.
> > > > >
> > > > > I was imagining an intermediate step, where *if*
> > > > > the model points at instances of a specific model
> > > > > type, and you use a simple template-ish tag, then you
> > > > > don't have to set any EL, so just:
> > > > >
> > > > > <tr:train value="#{trainModel}" var="row">
> > > > >   <tr:trainStop/>
> > > > > </tr:train>
> > > > >
> > > > > -- Adam
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>

Re: [Proposal] ProcessModel changes

[Arjuna Wijeyekoon <ar...@gmail.com>]

Hi Simon,
thanks for your reply.

Could be splitted in more than one interface
>

Well then you could have an explosion of interfaces. My point was not to
have separate interfaces for each concept.
I just wanted it to be flexible so that different people could provide the
implementations for the different concepts.
So person A (non JSF guy) provides the native model.
Person B (JSF guy) provides the AutoBindManager that knows how to pull
properties from the model for various components.


> Adding a new model to your system will requires additional
> configuration.


IMO, small price to pay to avoid having to force all models to implement
TrainStation (or some other API).


> 1. does not involve new tags.
>
>
> Row data interfaces does that
>
> 2. can be retrofitted into existing tags without having to change each and
> > every tag implementation.
>
>
> Idem
>

If I want to support outputText as well as commandNavigationItem, don't I
need to modify both those components?


Also, I don't know if the manager should be based on the
> component. I think it would be better to link it with the data model
> class,
> else using the same component with two different model could lead to a
> ClassCastException and/or incoherent attribute values. At worst, an AND
> link
> checking both the component and the data model could be used.


That is what I meant.  The manager would be referenced by both component
class and data model class.
public static AutoBindManager getManager(Class componentClass, Class
dataModelClass)

--arjuna


On 9/27/06, Simon Lessard <si...@gmail.com> wrote:
>
> Added some comments inline
>
> On 9/27/06, Arjuna Wijeyekoon <ar...@gmail.com> wrote:
> >
> > Hi,
> > So I feel a little unhappy with putting things like "label/readOnly"
> > (which
> > are UI properties),
> > "visited/selected/disabled/outcome" (which is all navigation related),
> > and "immediate" (related to validation) all on a single interface.
>
>
> Could be splitted in more than one interface
>
> I also feel like this solution solves a very specific problem -
> > the new <tr:trainStop> only helps with commandNavigationItem). Adding
> new
> > tags also bloats the number of tags in the framework.
> >
> > Also this forces MenuModel implementors to return objects of a specific
> > type
> > - so if they have a more comfortable native model,
> > they are forced to return adaptor objects.
>
>
> The interface would be optional, if present it takes effect,  else the
> default behavior is used.
>
> I'd like to propose a more general solution to the problem of -
> >
> > > Some components (especially stamped components) need a lot of
> > boiler-plate
> > > code.
> > >
> > And I like to propose a solution that:
> > 1. does not involve new tags.
>
>
> Row data interfaces does that
>
> 2. can be retrofitted into existing tags without having to change each and
> > every tag implementation.
>
>
> Idem
>
> 3. works with any model, so that the model author can work with any model
> > he/she is most comfortable with.
>
>
> Semi idem
>
> 4. Easy to maintain - if someone wants to change the model later, he/she
> > should be able to make the change in one place and not
> > have to touch a lot of files.
> > 5. can be used with all components, eg: commandNavigationItem and the
> > menuModel.  nodeStamps in tree/treeTable.
> > 6. Does not force UI properties and validation logic to all be on the
> same
> > interface.
>
>
> Using more than one interface solve that.
>
> So my thinking goes like this:
> >
> > Have an "autoBind" attribute on UIXComponentBase, so that a page author
> > can
> > write:
> > <tr:train value="#{trainModel}" var="row">
> > <tr:commandMenuItem  autoBind="#{row}"/>
> > </tr:train>
> >
> >
> > Have an interface called AutoBindManager:
> > public Object getProperty(FacesContext,UIComponent comp, String
> > attributeName, Object model)
> >
> > AutoBindManagers are registered in trinidad-config, and they are
> > registered
> > by two keys:
> > the component class (eg: CoreCommandMenuItem, or UIXCommand)  and
> > the model class  (eg: Simon's  Station.class)
> >
> > When asked for a property, UIXComponentBase (or FacesBeanImpl) will
> first
> > look to see if there is a property (or value-binding) set on the
> > component directly. If not, it will see if there is an autoBinding set
> on
> > the component.  If so it will look up the list of AutoBindManager sbased
> > on
> > the component and type of the autoBind object, and ask each manager for
> > the
> > property value, and stop when the first non-null property value is
> found.
> >
> > This way you can have (if you wish) different AutoBindManagers for
> > different
> > concepts (like UI properties and validation logic).
> >
> > Does this make sense?
> > What do you all think?
>
>
> I like the idea. However, I don't know if it's a better solution on the
> usability side. Adding a new model to your system will requires additional
> configuration. Also, I don't know if the manager should be based on the
> component. I think it would be better to link it with the data model
> class,
> else using the same component with two different model could lead to a
> ClassCastException and/or incoherent attribute values. At worst, an AND
> link
> checking both the component and the data model could be used.
>
>
> Regards,
>
> ~ Simon
>
>
> --arjuna
> >
> > On 9/27/06, Simon Lessard <si...@gmail.com> wrote:
> > >
> > > I see it like that as well. Basically, during rendering, the child
> > > component
> > > properies would be altered as follow:
> > >
> > > 1. Check if the property was set explicitely by the component (I'll
> have
> > > to
> > > check if there's an easy way to do that... I thought about checking
> for
> > a
> > > value binding but that's not exactly right, maybe the FacesBean). If
> an
> > > explicit property was set, use it.
> > >
> > > 2. Check the current row data at current row key. If it implements
> > > interface
> > > TrainStation (or any other name), save the default attribute values on
> > the
> > > stamp for the attribute the interface is providing. Cast the row data
> > and
> > > extract the new attribute values and states.
> > >
> > > 3. Nothing was mentionned by the user, so apply default behavior
> > (visited
> > > before focus, and so on).
> > >
> > >
> > > We could keep commandNavigationItem to implement that.
> > >
> > > ~ Simon
> > >
> > > On 9/27/06, Adam Winer <aw...@gmail.com> wrote:
> > > >
> > > > On 9/26/06, Pavitra Subramaniam <pa...@oracle.com>
> > wrote:
> > > > >
> > > > >
> > > > > <tr:train value="#{trainModel}" var="row">
> > > > >   <tr:stop text="#{row.label}"
> > > > >            action="#{row.outcome}"
> > > > >            immediate="#{row.immediate}"
> > > > >            readOnly="#{row.readOnly}"
> > > > >            visited="#{row.visited}"
> > > > >            selected="#{row.selected}"
> > > > >            disabled="#{row.disabled}"/>
> > > > > </tr:train>
> > > >
> > > >
> > > >
> > > > So how is this better than the existing
> > > > <af:commandMenuItem>?  Seems like the
> > > > same amount of code.
> > > >
> > > > I was imagining an intermediate step, where *if*
> > > > the model points at instances of a specific model
> > > > type, and you use a simple template-ish tag, then you
> > > > don't have to set any EL, so just:
> > > >
> > > > <tr:train value="#{trainModel}" var="row">
> > > >   <tr:trainStop/>
> > > > </tr:train>
> > > >
> > > > -- Adam
> > > >
> > > >
> > >
> > >
> >
> >
>
>

Re: [Proposal] ProcessModel changes

[Simon Lessard <si...@gmail.com>]

Added some comments inline

On 9/27/06, Arjuna Wijeyekoon <ar...@gmail.com> wrote:
>
> Hi,
> So I feel a little unhappy with putting things like "label/readOnly"
> (which
> are UI properties),
> "visited/selected/disabled/outcome" (which is all navigation related),
> and "immediate" (related to validation) all on a single interface.


Could be splitted in more than one interface

I also feel like this solution solves a very specific problem -
> the new <tr:trainStop> only helps with commandNavigationItem). Adding new
> tags also bloats the number of tags in the framework.
>
> Also this forces MenuModel implementors to return objects of a specific
> type
> - so if they have a more comfortable native model,
> they are forced to return adaptor objects.


The interface would be optional, if present it takes effect,  else the
default behavior is used.

I'd like to propose a more general solution to the problem of -
>
> > Some components (especially stamped components) need a lot of
> boiler-plate
> > code.
> >
> And I like to propose a solution that:
> 1. does not involve new tags.


Row data interfaces does that

2. can be retrofitted into existing tags without having to change each and
> every tag implementation.


Idem

3. works with any model, so that the model author can work with any model
> he/she is most comfortable with.


Semi idem

4. Easy to maintain - if someone wants to change the model later, he/she
> should be able to make the change in one place and not
> have to touch a lot of files.
> 5. can be used with all components, eg: commandNavigationItem and the
> menuModel.  nodeStamps in tree/treeTable.
> 6. Does not force UI properties and validation logic to all be on the same
> interface.


Using more than one interface solve that.

So my thinking goes like this:
>
> Have an "autoBind" attribute on UIXComponentBase, so that a page author
> can
> write:
> <tr:train value="#{trainModel}" var="row">
> <tr:commandMenuItem  autoBind="#{row}"/>
> </tr:train>
>
>
> Have an interface called AutoBindManager:
> public Object getProperty(FacesContext,UIComponent comp, String
> attributeName, Object model)
>
> AutoBindManagers are registered in trinidad-config, and they are
> registered
> by two keys:
> the component class (eg: CoreCommandMenuItem, or UIXCommand)  and
> the model class  (eg: Simon's  Station.class)
>
> When asked for a property, UIXComponentBase (or FacesBeanImpl) will first
> look to see if there is a property (or value-binding) set on the
> component directly. If not, it will see if there is an autoBinding set on
> the component.  If so it will look up the list of AutoBindManager sbased
> on
> the component and type of the autoBind object, and ask each manager for
> the
> property value, and stop when the first non-null property value is found.
>
> This way you can have (if you wish) different AutoBindManagers for
> different
> concepts (like UI properties and validation logic).
>
> Does this make sense?
> What do you all think?


I like the idea. However, I don't know if it's a better solution on the
usability side. Adding a new model to your system will requires additional
configuration. Also, I don't know if the manager should be based on the
component. I think it would be better to link it with the data model class,
else using the same component with two different model could lead to a
ClassCastException and/or incoherent attribute values. At worst, an AND link
checking both the component and the data model could be used.


Regards,

~ Simon


--arjuna
>
> On 9/27/06, Simon Lessard <si...@gmail.com> wrote:
> >
> > I see it like that as well. Basically, during rendering, the child
> > component
> > properies would be altered as follow:
> >
> > 1. Check if the property was set explicitely by the component (I'll have
> > to
> > check if there's an easy way to do that... I thought about checking for
> a
> > value binding but that's not exactly right, maybe the FacesBean). If an
> > explicit property was set, use it.
> >
> > 2. Check the current row data at current row key. If it implements
> > interface
> > TrainStation (or any other name), save the default attribute values on
> the
> > stamp for the attribute the interface is providing. Cast the row data
> and
> > extract the new attribute values and states.
> >
> > 3. Nothing was mentionned by the user, so apply default behavior
> (visited
> > before focus, and so on).
> >
> >
> > We could keep commandNavigationItem to implement that.
> >
> > ~ Simon
> >
> > On 9/27/06, Adam Winer <aw...@gmail.com> wrote:
> > >
> > > On 9/26/06, Pavitra Subramaniam <pa...@oracle.com>
> wrote:
> > > >
> > > >
> > > > <tr:train value="#{trainModel}" var="row">
> > > >   <tr:stop text="#{row.label}"
> > > >            action="#{row.outcome}"
> > > >            immediate="#{row.immediate}"
> > > >            readOnly="#{row.readOnly}"
> > > >            visited="#{row.visited}"
> > > >            selected="#{row.selected}"
> > > >            disabled="#{row.disabled}"/>
> > > > </tr:train>
> > >
> > >
> > >
> > > So how is this better than the existing
> > > <af:commandMenuItem>?  Seems like the
> > > same amount of code.
> > >
> > > I was imagining an intermediate step, where *if*
> > > the model points at instances of a specific model
> > > type, and you use a simple template-ish tag, then you
> > > don't have to set any EL, so just:
> > >
> > > <tr:train value="#{trainModel}" var="row">
> > >   <tr:trainStop/>
> > > </tr:train>
> > >
> > > -- Adam
> > >
> > >
> >
> >
>
>

Re: [Proposal] ProcessModel changes

[Arjuna Wijeyekoon <ar...@gmail.com>]

Hi,
So I feel a little unhappy with putting things like "label/readOnly" (which
are UI properties),
"visited/selected/disabled/outcome" (which is all navigation related),
and "immediate" (related to validation) all on a single interface.

I also feel like this solution solves a very specific problem -
the new <tr:trainStop> only helps with commandNavigationItem). Adding new
tags also bloats the number of tags in the framework.

Also this forces MenuModel implementors to return objects of a specific type
- so if they have a more comfortable native model,
they are forced to return adaptor objects.

I'd like to propose a more general solution to the problem of -

> Some components (especially stamped components) need a lot of boiler-plate
> code.
>
And I like to propose a solution that:
1. does not involve new tags.
2. can be retrofitted into existing tags without having to change each and
every tag implementation.
3. works with any model, so that the model author can work with any model
he/she is most comfortable with.
4. Easy to maintain - if someone wants to change the model later, he/she
should be able to make the change in one place and not
have to touch a lot of files.
5. can be used with all components, eg: commandNavigationItem and the
menuModel.  nodeStamps in tree/treeTable.
6. Does not force UI properties and validation logic to all be on the same
interface.



So my thinking goes like this:

Have an "autoBind" attribute on UIXComponentBase, so that a page author can
write:
<tr:train value="#{trainModel}" var="row">
 <tr:commandMenuItem  autoBind="#{row}"/>
</tr:train>


Have an interface called AutoBindManager:
public Object getProperty(FacesContext,UIComponent comp, String
attributeName, Object model)

AutoBindManagers are registered in trinidad-config, and they are registered
by two keys:
the component class (eg: CoreCommandMenuItem, or UIXCommand)  and
the model class  (eg: Simon's  Station.class)

When asked for a property, UIXComponentBase (or FacesBeanImpl) will first
look to see if there is a property (or value-binding) set on the
component directly. If not, it will see if there is an autoBinding set on
the component.  If so it will look up the list of AutoBindManager sbased on
the component and type of the autoBind object, and ask each manager for the
property value, and stop when the first non-null property value is found.

This way you can have (if you wish) different AutoBindManagers for different
concepts (like UI properties and validation logic).

Does this make sense?
What do you all think?
--arjuna

On 9/27/06, Simon Lessard <si...@gmail.com> wrote:
>
> I see it like that as well. Basically, during rendering, the child
> component
> properies would be altered as follow:
>
> 1. Check if the property was set explicitely by the component (I'll have
> to
> check if there's an easy way to do that... I thought about checking for a
> value binding but that's not exactly right, maybe the FacesBean). If an
> explicit property was set, use it.
>
> 2. Check the current row data at current row key. If it implements
> interface
> TrainStation (or any other name), save the default attribute values on the
> stamp for the attribute the interface is providing. Cast the row data and
> extract the new attribute values and states.
>
> 3. Nothing was mentionned by the user, so apply default behavior (visited
> before focus, and so on).
>
>
> We could keep commandNavigationItem to implement that.
>
> ~ Simon
>
> On 9/27/06, Adam Winer <aw...@gmail.com> wrote:
> >
> > On 9/26/06, Pavitra Subramaniam <pa...@oracle.com> wrote:
> > >
> > >
> > > <tr:train value="#{trainModel}" var="row">
> > >   <tr:stop text="#{row.label}"
> > >            action="#{row.outcome}"
> > >            immediate="#{row.immediate}"
> > >            readOnly="#{row.readOnly}"
> > >            visited="#{row.visited}"
> > >            selected="#{row.selected}"
> > >            disabled="#{row.disabled}"/>
> > > </tr:train>
> >
> >
> >
> > So how is this better than the existing
> > <af:commandMenuItem>?  Seems like the
> > same amount of code.
> >
> > I was imagining an intermediate step, where *if*
> > the model points at instances of a specific model
> > type, and you use a simple template-ish tag, then you
> > don't have to set any EL, so just:
> >
> > <tr:train value="#{trainModel}" var="row">
> >   <tr:trainStop/>
> > </tr:train>
> >
> > -- Adam
> >
> >
>
>

Re: [Proposal] ProcessModel changes

[Simon Lessard <si...@gmail.com>]

I see it like that as well. Basically, during rendering, the child component
properies would be altered as follow:

1. Check if the property was set explicitely by the component (I'll have to
check if there's an easy way to do that... I thought about checking for a
value binding but that's not exactly right, maybe the FacesBean). If an
explicit property was set, use it.

2. Check the current row data at current row key. If it implements interface
TrainStation (or any other name), save the default attribute values on the
stamp for the attribute the interface is providing. Cast the row data and
extract the new attribute values and states.

3. Nothing was mentionned by the user, so apply default behavior (visited
before focus, and so on).


We could keep commandNavigationItem to implement that.

~ Simon

On 9/27/06, Adam Winer <aw...@gmail.com> wrote:
>
> On 9/26/06, Pavitra Subramaniam <pa...@oracle.com> wrote:
> >
> >
> > <tr:train value="#{trainModel}" var="row">
> >   <tr:stop text="#{row.label}"
> >            action="#{row.outcome}"
> >            immediate="#{row.immediate}"
> >            readOnly="#{row.readOnly}"
> >            visited="#{row.visited}"
> >            selected="#{row.selected}"
> >            disabled="#{row.disabled}"/>
> > </tr:train>
>
>
>
> So how is this better than the existing
> <af:commandMenuItem>?  Seems like the
> same amount of code.
>
> I was imagining an intermediate step, where *if*
> the model points at instances of a specific model
> type, and you use a simple template-ish tag, then you
> don't have to set any EL, so just:
>
> <tr:train value="#{trainModel}" var="row">
>   <tr:trainStop/>
> </tr:train>
>
> -- Adam
>
>

Re: [Proposal] ProcessModel changes

[Adam Winer <aw...@gmail.com>]

On 9/26/06, Pavitra Subramaniam <pa...@oracle.com> wrote:
>
>
> <tr:train value="#{trainModel}" var="row">
>   <tr:stop text="#{row.label}"
>            action="#{row.outcome}"
>            immediate="#{row.immediate}"
>            readOnly="#{row.readOnly}"
>            visited="#{row.visited}"
>            selected="#{row.selected}"
>            disabled="#{row.disabled}"/>
> </tr:train>



So how is this better than the existing
<af:commandMenuItem>?  Seems like the
same amount of code.

I was imagining an intermediate step, where *if*
the model points at instances of a specific model
type, and you use a simple template-ish tag, then you
don't have to set any EL, so just:

<tr:train value="#{trainModel}" var="row">
  <tr:trainStop/>
</tr:train>

-- Adam

Re: [Proposal] ProcessModel changes

[Simon Lessard <si...@gmail.com>]

Alrighty,

I'll check both and try to come up with an interface suggestion for both
MenuModel and ProcessModel this weekened.


Regards,

~ Simon

On 9/25/06, Adam Winer <aw...@gmail.com> wrote:
>
> A row-data interface seems like a good way to go, though we should
> look at that in conjunction with the XMLMenuModel (reduce default
> binding in that case too).  Ideally, this could be baked in to
> our current command tag - if your model implements this API,
> we set up a bunch of things for you, unless you explicitly set them.
>
> -- Adam
>
>
> On 9/25/06, Simon Lessard <si...@gmail.com> wrote:
> >
> > A new specialised tag is a good idea. That way it still keep control in
> > the
> > jsf page. So we have two requisites:
> > 1. The new tag would simply have to support a state attribute allowing a
> > list of string (visited, unvisited, read-only, etc.)
> > 2. Reduce boilerplate attributes.
> >
> > Both of those seems opposed to each other though. What can be done about
> > 2?
> > Default values could be a way, but what would be those values? If not
> > forcing the model class, maybe we could force an interface on the row
> data
> > to fetch those default values?
> >
> >
> > Regards,
> >
> > ~ Simon
> >
> > On 9/24/06, Adam Winer <aw...@gmail.com> wrote:
> > >
> > > I think it might be useful to let users write
> > > very component-specific models, such that they
> > > can have more compact, more automatic pages.
> > >
> > > But, I'm uncomfortable with making this the
> > > required way to implement the page, 'cause
> > > it does push so much down into the model..  And,
> > > for example, the fact that Train doesn't support,
> > > for example, onclick on the stamp is basically
> > > just a bug - so would we add "getOnclick()" to
> > > the model (blech)?
> > >
> > > Also, doesn't the "action" EL really have to refer to
> > > a "var" on the component, since it's node-specific?
> > > If so, it starts getting weirder, because it's unusual
> > > to have a component where "var" affects attributes
> > > on itself - you can't call "getAction()", etc. without
> > > first setting up the current row on itself.
> > >
> > > And ya really need to add actionListener...  and
> > > make it into an ActionSource itself.
> > >
> > > So, I think I'm -1 on the idea of making it *so* compact,
> > > but I'd be really positive on the idea of finding someway
> > > to eliminate all that boilerplate EL, like maybe a tag
> > > that specializes commandMenuItem?
> > >
> > > -- Adam
> > >
> > >
> > > On 9/24/06, Simon Lessard <si...@gmail.com> wrote:
> > > >
> > > > Good morning everyone,
> > > >
> > > > While making the infamous train renderer, it was difficult to
> > determine
> > > if
> > > > a
> > > > step was visited or not. So, in the end, visited became "before
> > current
> > > > step" and unvisited "after current step". Also, most of the times,
> the
> > > > commandNavigationItem placed in the stamp has the same attribute
> > values,
> > > > all
> > > > linked to the model.
> > > >
> > > > Therefore, I was wondering if it would be acceptable to move all
> > > > attributes
> > > > to the ProcessModel class and remove the node stamp from process
> train
> > > > component. Using a processTrain would require only the following
> then:
> > > > <tr:train value="#{process.model}" action="#{process.onAction}" />.
> > > >
> > > > I place the action separated from the model because linking it
> > directly
> > > > would be against JSF soul imho. However, nothing would prevent the
> end
> > > > user
> > > > to place the action method directly on the model if he wanted with
> > that
> > > > method either. The only prerequisite is that the train renderer use
> a
> > > > setRowKey on the right step during processDecode, but it already
> does
> > > > that.
> > > >
> > > > I would use following signatures inside ProcessModel to support this
> > > > feature:
> > > >
> > > > public abstract class ProcessModel extends MenuModel
> > > > {
> > > >   /* Get the amount of of rendered stations in the process */
> > > >   public abstract ProcessModel.Train getTrain();
> > > >
> > > >   public abstract class Train
> > > >   {
> > > >     /* Get the rendered steps of the train*/
> > > >     public abstract Station getStations();
> > > >
> > > >     /* Determine if this train is the child of another */
> > > >     public abstract boolean isSubTrain();
> > > >   }
> > > >
> > > >   public abstract class Station
> > > >   {
> > > >     /* Get this step's label */
> > > >     public abstract String getLabel();
> > > >
> > > >     /* Get the rowKey for this station */
> > > >     public abstract Object getRowKey();
> > > >
> > > >     /* Determines if the link to this step is disabled*/
> > > >     public abstract boolean isDisabled();
> > > >
> > > >     /* Determines if the link to this step is immediate */
> > > >     public abstract boolean isImmediate();
> > > >
> > > >     /* Determines if the link to this step is read only */
> > > >     public abstract boolean isReadOnly();
> > > >
> > > >     /* Determines if the link to this step is the current one */
> > > >     public abstract boolean isSelected();
> > > >
> > > >     /* Determines if this station is visited */
> > > >     public abstract boolean isVisited();
> > > >   }
> > > > }
> > > >
> > > > At first, this may look like a decrease in the flexibility, but it's
> > > > actually improving it by giving the full power on the station's
> state
> > to
> > > > the
> > > > user, rather than having it deduced by the renderer in a hard coded
> > way.
> > > > The
> > > > only con I see is the inclusion of some view layer data in the
> model,
> > > > namely
> > > > label, immediate and readOnly.
> > > >
> > > > Anyone has a reason I didn't think about to veto that proposition?
> > > >
> > > >
> > > > Regards,
> > > >
> > > > ~ Simon
> > > >
> > > >
> > >
> > >
> >
> >
>
>

Re: [Proposal] ProcessModel changes

[Adam Winer <aw...@gmail.com>]

A row-data interface seems like a good way to go, though we should
look at that in conjunction with the XMLMenuModel (reduce default
binding in that case too).  Ideally, this could be baked in to
our current command tag - if your model implements this API,
we set up a bunch of things for you, unless you explicitly set them.

-- Adam


On 9/25/06, Simon Lessard <si...@gmail.com> wrote:
>
> A new specialised tag is a good idea. That way it still keep control in
> the
> jsf page. So we have two requisites:
> 1. The new tag would simply have to support a state attribute allowing a
> list of string (visited, unvisited, read-only, etc.)
> 2. Reduce boilerplate attributes.
>
> Both of those seems opposed to each other though. What can be done about
> 2?
> Default values could be a way, but what would be those values? If not
> forcing the model class, maybe we could force an interface on the row data
> to fetch those default values?
>
>
> Regards,
>
> ~ Simon
>
> On 9/24/06, Adam Winer <aw...@gmail.com> wrote:
> >
> > I think it might be useful to let users write
> > very component-specific models, such that they
> > can have more compact, more automatic pages.
> >
> > But, I'm uncomfortable with making this the
> > required way to implement the page, 'cause
> > it does push so much down into the model..  And,
> > for example, the fact that Train doesn't support,
> > for example, onclick on the stamp is basically
> > just a bug - so would we add "getOnclick()" to
> > the model (blech)?
> >
> > Also, doesn't the "action" EL really have to refer to
> > a "var" on the component, since it's node-specific?
> > If so, it starts getting weirder, because it's unusual
> > to have a component where "var" affects attributes
> > on itself - you can't call "getAction()", etc. without
> > first setting up the current row on itself.
> >
> > And ya really need to add actionListener...  and
> > make it into an ActionSource itself.
> >
> > So, I think I'm -1 on the idea of making it *so* compact,
> > but I'd be really positive on the idea of finding someway
> > to eliminate all that boilerplate EL, like maybe a tag
> > that specializes commandMenuItem?
> >
> > -- Adam
> >
> >
> > On 9/24/06, Simon Lessard <si...@gmail.com> wrote:
> > >
> > > Good morning everyone,
> > >
> > > While making the infamous train renderer, it was difficult to
> determine
> > if
> > > a
> > > step was visited or not. So, in the end, visited became "before
> current
> > > step" and unvisited "after current step". Also, most of the times, the
> > > commandNavigationItem placed in the stamp has the same attribute
> values,
> > > all
> > > linked to the model.
> > >
> > > Therefore, I was wondering if it would be acceptable to move all
> > > attributes
> > > to the ProcessModel class and remove the node stamp from process train
> > > component. Using a processTrain would require only the following then:
> > > <tr:train value="#{process.model}" action="#{process.onAction}" />.
> > >
> > > I place the action separated from the model because linking it
> directly
> > > would be against JSF soul imho. However, nothing would prevent the end
> > > user
> > > to place the action method directly on the model if he wanted with
> that
> > > method either. The only prerequisite is that the train renderer use a
> > > setRowKey on the right step during processDecode, but it already does
> > > that.
> > >
> > > I would use following signatures inside ProcessModel to support this
> > > feature:
> > >
> > > public abstract class ProcessModel extends MenuModel
> > > {
> > >   /* Get the amount of of rendered stations in the process */
> > >   public abstract ProcessModel.Train getTrain();
> > >
> > >   public abstract class Train
> > >   {
> > >     /* Get the rendered steps of the train*/
> > >     public abstract Station getStations();
> > >
> > >     /* Determine if this train is the child of another */
> > >     public abstract boolean isSubTrain();
> > >   }
> > >
> > >   public abstract class Station
> > >   {
> > >     /* Get this step's label */
> > >     public abstract String getLabel();
> > >
> > >     /* Get the rowKey for this station */
> > >     public abstract Object getRowKey();
> > >
> > >     /* Determines if the link to this step is disabled*/
> > >     public abstract boolean isDisabled();
> > >
> > >     /* Determines if the link to this step is immediate */
> > >     public abstract boolean isImmediate();
> > >
> > >     /* Determines if the link to this step is read only */
> > >     public abstract boolean isReadOnly();
> > >
> > >     /* Determines if the link to this step is the current one */
> > >     public abstract boolean isSelected();
> > >
> > >     /* Determines if this station is visited */
> > >     public abstract boolean isVisited();
> > >   }
> > > }
> > >
> > > At first, this may look like a decrease in the flexibility, but it's
> > > actually improving it by giving the full power on the station's state
> to
> > > the
> > > user, rather than having it deduced by the renderer in a hard coded
> way.
> > > The
> > > only con I see is the inclusion of some view layer data in the model,
> > > namely
> > > label, immediate and readOnly.
> > >
> > > Anyone has a reason I didn't think about to veto that proposition?
> > >
> > >
> > > Regards,
> > >
> > > ~ Simon
> > >
> > >
> >
> >
>
>

RE: [Proposal] ProcessModel changes

[Pavitra Subramaniam <pa...@oracle.com>]

I totally agree with Adam about not making it "compact". -1 for that.

Having a new child tag for a train node, that supports the various state attribute seems like a good idea. I am not sure how we could reduce the # of boilerplate attributes but we could certainly introduce a new interface between the component and the existing XmlMenuModel. 

If I were to do this from scratch, I would have an abstract class like "TrainModel", that has a hook to the underlying "data model" - XmlMenuModel for instance and hides it from the end-user. This way the user does not have to bother with UI ELs being pushed to the menuModel. 
Customers would extend TrainModel (see below) to support behaviors like MAX_VISITED, or PLUS_ONE. Simon mentioned in an earlier email that he had to support train behaviors like BACKTRACK, BACKTRACK_PLUS_NEXT, MAX_VISITED, MAX_VISITED_PLUS_NEXT, NEXT_ONLY, NO_NAVIGATION,  PREVIOUS,  PREVIOUS_PLUS_NEXT etc. Each implementation could have default values set for visited, read-only, disabled. 'Selected' obviously is determined by the focusRowKey in menuModel. 

This would cleanly separate the 'UI' artifacts from the model that sets up the data for the train (rowKey, label etc.). I am not sure if this is what Simon meant about a rowData interface. 

public abstract class TrainModel extends DataModel
{
  XmlMenuModel model; // Not sure if it's ok to hard-wire train to use XmlMenuModel, as train is not really a menu
                      // and it seems to be a constant source of confusion. 
  
  Stop getRowData(); // Internally it looks up the menuModel to get the next rowIndex and retrieve the data.
  
  public abstract class Stop 
  {
    String getLabel();
    String getOutcome();

    boolean isVisited(); 
    boolean isSelected();
    boolean isReadOnly();
    boolean isImmediate();
    boolean isDisabled();
  }
}

<tr:train value="#{trainModel}" var="row">
  <tr:stop text="#{row.label}" 
           action="#{row.outcome}"
           immediate="#{row.immediate}"
           readOnly="#{row.readOnly}"
           visited="#{row.visited}"         
           selected="#{row.selected}"
           disabled="#{row.disabled}"/>
</tr:train>

This is just an idea. 

- Pavitra
 

> -----Original Message-----
> From: Simon Lessard [mailto:simon.lessard.3@gmail.com] 
> Sent: Monday, September 25, 2006 6:30 AM
> To: adffaces-dev@incubator.apache.org
> Subject: Re: [Proposal] ProcessModel changes
> 
> A new specialised tag is a good idea. That way it still keep 
> control in the jsf page. So we have two requisites:
> 1. The new tag would simply have to support a state attribute 
> allowing a list of string (visited, unvisited, read-only, 
> etc.) 2. Reduce boilerplate attributes.
> 
> Both of those seems opposed to each other though. What can be 
> done about 2?
> Default values could be a way, but what would be those 
> values? If not forcing the model class, maybe we could force 
> an interface on the row data to fetch those default values?
> 
> 
> Regards,
> 
> ~ Simon
> 
> On 9/24/06, Adam Winer <aw...@gmail.com> wrote:
> >
> > I think it might be useful to let users write very 
> component-specific 
> > models, such that they can have more compact, more automatic pages.
> >
> > But, I'm uncomfortable with making this the required way to 
> implement 
> > the page, 'cause it does push so much down into the model.. 
>  And, for 
> > example, the fact that Train doesn't support, for example, 
> onclick on 
> > the stamp is basically just a bug - so would we add 
> "getOnclick()" to 
> > the model (blech)?
> >
> > Also, doesn't the "action" EL really have to refer to a 
> "var" on the 
> > component, since it's node-specific?
> > If so, it starts getting weirder, because it's unusual to have a 
> > component where "var" affects attributes on itself - you can't call 
> > "getAction()", etc. without first setting up the current row on 
> > itself.
> >
> > And ya really need to add actionListener...  and make it into an 
> > ActionSource itself.
> >
> > So, I think I'm -1 on the idea of making it *so* compact, 
> but I'd be 
> > really positive on the idea of finding someway to eliminate 
> all that 
> > boilerplate EL, like maybe a tag that specializes commandMenuItem?
> >
> > -- Adam
> >
> >
> > On 9/24/06, Simon Lessard <si...@gmail.com> wrote:
> > >
> > > Good morning everyone,
> > >
> > > While making the infamous train renderer, it was difficult to 
> > > determine
> > if
> > > a
> > > step was visited or not. So, in the end, visited became "before 
> > > current step" and unvisited "after current step". Also, 
> most of the 
> > > times, the commandNavigationItem placed in the stamp has the same 
> > > attribute values, all linked to the model.
> > >
> > > Therefore, I was wondering if it would be acceptable to move all 
> > > attributes to the ProcessModel class and remove the node 
> stamp from 
> > > process train component. Using a processTrain would 
> require only the 
> > > following then:
> > > <tr:train value="#{process.model}" 
> action="#{process.onAction}" />.
> > >
> > > I place the action separated from the model because linking it 
> > > directly would be against JSF soul imho. However, nothing would 
> > > prevent the end user to place the action method directly on the 
> > > model if he wanted with that method either. The only 
> prerequisite is 
> > > that the train renderer use a setRowKey on the right step during 
> > > processDecode, but it already does that.
> > >
> > > I would use following signatures inside ProcessModel to 
> support this
> > > feature:
> > >
> > > public abstract class ProcessModel extends MenuModel {
> > >   /* Get the amount of of rendered stations in the process */
> > >   public abstract ProcessModel.Train getTrain();
> > >
> > >   public abstract class Train
> > >   {
> > >     /* Get the rendered steps of the train*/
> > >     public abstract Station getStations();
> > >
> > >     /* Determine if this train is the child of another */
> > >     public abstract boolean isSubTrain();
> > >   }
> > >
> > >   public abstract class Station
> > >   {
> > >     /* Get this step's label */
> > >     public abstract String getLabel();
> > >
> > >     /* Get the rowKey for this station */
> > >     public abstract Object getRowKey();
> > >
> > >     /* Determines if the link to this step is disabled*/
> > >     public abstract boolean isDisabled();
> > >
> > >     /* Determines if the link to this step is immediate */
> > >     public abstract boolean isImmediate();
> > >
> > >     /* Determines if the link to this step is read only */
> > >     public abstract boolean isReadOnly();
> > >
> > >     /* Determines if the link to this step is the current one */
> > >     public abstract boolean isSelected();
> > >
> > >     /* Determines if this station is visited */
> > >     public abstract boolean isVisited();
> > >   }
> > > }
> > >
> > > At first, this may look like a decrease in the 
> flexibility, but it's 
> > > actually improving it by giving the full power on the station's 
> > > state to the user, rather than having it deduced by the 
> renderer in 
> > > a hard coded way.
> > > The
> > > only con I see is the inclusion of some view layer data in the 
> > > model, namely label, immediate and readOnly.
> > >
> > > Anyone has a reason I didn't think about to veto that proposition?
> > >
> > >
> > > Regards,
> > >
> > > ~ Simon
> > >
> > >
> >
> >
> 
> 
> 

Re: [Proposal] ProcessModel changes

[Simon Lessard <si...@gmail.com>]

A new specialised tag is a good idea. That way it still keep control in the
jsf page. So we have two requisites:
1. The new tag would simply have to support a state attribute allowing a
list of string (visited, unvisited, read-only, etc.)
2. Reduce boilerplate attributes.

Both of those seems opposed to each other though. What can be done about 2?
Default values could be a way, but what would be those values? If not
forcing the model class, maybe we could force an interface on the row data
to fetch those default values?


Regards,

~ Simon

On 9/24/06, Adam Winer <aw...@gmail.com> wrote:
>
> I think it might be useful to let users write
> very component-specific models, such that they
> can have more compact, more automatic pages.
>
> But, I'm uncomfortable with making this the
> required way to implement the page, 'cause
> it does push so much down into the model..  And,
> for example, the fact that Train doesn't support,
> for example, onclick on the stamp is basically
> just a bug - so would we add "getOnclick()" to
> the model (blech)?
>
> Also, doesn't the "action" EL really have to refer to
> a "var" on the component, since it's node-specific?
> If so, it starts getting weirder, because it's unusual
> to have a component where "var" affects attributes
> on itself - you can't call "getAction()", etc. without
> first setting up the current row on itself.
>
> And ya really need to add actionListener...  and
> make it into an ActionSource itself.
>
> So, I think I'm -1 on the idea of making it *so* compact,
> but I'd be really positive on the idea of finding someway
> to eliminate all that boilerplate EL, like maybe a tag
> that specializes commandMenuItem?
>
> -- Adam
>
>
> On 9/24/06, Simon Lessard <si...@gmail.com> wrote:
> >
> > Good morning everyone,
> >
> > While making the infamous train renderer, it was difficult to determine
> if
> > a
> > step was visited or not. So, in the end, visited became "before current
> > step" and unvisited "after current step". Also, most of the times, the
> > commandNavigationItem placed in the stamp has the same attribute values,
> > all
> > linked to the model.
> >
> > Therefore, I was wondering if it would be acceptable to move all
> > attributes
> > to the ProcessModel class and remove the node stamp from process train
> > component. Using a processTrain would require only the following then:
> > <tr:train value="#{process.model}" action="#{process.onAction}" />.
> >
> > I place the action separated from the model because linking it directly
> > would be against JSF soul imho. However, nothing would prevent the end
> > user
> > to place the action method directly on the model if he wanted with that
> > method either. The only prerequisite is that the train renderer use a
> > setRowKey on the right step during processDecode, but it already does
> > that.
> >
> > I would use following signatures inside ProcessModel to support this
> > feature:
> >
> > public abstract class ProcessModel extends MenuModel
> > {
> >   /* Get the amount of of rendered stations in the process */
> >   public abstract ProcessModel.Train getTrain();
> >
> >   public abstract class Train
> >   {
> >     /* Get the rendered steps of the train*/
> >     public abstract Station getStations();
> >
> >     /* Determine if this train is the child of another */
> >     public abstract boolean isSubTrain();
> >   }
> >
> >   public abstract class Station
> >   {
> >     /* Get this step's label */
> >     public abstract String getLabel();
> >
> >     /* Get the rowKey for this station */
> >     public abstract Object getRowKey();
> >
> >     /* Determines if the link to this step is disabled*/
> >     public abstract boolean isDisabled();
> >
> >     /* Determines if the link to this step is immediate */
> >     public abstract boolean isImmediate();
> >
> >     /* Determines if the link to this step is read only */
> >     public abstract boolean isReadOnly();
> >
> >     /* Determines if the link to this step is the current one */
> >     public abstract boolean isSelected();
> >
> >     /* Determines if this station is visited */
> >     public abstract boolean isVisited();
> >   }
> > }
> >
> > At first, this may look like a decrease in the flexibility, but it's
> > actually improving it by giving the full power on the station's state to
> > the
> > user, rather than having it deduced by the renderer in a hard coded way.
> > The
> > only con I see is the inclusion of some view layer data in the model,
> > namely
> > label, immediate and readOnly.
> >
> > Anyone has a reason I didn't think about to veto that proposition?
> >
> >
> > Regards,
> >
> > ~ Simon
> >
> >
>
>

Re: [Proposal] ProcessModel changes

[Adam Winer <aw...@gmail.com>]

I think it might be useful to let users write
very component-specific models, such that they
can have more compact, more automatic pages.

But, I'm uncomfortable with making this the
required way to implement the page, 'cause
it does push so much down into the model..  And,
for example, the fact that Train doesn't support,
for example, onclick on the stamp is basically
just a bug - so would we add "getOnclick()" to
the model (blech)?

Also, doesn't the "action" EL really have to refer to
a "var" on the component, since it's node-specific?
If so, it starts getting weirder, because it's unusual
to have a component where "var" affects attributes
on itself - you can't call "getAction()", etc. without
first setting up the current row on itself.

And ya really need to add actionListener...  and
make it into an ActionSource itself.

So, I think I'm -1 on the idea of making it *so* compact,
but I'd be really positive on the idea of finding someway
to eliminate all that boilerplate EL, like maybe a tag
that specializes commandMenuItem?

-- Adam


On 9/24/06, Simon Lessard <si...@gmail.com> wrote:
>
> Good morning everyone,
>
> While making the infamous train renderer, it was difficult to determine if
> a
> step was visited or not. So, in the end, visited became "before current
> step" and unvisited "after current step". Also, most of the times, the
> commandNavigationItem placed in the stamp has the same attribute values,
> all
> linked to the model.
>
> Therefore, I was wondering if it would be acceptable to move all
> attributes
> to the ProcessModel class and remove the node stamp from process train
> component. Using a processTrain would require only the following then:
> <tr:train value="#{process.model}" action="#{process.onAction}" />.
>
> I place the action separated from the model because linking it directly
> would be against JSF soul imho. However, nothing would prevent the end
> user
> to place the action method directly on the model if he wanted with that
> method either. The only prerequisite is that the train renderer use a
> setRowKey on the right step during processDecode, but it already does
> that.
>
> I would use following signatures inside ProcessModel to support this
> feature:
>
> public abstract class ProcessModel extends MenuModel
> {
>   /* Get the amount of of rendered stations in the process */
>   public abstract ProcessModel.Train getTrain();
>
>   public abstract class Train
>   {
>     /* Get the rendered steps of the train*/
>     public abstract Station getStations();
>
>     /* Determine if this train is the child of another */
>     public abstract boolean isSubTrain();
>   }
>
>   public abstract class Station
>   {
>     /* Get this step's label */
>     public abstract String getLabel();
>
>     /* Get the rowKey for this station */
>     public abstract Object getRowKey();
>
>     /* Determines if the link to this step is disabled*/
>     public abstract boolean isDisabled();
>
>     /* Determines if the link to this step is immediate */
>     public abstract boolean isImmediate();
>
>     /* Determines if the link to this step is read only */
>     public abstract boolean isReadOnly();
>
>     /* Determines if the link to this step is the current one */
>     public abstract boolean isSelected();
>
>     /* Determines if this station is visited */
>     public abstract boolean isVisited();
>   }
> }
>
> At first, this may look like a decrease in the flexibility, but it's
> actually improving it by giving the full power on the station's state to
> the
> user, rather than having it deduced by the renderer in a hard coded way.
> The
> only con I see is the inclusion of some view layer data in the model,
> namely
> label, immediate and readOnly.
>
> Anyone has a reason I didn't think about to veto that proposition?
>
>
> Regards,
>
> ~ Simon
>
>