> 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
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
