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.

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.

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.
2. can be retrofitted into existing tags without having to change each and
every tag implementation.
3. works with any model, so that the model author can work with any model
he/she is most comfortable with.
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.



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


Reply via email to