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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote:
>
> Hello Arjuna,
>
>
> On 9/27/06, Arjuna Wijeyekoon <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote:
> > >
> > > Added some comments inline
> > >
> > > On 9/27/06, Arjuna Wijeyekoon <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote:
> > > > > >
> > > > > > On 9/26/06, Pavitra Subramaniam <
[EMAIL PROTECTED]>
> > > > 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
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
