>
> Will the unbound properties be "set" as well? (If I
have several unused
> parameters in a component)
No; unbound parameters will not be set, so they'll keep
whatever the default value is in the component class.
>
> 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.
I don't either. It would be good to resurrect some test
code I wrote and see how it plays in JDK 1.4.
Supposedly, reflection is now many times faster than in
1.3 and earlier.
I would like to compute the costs of the following:
1) Invoke a setter method as pure Java code
2) Invoke a setter method using reflection
3) Invoke a setter method using PropertyHelper
And see what the relative costs are. If I ever get some
free time (I'm still behind schedule at work and in
crunch mode, so its hard for me to get anything done for
Tapestry).
> "Howard
M.
> Lewis Ship" To:
Christian
>
Hall/Technology/Equifax@Equifax
> <hlship@attbi
cc: "Tapestry Developer"
> <tapestry-
[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
> >
>
>
>
--
[EMAIL PROTECTED]
http://tapestry.sf.net
>
> 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
_______________________________________________
Tapestry-developer mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/tapestry-developer
