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.
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).
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?
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)
--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
> > >
> > >
> >
> >
>
>
