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