Will the unbound properties be "set" as well? (If I have several unused
parameters in a component)
Also, can someone give me an idea of the overhead paid for all the
reflection/introspection going on? I don't have a good grasp on where the
boundary between convenience and performance lies when it requires
reflection.
"Howard M.
Lewis Ship" To: Christian
Hall/Technology/Equifax@Equifax
<hlship@attbi cc: "Tapestry Developer"
<[EMAIL PROTECTED]>
.com> Subject: Re: [Tapestry-developer] Massive
change to parameters / bindings
04/26/2002
11:45 AM
>
> Just so I am clear, is this what you are saying?
>
> - For components one builds, each parameter must have a corresponding
> IBinding property
No, that's what were getting away from. Under the revised scheme, you
would
have a property that matches the name and **type** of the parameter. The
existence of the IBinding would be hidden from your code (with some
exceptions).
> - If "standard" (non-IBinding) properties are desired, provide such
> properties with same names as parameters, and Tapestry will populate them
> from the IBindings
A yes ... this is to be the standard case.
> - If you want to do something special with the input (examples might be
> useful here), you can just leave out the "standard" properties and
> de-reference the IBinding in renderComponent
Right; if you want more control, implement the parameter as it is done
today, by providing a fooBinding property, not a foo property. Or, for
less
efficiency, provide no property and invoke getBinding() instead.
> - If you want to provide output to parameters, this is done the same way
it
> is done now (using IBinding).
Yes. Thinking about the few places in Tapestry where output parameters are
used (Foreach, form elements), the component needs precise control over
when
the output parameter is set ... i.e., set it, then invoke the listener.
>
> Also, you said:
>
> "Rule #1 means all sorts of properties will be set."
That is, render() will invoke setter methods for all bindings that can be
mapped to parameters before invoking renderComponent(). The current system
allows the developer to be more frugal about which bindings are
dereferenced.
>
> Not sure what you meant here...just the properties that map to bindings,
> right?
Basically, each dynamic binding that can map to a JavaBean property of the
component will be set. Again, the current system allows the developer more
control.
>
> -C
>
_______________________________________________
Tapestry-developer mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/tapestry-developer
