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