Hi Lance,
as far as I can see the public API was extended several times in the
past. A lot methods are marked as @since 5.2.
The only potential problem I see is in "Binding" since people might have
implemented their own. It's quite unlikely that someone has it's own
ComponentResources and such.
An alternative (especially for Binding) would be to create an Interface
"GenericsAwareBinding" that extends Binding with the new method.
Implementations could use the new Method if the binding is generic aware
and otherwise fall back to the old "getBindingType".
Maybe this can even be achieved using instrumentation magic (dynamically
add the method if it is missing and fall back to the non-generic)?
Theoretically it should be possible to have a worker which detect if
e.g. "Binding" is an interface but the new Method is missing.
I'm looking into TAP5-1213 to provide access to the bound property's
generic type information (eg List<SomeBean>). Basically the generic type
information needs to be passed from PropertyConduitSource to
ComponentResources
This change requires adding a generic type getter to a few public
interfaces, namely:
- org.apache.tapestry5.Binding
- org.apache.tapestry5.ComponentResources
- org.apache.tapestry5.PropertyConduit
- org.apache.tapestry5.ioc.services.PropertyAdapter
I realise that adding methods to public interfaces breaks backwards
compatability. What's people's thoughts on this?
--
Mit freundlichen Grüßen / Kind regards
Michael Wyraz
evermind GmbH
Schorlemmerstraße 1
04155 Leipzig
Tel.: +49 (0)341-25 39 66 - 0
Fax: +49 (0)341-25 39 66 - 1
Funk: +49 (0)177-73 00 00 3
E-Mail: michael.wy...@evermind.de
HRB: 21586
Amtsgericht Leipzig
Geschäftsführer:
Christoph Klemm
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
For additional commands, e-mail: dev-h...@tapestry.apache.org
