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 <[EMAIL PROTECTED]> 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
