You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Lance Java <la...@googlemail.com> on 2014/05/14 22:33:15 UTC

TAP5-1213: Changes to public API

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?

Re: TAP5-1213: Changes to public API

Posted by Michael Wyraz <mi...@evermind.de>.
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.wyraz@evermind.de

HRB: 21586
Amtsgericht Leipzig

Geschäftsführer:
Christoph Klemm


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org


Re: TAP5-1213: Changes to public API

Posted by Lance Java <la...@googlemail.com>.
I've uploaded the patch to jira
https://issues.apache.org/jira/browse/TAP5-1213
https://issues.apache.org/jira/secure/attachment/12645469/TAP5-1213.patch

Cheers,
Lance.


On 18 May 2014 16:49, Ulrich Stärk <ul...@spielviel.de> wrote:

> If you are unsure you can send the patch here and ask for reviews.
>
> Uli
>
> On 2014-05-18 16:39, Lance Java wrote:
> > So, is it OK to commit the changes? It will obviously need a breaking
> > change note in the release notes.
> >  On 18 May 2014 00:10, "Howard Lewis Ship" <hl...@gmail.com> wrote:
> >
> >> It can be problematic; I don't expect people to implement
> >> ComponentResources ... but some other common interfaces, such as
> >> FormSupport, are often proxied/delegated in a way that provides pain
> when
> >> new methods are added.  JDK 8 default methods may help there, hard to
> say
> >> so far.
> >>
> >>
> >> On Sat, May 17, 2014 at 1:27 PM, Lance Java <lance.java@googlemail.com
> >>> wrote:
> >>
> >>> I've managed to solve the issue without affecting
> >> org.apache.tapestry5.ioc.
> >>> services.PropertyAdapter.
> >>>
> >>> So the introduced methods are:
> >>> Type Binding.getBindingGenericType()
> >>> Type PropertyConduit getPropertyGenericType()
> >>> Type ComponentResources.getBoundGenericType(String parameterName)
> >>>
> >>> I don't think anyone will be implementing their own ComponentResources
> or
> >>> PropertyConduit so I think those changes are fin. Ashas been mentioned,
> >>> third parties (including myself) have implemented custom bindings. If
> >> it's
> >>> any consolation, I've implemented
> AbstractBinding.getBindingGenericType()
> >>> to simply return getBindingType().
> >>>
> >>> The other solution I can see is to have Binding2 in a similar style to
> >>> Asset2 etc.
> >>>
> >>>
> >>> On 16 May 2014 00:48, Howard Lewis Ship <hl...@gmail.com> wrote:
> >>>
> >>>> I'd need to know a bit more; this will tend to break 3rd party
> >> libraries
> >>>> that compile against the old code, which is not so good. Possibly if
> >> the
> >>>> new information could be added under an entirely new method of the
> >>> existing
> >>>> APIs that would be less of a problem.
> >>>>
> >>>>
> >>>> On Wed, May 14, 2014 at 1:33 PM, Lance Java <
> lance.java@googlemail.com
> >>>>> wrote:
> >>>>
> >>>>> 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?
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Howard M. Lewis Ship
> >>>>
> >>>> Creator of Apache Tapestry
> >>>>
> >>>> The source for Tapestry training, mentoring and support. Contact me to
> >>>> learn how I can get you up and productive in Tapestry fast!
> >>>>
> >>>> (971) 678-5210
> >>>> http://howardlewisship.com
> >>>> @hlship
> >>>>
> >>>
> >>
> >>
> >>
> >> --
> >> Howard M. Lewis Ship
> >>
> >> Creator of Apache Tapestry
> >>
> >> The source for Tapestry training, mentoring and support. Contact me to
> >> learn how I can get you up and productive in Tapestry fast!
> >>
> >> (971) 678-5210
> >> http://howardlewisship.com
> >> @hlship
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>

Re: TAP5-1213: Changes to public API

Posted by Ulrich Stärk <ul...@spielviel.de>.
If you are unsure you can send the patch here and ask for reviews.

Uli

On 2014-05-18 16:39, Lance Java wrote:
> So, is it OK to commit the changes? It will obviously need a breaking
> change note in the release notes.
>  On 18 May 2014 00:10, "Howard Lewis Ship" <hl...@gmail.com> wrote:
> 
>> It can be problematic; I don't expect people to implement
>> ComponentResources ... but some other common interfaces, such as
>> FormSupport, are often proxied/delegated in a way that provides pain when
>> new methods are added.  JDK 8 default methods may help there, hard to say
>> so far.
>>
>>
>> On Sat, May 17, 2014 at 1:27 PM, Lance Java <lance.java@googlemail.com
>>> wrote:
>>
>>> I've managed to solve the issue without affecting
>> org.apache.tapestry5.ioc.
>>> services.PropertyAdapter.
>>>
>>> So the introduced methods are:
>>> Type Binding.getBindingGenericType()
>>> Type PropertyConduit getPropertyGenericType()
>>> Type ComponentResources.getBoundGenericType(String parameterName)
>>>
>>> I don't think anyone will be implementing their own ComponentResources or
>>> PropertyConduit so I think those changes are fin. Ashas been mentioned,
>>> third parties (including myself) have implemented custom bindings. If
>> it's
>>> any consolation, I've implemented AbstractBinding.getBindingGenericType()
>>> to simply return getBindingType().
>>>
>>> The other solution I can see is to have Binding2 in a similar style to
>>> Asset2 etc.
>>>
>>>
>>> On 16 May 2014 00:48, Howard Lewis Ship <hl...@gmail.com> wrote:
>>>
>>>> I'd need to know a bit more; this will tend to break 3rd party
>> libraries
>>>> that compile against the old code, which is not so good. Possibly if
>> the
>>>> new information could be added under an entirely new method of the
>>> existing
>>>> APIs that would be less of a problem.
>>>>
>>>>
>>>> On Wed, May 14, 2014 at 1:33 PM, Lance Java <lance.java@googlemail.com
>>>>> wrote:
>>>>
>>>>> 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?
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Howard M. Lewis Ship
>>>>
>>>> Creator of Apache Tapestry
>>>>
>>>> The source for Tapestry training, mentoring and support. Contact me to
>>>> learn how I can get you up and productive in Tapestry fast!
>>>>
>>>> (971) 678-5210
>>>> http://howardlewisship.com
>>>> @hlship
>>>>
>>>
>>
>>
>>
>> --
>> Howard M. Lewis Ship
>>
>> Creator of Apache Tapestry
>>
>> The source for Tapestry training, mentoring and support. Contact me to
>> learn how I can get you up and productive in Tapestry fast!
>>
>> (971) 678-5210
>> http://howardlewisship.com
>> @hlship
>>
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org


Re: TAP5-1213: Changes to public API

Posted by Lance Java <la...@googlemail.com>.
So, is it OK to commit the changes? It will obviously need a breaking
change note in the release notes.
 On 18 May 2014 00:10, "Howard Lewis Ship" <hl...@gmail.com> wrote:

> It can be problematic; I don't expect people to implement
> ComponentResources ... but some other common interfaces, such as
> FormSupport, are often proxied/delegated in a way that provides pain when
> new methods are added.  JDK 8 default methods may help there, hard to say
> so far.
>
>
> On Sat, May 17, 2014 at 1:27 PM, Lance Java <lance.java@googlemail.com
> >wrote:
>
> > I've managed to solve the issue without affecting
> org.apache.tapestry5.ioc.
> > services.PropertyAdapter.
> >
> > So the introduced methods are:
> > Type Binding.getBindingGenericType()
> > Type PropertyConduit getPropertyGenericType()
> > Type ComponentResources.getBoundGenericType(String parameterName)
> >
> > I don't think anyone will be implementing their own ComponentResources or
> > PropertyConduit so I think those changes are fin. Ashas been mentioned,
> > third parties (including myself) have implemented custom bindings. If
> it's
> > any consolation, I've implemented AbstractBinding.getBindingGenericType()
> > to simply return getBindingType().
> >
> > The other solution I can see is to have Binding2 in a similar style to
> > Asset2 etc.
> >
> >
> > On 16 May 2014 00:48, Howard Lewis Ship <hl...@gmail.com> wrote:
> >
> > > I'd need to know a bit more; this will tend to break 3rd party
> libraries
> > > that compile against the old code, which is not so good. Possibly if
> the
> > > new information could be added under an entirely new method of the
> > existing
> > > APIs that would be less of a problem.
> > >
> > >
> > > On Wed, May 14, 2014 at 1:33 PM, Lance Java <lance.java@googlemail.com
> > > >wrote:
> > >
> > > > 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?
> > > >
> > >
> > >
> > >
> > > --
> > > Howard M. Lewis Ship
> > >
> > > Creator of Apache Tapestry
> > >
> > > The source for Tapestry training, mentoring and support. Contact me to
> > > learn how I can get you up and productive in Tapestry fast!
> > >
> > > (971) 678-5210
> > > http://howardlewisship.com
> > > @hlship
> > >
> >
>
>
>
> --
> Howard M. Lewis Ship
>
> Creator of Apache Tapestry
>
> The source for Tapestry training, mentoring and support. Contact me to
> learn how I can get you up and productive in Tapestry fast!
>
> (971) 678-5210
> http://howardlewisship.com
> @hlship
>

Re: TAP5-1213: Changes to public API

Posted by Michael Wyraz <mi...@evermind.de>.
Hi,

Java 8 default methods doesn't seem to be a valid solution. They allows 
to keep an implementation compatible when new methods are added but (as 
far as I could see) they do not enable binary compatibility (means, the 
method remains abstract until the implementation is compiled against the 
new interface, see 
http://stackoverflow.com/questions/22618493/does-introducing-a-default-method-to-an-interface-really-preserve-back-compatibi 
for details). So it's more or less compiler magic.

But how about a worker that instruments "Binding" implementations where 
the new method "Binding.getBindingGenericType()"
is not implemented and simply add a new Method that redirects to 
Binding.getBindingType()?

Kind regards,
Michael.


> It can be problematic; I don't expect people to implement
> ComponentResources ... but some other common interfaces, such as
> FormSupport, are often proxied/delegated in a way that provides pain when
> new methods are added.  JDK 8 default methods may help there, hard to say
> so far.
>
>
> On Sat, May 17, 2014 at 1:27 PM, Lance Java <la...@googlemail.com>wrote:
>
>> I've managed to solve the issue without affecting org.apache.tapestry5.ioc.
>> services.PropertyAdapter.
>>
>> So the introduced methods are:
>> Type Binding.getBindingGenericType()
>> Type PropertyConduit getPropertyGenericType()
>> Type ComponentResources.getBoundGenericType(String parameterName)
>>
>> I don't think anyone will be implementing their own ComponentResources or
>> PropertyConduit so I think those changes are fin. Ashas been mentioned,
>> third parties (including myself) have implemented custom bindings. If it's
>> any consolation, I've implemented AbstractBinding.getBindingGenericType()
>> to simply return getBindingType().
>>
>> The other solution I can see is to have Binding2 in a similar style to
>> Asset2 etc.
>>
>>
>> On 16 May 2014 00:48, Howard Lewis Ship <hl...@gmail.com> wrote:
>>
>>> I'd need to know a bit more; this will tend to break 3rd party libraries
>>> that compile against the old code, which is not so good. Possibly if the
>>> new information could be added under an entirely new method of the
>> existing
>>> APIs that would be less of a problem.
>>>
>>>
>>> On Wed, May 14, 2014 at 1:33 PM, Lance Java <lance.java@googlemail.com
>>>> wrote:
>>>> 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?
>>>>
>>>
>>>
>>> --
>>> Howard M. Lewis Ship
>>>
>>> Creator of Apache Tapestry
>>>
>>> The source for Tapestry training, mentoring and support. Contact me to
>>> learn how I can get you up and productive in Tapestry fast!
>>>
>>> (971) 678-5210
>>> http://howardlewisship.com
>>> @hlship
>>>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org


Re: TAP5-1213: Changes to public API

Posted by Howard Lewis Ship <hl...@gmail.com>.
It can be problematic; I don't expect people to implement
ComponentResources ... but some other common interfaces, such as
FormSupport, are often proxied/delegated in a way that provides pain when
new methods are added.  JDK 8 default methods may help there, hard to say
so far.


On Sat, May 17, 2014 at 1:27 PM, Lance Java <la...@googlemail.com>wrote:

> I've managed to solve the issue without affecting org.apache.tapestry5.ioc.
> services.PropertyAdapter.
>
> So the introduced methods are:
> Type Binding.getBindingGenericType()
> Type PropertyConduit getPropertyGenericType()
> Type ComponentResources.getBoundGenericType(String parameterName)
>
> I don't think anyone will be implementing their own ComponentResources or
> PropertyConduit so I think those changes are fin. Ashas been mentioned,
> third parties (including myself) have implemented custom bindings. If it's
> any consolation, I've implemented AbstractBinding.getBindingGenericType()
> to simply return getBindingType().
>
> The other solution I can see is to have Binding2 in a similar style to
> Asset2 etc.
>
>
> On 16 May 2014 00:48, Howard Lewis Ship <hl...@gmail.com> wrote:
>
> > I'd need to know a bit more; this will tend to break 3rd party libraries
> > that compile against the old code, which is not so good. Possibly if the
> > new information could be added under an entirely new method of the
> existing
> > APIs that would be less of a problem.
> >
> >
> > On Wed, May 14, 2014 at 1:33 PM, Lance Java <lance.java@googlemail.com
> > >wrote:
> >
> > > 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?
> > >
> >
> >
> >
> > --
> > Howard M. Lewis Ship
> >
> > Creator of Apache Tapestry
> >
> > The source for Tapestry training, mentoring and support. Contact me to
> > learn how I can get you up and productive in Tapestry fast!
> >
> > (971) 678-5210
> > http://howardlewisship.com
> > @hlship
> >
>



-- 
Howard M. Lewis Ship

Creator of Apache Tapestry

The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!

(971) 678-5210
http://howardlewisship.com
@hlship

Re: TAP5-1213: Changes to public API

Posted by Lance Java <la...@googlemail.com>.
Haha... I could try / catch AbstractMethodError and get rid of Binding2 /
PropertyConduit2. Win!

Jokes...
 On 20 May 2014 17:46, "Jochen Kemnade" <ke...@gmail.com> wrote:

> True, but if they occur, the cause is not so easy to find IMO.
>

Re: TAP5-1213: Changes to public API

Posted by Jochen Kemnade <ke...@gmail.com>.
True, but if they occur, the cause is not so easy to find IMO.

Re: TAP5-1213: Changes to public API

Posted by Lance Java <la...@googlemail.com>.
I was referring to the exception being rare, not third party
implementations.

Keep in mind that the exception will only occur when invoking the new
method on ComponentResources. At the moment there is no such code in
existence.
 On 20 May 2014 13:51, "Thiago H de Paula Figueiredo" <th...@gmail.com>
wrote:

> On Tue, 20 May 2014 07:20:21 -0300, Lance Java <la...@googlemail.com>
> wrote:
>
>  This would only occur in third party bindings / propertyConduits that
>> don't extend core (internal) implementations.
>>
>> IMHO these exceptions are likely to be rare as hen's teeth ;)
>>
>
> Agreed for ComponentResources, less agreed for Binding and disagreed for
> PropertyConduit, which is used inside some projects to implement some
> properties for BeanModel-based components. This is *not* uncommon to be
> found in non-library code.
>
> --
> Thiago H. de Paula Figueiredo
> Tapestry, Java and Hibernate consultant and developer
> http://machina.com.br
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>

Re: TAP5-1213: Changes to public API

Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Tue, 20 May 2014 07:20:21 -0300, Lance Java <la...@googlemail.com>  
wrote:

> This would only occur in third party bindings / propertyConduits that  
> don't extend core (internal) implementations.
>
> IMHO these exceptions are likely to be rare as hen's teeth ;)

Agreed for ComponentResources, less agreed for Binding and disagreed for  
PropertyConduit, which is used inside some projects to implement some  
properties for BeanModel-based components. This is *not* uncommon to be  
found in non-library code.

-- 
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org


Re: TAP5-1213: Changes to public API

Posted by Michael Wyraz <mi...@evermind.de>.
> In this instance, I would assume an AbstractMethodError would be 
> thrown when calling the new method: 
> ComponentResources.getBoundGenericType(paramName) This would only 
> occur in third party bindings / propertyConduits that don't extend 
> core (internal) implementations. IMHO these exceptions are likely to 
> be rare as hen's teeth ;) 
And the exception would only be thrown if the new method is called (e.g. 
via ComponentResources) which is only the case for new code. So a 
problem occurs only if new code uses old bindings. Old code that uses 
old bindings would still work without problems. If I have a voice, I 
vote for API change in this cases. This is better to have Binding2, 
Binding2, BindingN (imagine what once would happen if some binding 
implements Binding 1,2,4 but not 3 ;-) ).

Do you think the feature could make it in the new beta?

Kind Regards,
Michael.


-- 

Mit freundlichen Grüßen / 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.wyraz@evermind.de

HRB: 21586
Amtsgericht Leipzig

Geschäftsführer:
Christoph Klemm
Thomas Grünert
Michael Wyraz


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org


Re: TAP5-1213: Changes to public API

Posted by Lance Java <la...@googlemail.com>.
> wouldn't adding methods to the existing interfaces lead to libraries
written for (and compiled against) Tapestry 5.3 would not work with
Tapestry 5.4 anymore?

In this instance, I would assume an AbstractMethodError would be thrown
when calling the new method:
ComponentResources.getBoundGenericType(paramName)

This would only occur in third party bindings / propertyConduits that don't
extend core (internal) implementations.

IMHO these exceptions are likely to be rare as hen's teeth ;)

Re: TAP5-1213: Changes to public API

Posted by Jochen Kemnade <jo...@eddyson.de>.
Am 20.05.2014 08:23, schrieb Lance Java:
> I agree but thought I was in the minority.
>
> The extra interfaces have increased the complexity and require third
> parties to know about the nuances of the implementation. Adding methods to
> the public API may cause compilation errors (in rare cases) but at least
> it's clear.
>
> Anyone else have an opinion?

Unfortunately, I haven't had the chance to look at the changes too 
closely yet, so I'm not sure if this is relevant at all. But wouldn't 
adding methods to the existing interfaces lead to libraries written for 
(and compiled against) Tapestry 5.3 would not work with Tapestry 5.4 
anymore?

Jochen

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org


Re: TAP5-1213: Changes to public API

Posted by Lance Java <la...@googlemail.com>.
I agree but thought I was in the minority.

The extra interfaces have increased the complexity and require third
parties to know about the nuances of the implementation. Adding methods to
the public API may cause compilation errors (in rare cases) but at least
it's clear.

Anyone else have an opinion?
 On 20 May 2014 00:13, "Kalle Korhonen" <ka...@gmail.com> wrote:

> JMHO, maintaining backwards compatibility in this case isn't worth the
> added complexity. Making support libraries compatible requires just
> compiling them against the new version and there are many other, more
> drastic changes in 5.4 that require at least a re-compilation and in many
> cases, changes in the library code. Just my point of view as an author of
> multiple T5.4 support libraries.
>
> Kalle
>
>
> On Mon, May 19, 2014 at 1:52 PM, Lance Java <lance.java@googlemail.com
> >wrote:
>
> > ok, just committed with Binding2 / PropertyConduit2 keeping backwards
> > compatibility in tact.
> >
> >
> > On 19 May 2014 19:02, Lance Java <la...@googlemail.com> wrote:
> >
> > > I can implement like that if others agree. I just hate instanceof
> > littered
> > > around the place.
> > >
> > > It also brings up the possibility of third parties wrapping a Binding2
> > > with a Binding and losing functionality. I'd prefer a compilation error
> > > myself.
> > >  On 19 May 2014 17:46, "Thiago H de Paula Figueiredo" <
> > thiagohp@gmail.com>
> > > wrote:
> > >
> > >> On Mon, 19 May 2014 13:04:55 -0300, Lance Java <
> > lance.java@googlemail.com>
> > >> wrote:
> > >>
> > >>  I guess my question is, is it worth adding / maintaining Binding2 and
> > >>> PropertyConduit2 and all the type checking / adapting.
> > >>>
> > >>> Or are we happy to add the methods to the public API given its a no
> > >>> brainer to implement getGenericType() to return getType()
> > >>>
> > >>
> > >> Considering we've dealt with this kind of scenario using the first
> > option
> > >> (Binding2 and PropertyConduit2), I'd go with it. I guess just a
> handful
> > of
> > >> places would need to be adapted.
> > >>
> > >> --
> > >> Thiago H. de Paula Figueiredo
> > >> Tapestry, Java and Hibernate consultant and developer
> > >> http://machina.com.br
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> > >> For additional commands, e-mail: dev-help@tapestry.apache.org
> > >>
> > >>
> >
>

Re: TAP5-1213: Changes to public API

Posted by Kalle Korhonen <ka...@gmail.com>.
JMHO, maintaining backwards compatibility in this case isn't worth the
added complexity. Making support libraries compatible requires just
compiling them against the new version and there are many other, more
drastic changes in 5.4 that require at least a re-compilation and in many
cases, changes in the library code. Just my point of view as an author of
multiple T5.4 support libraries.

Kalle


On Mon, May 19, 2014 at 1:52 PM, Lance Java <la...@googlemail.com>wrote:

> ok, just committed with Binding2 / PropertyConduit2 keeping backwards
> compatibility in tact.
>
>
> On 19 May 2014 19:02, Lance Java <la...@googlemail.com> wrote:
>
> > I can implement like that if others agree. I just hate instanceof
> littered
> > around the place.
> >
> > It also brings up the possibility of third parties wrapping a Binding2
> > with a Binding and losing functionality. I'd prefer a compilation error
> > myself.
> >  On 19 May 2014 17:46, "Thiago H de Paula Figueiredo" <
> thiagohp@gmail.com>
> > wrote:
> >
> >> On Mon, 19 May 2014 13:04:55 -0300, Lance Java <
> lance.java@googlemail.com>
> >> wrote:
> >>
> >>  I guess my question is, is it worth adding / maintaining Binding2 and
> >>> PropertyConduit2 and all the type checking / adapting.
> >>>
> >>> Or are we happy to add the methods to the public API given its a no
> >>> brainer to implement getGenericType() to return getType()
> >>>
> >>
> >> Considering we've dealt with this kind of scenario using the first
> option
> >> (Binding2 and PropertyConduit2), I'd go with it. I guess just a handful
> of
> >> places would need to be adapted.
> >>
> >> --
> >> Thiago H. de Paula Figueiredo
> >> Tapestry, Java and Hibernate consultant and developer
> >> http://machina.com.br
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: dev-help@tapestry.apache.org
> >>
> >>
>

Re: TAP5-1213: Changes to public API

Posted by Lance Java <la...@googlemail.com>.
ok, just committed with Binding2 / PropertyConduit2 keeping backwards
compatibility in tact.


On 19 May 2014 19:02, Lance Java <la...@googlemail.com> wrote:

> I can implement like that if others agree. I just hate instanceof littered
> around the place.
>
> It also brings up the possibility of third parties wrapping a Binding2
> with a Binding and losing functionality. I'd prefer a compilation error
> myself.
>  On 19 May 2014 17:46, "Thiago H de Paula Figueiredo" <th...@gmail.com>
> wrote:
>
>> On Mon, 19 May 2014 13:04:55 -0300, Lance Java <la...@googlemail.com>
>> wrote:
>>
>>  I guess my question is, is it worth adding / maintaining Binding2 and
>>> PropertyConduit2 and all the type checking / adapting.
>>>
>>> Or are we happy to add the methods to the public API given its a no
>>> brainer to implement getGenericType() to return getType()
>>>
>>
>> Considering we've dealt with this kind of scenario using the first option
>> (Binding2 and PropertyConduit2), I'd go with it. I guess just a handful of
>> places would need to be adapted.
>>
>> --
>> Thiago H. de Paula Figueiredo
>> Tapestry, Java and Hibernate consultant and developer
>> http://machina.com.br
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>>

Re: TAP5-1213: Changes to public API

Posted by Lance Java <la...@googlemail.com>.
I can implement like that if others agree. I just hate instanceof littered
around the place.

It also brings up the possibility of third parties wrapping a Binding2 with
a Binding and losing functionality. I'd prefer a compilation error myself.
 On 19 May 2014 17:46, "Thiago H de Paula Figueiredo" <th...@gmail.com>
wrote:

> On Mon, 19 May 2014 13:04:55 -0300, Lance Java <la...@googlemail.com>
> wrote:
>
>  I guess my question is, is it worth adding / maintaining Binding2 and
>> PropertyConduit2 and all the type checking / adapting.
>>
>> Or are we happy to add the methods to the public API given its a no
>> brainer to implement getGenericType() to return getType()
>>
>
> Considering we've dealt with this kind of scenario using the first option
> (Binding2 and PropertyConduit2), I'd go with it. I guess just a handful of
> places would need to be adapted.
>
> --
> Thiago H. de Paula Figueiredo
> Tapestry, Java and Hibernate consultant and developer
> http://machina.com.br
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>

Re: TAP5-1213: Changes to public API

Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Mon, 19 May 2014 13:04:55 -0300, Lance Java <la...@googlemail.com>  
wrote:

> I guess my question is, is it worth adding / maintaining Binding2 and
> PropertyConduit2 and all the type checking / adapting.
>
> Or are we happy to add the methods to the public API given its a no  
> brainer to implement getGenericType() to return getType()

Considering we've dealt with this kind of scenario using the first option  
(Binding2 and PropertyConduit2), I'd go with it. I guess just a handful of  
places would need to be adapted.

-- 
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org


Re: TAP5-1213: Changes to public API

Posted by Lance Java <la...@googlemail.com>.
I guess my question is, is it worth adding / maintaining Binding2 and
PropertyConduit2 and all the type checking / adapting.

Or are we happy to add the methods to the public API given its a no brainer
to implement getGenericType() to return getType()
 On 19 May 2014 15:17, "Thiago H de Paula Figueiredo" <th...@gmail.com>
wrote:

> On Sat, 17 May 2014 14:27:21 -0300, Lance Java <la...@googlemail.com>
> wrote:
>
>  I don't think anyone will be implementing their own ComponentResources or
>> PropertyConduit so I think those changes are fin.
>>
>
> Agreed with ComponentResources, not about PropertyConduit, but I still
> think that wouldn't be a problem, specially if a new PropertyConduit2
> interface is defined.
>
> --
> Thiago H. de Paula Figueiredo
> Tapestry, Java and Hibernate consultant and developer
> http://machina.com.br
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>

Re: TAP5-1213: Changes to public API

Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Sat, 17 May 2014 14:27:21 -0300, Lance Java <la...@googlemail.com>  
wrote:

> I don't think anyone will be implementing their own ComponentResources or
> PropertyConduit so I think those changes are fin.

Agreed with ComponentResources, not about PropertyConduit, but I still  
think that wouldn't be a problem, specially if a new PropertyConduit2  
interface is defined.

-- 
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org


Re: TAP5-1213: Changes to public API

Posted by Lance Java <la...@googlemail.com>.
I've managed to solve the issue without affecting org.apache.tapestry5.ioc.
services.PropertyAdapter.

So the introduced methods are:
Type Binding.getBindingGenericType()
Type PropertyConduit getPropertyGenericType()
Type ComponentResources.getBoundGenericType(String parameterName)

I don't think anyone will be implementing their own ComponentResources or
PropertyConduit so I think those changes are fin. Ashas been mentioned,
third parties (including myself) have implemented custom bindings. If it's
any consolation, I've implemented AbstractBinding.getBindingGenericType()
to simply return getBindingType().

The other solution I can see is to have Binding2 in a similar style to
Asset2 etc.


On 16 May 2014 00:48, Howard Lewis Ship <hl...@gmail.com> wrote:

> I'd need to know a bit more; this will tend to break 3rd party libraries
> that compile against the old code, which is not so good. Possibly if the
> new information could be added under an entirely new method of the existing
> APIs that would be less of a problem.
>
>
> On Wed, May 14, 2014 at 1:33 PM, Lance Java <lance.java@googlemail.com
> >wrote:
>
> > 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?
> >
>
>
>
> --
> Howard M. Lewis Ship
>
> Creator of Apache Tapestry
>
> The source for Tapestry training, mentoring and support. Contact me to
> learn how I can get you up and productive in Tapestry fast!
>
> (971) 678-5210
> http://howardlewisship.com
> @hlship
>

Re: TAP5-1213: Changes to public API

Posted by Howard Lewis Ship <hl...@gmail.com>.
I'd need to know a bit more; this will tend to break 3rd party libraries
that compile against the old code, which is not so good. Possibly if the
new information could be added under an entirely new method of the existing
APIs that would be less of a problem.


On Wed, May 14, 2014 at 1:33 PM, Lance Java <la...@googlemail.com>wrote:

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



-- 
Howard M. Lewis Ship

Creator of Apache Tapestry

The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!

(971) 678-5210
http://howardlewisship.com
@hlship