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