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:[EMAIL PROTECTED]
> Sent: Monday, September 25, 2006 6:30 AM
> To: [email protected]
> 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 <[EMAIL PROTECTED]> 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 <[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
> > >
> > >
> >
> >
>
>
>
