Removing Zend_Gdata_Gbase and Zend_Gdata_Health

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Removing Zend_Gdata_Gbase and Zend_Gdata_Health

Adam Lundrigan

I've created patches to remove Gbase and Health APIs from Zend_Gdata:
Those APIs are no longer supported by Google.  The respective tickets contain the patches as well as an explanation of the method I used to remove each.

Could someone please review my patches to ensure they have the desired effect.  If all is well I will commit to trunk and release-1.11 before the next release.
 
Thanks!

--
Adam Lundrigan, B.Sc, ZCE
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Removing Zend_Gdata_Gbase and Zend_Gdata_Health

Marco Pivetta

Hey Adam,
Are you sure about introducing this into 1.11? It is a BC break... Shouldn't it only go to 1.12? :)

On May 5, 2012 2:44 AM, "Adam Lundrigan" <[hidden email]> wrote:

I've created patches to remove Gbase and Health APIs from Zend_Gdata:
Those APIs are no longer supported by Google.  The respective tickets contain the patches as well as an explanation of the method I used to remove each.

Could someone please review my patches to ensure they have the desired effect.  If all is well I will commit to trunk and release-1.11 before the next release.
 
Thanks!

--
Adam Lundrigan, B.Sc, ZCE
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Removing Zend_Gdata_Gbase and Zend_Gdata_Health

till
It seems the API is literally gone.

IMHO – a valid BC break. I doubt anyone is able to use this anyway.

-- 
till
Sent with Sparrow

On Sunday, May 6, 2012 at 6:34 PM, Marco Pivetta wrote:

Hey Adam,
Are you sure about introducing this into 1.11? It is a BC break... Shouldn't it only go to 1.12? :)

On May 5, 2012 2:44 AM, "Adam Lundrigan" <[hidden email]> wrote:

I've created patches to remove Gbase and Health APIs from Zend_Gdata:
Those APIs are no longer supported by Google.  The respective tickets contain the patches as well as an explanation of the method I used to remove each.

Could someone please review my patches to ensure they have the desired effect.  If all is well I will commit to trunk and release-1.11 before the next release.
 
Thanks!

--
Adam Lundrigan, B.Sc, ZCE
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Removing Zend_Gdata_Gbase and Zend_Gdata_Health

Adam Lundrigan
In reply to this post by Marco Pivetta

Marco,

It would be the if the code worked.  Those APIs have been disabled on Google's end so the code is useless now.
--
Adam Lundrigan, B.Sc, ZCE
[hidden email]

Sent from my Motorola Atrix smartphone

On 2012-05-06 2:04 PM, "Marco Pivetta" <[hidden email]> wrote:

Hey Adam,
Are you sure about introducing this into 1.11? It is a BC break... Shouldn't it only go to 1.12? :)

On May 5, 2012 2:44 AM, "Adam Lundrigan" <[hidden email]> wrote:

I've created patches to remove Gbase and Health APIs from Zend_Gdata:
Those APIs are no longer supported by Google.  The respective tickets contain the patches as well as an explanation of the method I used to remove each.

Could someone please review my patches to ensure they have the desired effect.  If all is well I will commit to trunk and release-1.11 before the next release.
 
Thanks!

--
Adam Lundrigan, B.Sc, ZCE
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Removing Zend_Gdata_Gbase and Zend_Gdata_Health

robertbasic
In reply to this post by Marco Pivetta

Adam, I think Marco was referring to the fact that you'll merge it to release-1.11 :) a typo I believe

On 6 May 2012 18:34, "Marco Pivetta" <[hidden email]> wrote:

Hey Adam,
Are you sure about introducing this into 1.11? It is a BC break... Shouldn't it only go to 1.12? :)

On May 5, 2012 2:44 AM, "Adam Lundrigan" <[hidden email]> wrote:

I've created patches to remove Gbase and Health APIs from Zend_Gdata:
Those APIs are no longer supported by Google.  The respective tickets contain the patches as well as an explanation of the method I used to remove each.

Could someone please review my patches to ensure they have the desired effect.  If all is well I will commit to trunk and release-1.11 before the next release.
 
Thanks!

--
Adam Lundrigan, B.Sc, ZCE
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Removing Zend_Gdata_Gbase and Zend_Gdata_Health

Marco Pivetta
Yeah, I was referring to the fact that even if these APIs don't work anymore (think I saw the notice by Google a couple of months ago), anyone using them for *some* reason shouldn't upgrade their 1.11 refs and receive a fatal :P

Marco Pivetta

http://twitter.com/Ocramius     

http://marco-pivetta.com    



On 6 May 2012 20:31, Robert Basic <[hidden email]> wrote:

Adam, I think Marco was referring to the fact that you'll merge it to release-1.11 :) a typo I believe

On 6 May 2012 18:34, "Marco Pivetta" <[hidden email]> wrote:

Hey Adam,
Are you sure about introducing this into 1.11? It is a BC break... Shouldn't it only go to 1.12? :)

On May 5, 2012 2:44 AM, "Adam Lundrigan" <[hidden email]> wrote:

I've created patches to remove Gbase and Health APIs from Zend_Gdata:
Those APIs are no longer supported by Google.  The respective tickets contain the patches as well as an explanation of the method I used to remove each.

Could someone please review my patches to ensure they have the desired effect.  If all is well I will commit to trunk and release-1.11 before the next release.
 
Thanks!

--
Adam Lundrigan, B.Sc, ZCE
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Injecting arrays with DI config

Roediger, Tim

Hi all,

 

Browsing the DI code, I understand this kind of config  won’t work (the collection is injected with an array of strings, rather than an array of configured objects):

 

    'di' => array(

        'instance' => array(

            'alias' => array(

                'obj1' => 'Namespace\Class',

                'obj2' => 'Namespace\Class',

                'obj3' => 'Namespace\Class',

            ),

           

           ‘obj1’ => array(

                  ‘parameters’ => array(

                      ‘option’ => ‘Test 1’

           )),

 

           ‘obj2’ => array(

                  ‘parameters’ => array(

                      ‘option’ => ‘Test 2’

           )),

 

           ‘obj3’ => array(

                  ‘parameters’ => array(

                      ‘option’ => ‘Test 2’

           )),

 

            'Namespace\Another\Class' => array(

                'parameters' => array(               

                    'collection' => array(

                        'item1' => 'obj1',

                        'item2' => 'obj2',

                        'item3' => 'obj3',                                 

                    ),

                ),                   

            ),

            ……

 

So, my question is, is there a way to inject an array of arbitrary length of configured objects? If not, why is this not a good idea?

 

Cheers,

            

Tim Roediger

Reply | Threaded
Open this post in threaded view
|

Re: Injecting arrays with DI config

Marco Pivetta
The only way of achieving multiple injections of configured objects is the 'injections' config in Di. You can take a look at ralphs examples for this:
https://github.com/ralphschindler/Zend_DI-Examples/blob/master/example-08.php
https://github.com/ralphschindler/Zend_DI-Examples/blob/master/example-15.php

The problem is that Di doesn't know about your parameters, and cannot know if it should traverse an array passed in looking for instances.

Marco Pivetta

http://twitter.com/Ocramius     

http://marco-pivetta.com    



On 7 May 2012 07:49, Tim Roediger <[hidden email]> wrote:

Hi all,

 

Browsing the DI code, I understand this kind of config  won’t work (the collection is injected with an array of strings, rather than an array of configured objects):

 

    'di' => array(

        'instance' => array(

            'alias' => array(

                'obj1' => 'Namespace\Class',

                'obj2' => 'Namespace\Class',

                'obj3' => 'Namespace\Class',

            ),

           

           ‘obj1’ => array(

                  ‘parameters’ => array(

                      ‘option’ => ‘Test 1’

           )),

 

           ‘obj2’ => array(

                  ‘parameters’ => array(

                      ‘option’ => ‘Test 2’

           )),

 

           ‘obj3’ => array(

                  ‘parameters’ => array(

                      ‘option’ => ‘Test 2’

           )),

 

            'Namespace\Another\Class' => array(

                'parameters' => array(               

                    'collection' => array(

                        'item1' => 'obj1',

                        'item2' => 'obj2',

                        'item3' => 'obj3',                                 

                    ),

                ),                   

            ),

            ……

 

So, my question is, is there a way to inject an array of arbitrary length of configured objects? If not, why is this not a good idea?

 

Cheers,

            

Tim Roediger


Reply | Threaded
Open this post in threaded view
|

Re: Removing Zend_Gdata_Gbase and Zend_Gdata_Health

Adam Lundrigan
In reply to this post by Marco Pivetta

My brain was working when I read your first message, I swear!  :P

I see your point now.  An application may gracefully handle the API failing, but may not handle an exception thrown directly from the constructor and so that would break the application. 

I think you're right about leaving the code in 1.11 branch.

--
Adam Lundrigan, B.Sc, ZCE
[hidden email]

Sent from my Motorola Atrix smartphone

On 2012-05-06 5:24 PM, "Marco Pivetta" <[hidden email]> wrote:
Yeah, I was referring to the fact that even if these APIs don't work anymore (think I saw the notice by Google a couple of months ago), anyone using them for *some* reason shouldn't upgrade their 1.11 refs and receive a fatal :P

Marco Pivetta

http://twitter.com/Ocramius     

http://marco-pivetta.com    



On 6 May 2012 20:31, Robert Basic <[hidden email]> wrote:

Adam, I think Marco was referring to the fact that you'll merge it to release-1.11 :) a typo I believe

On 6 May 2012 18:34, "Marco Pivetta" <[hidden email]> wrote:

Hey Adam,
Are you sure about introducing this into 1.11? It is a BC break... Shouldn't it only go to 1.12? :)

On May 5, 2012 2:44 AM, "Adam Lundrigan" <[hidden email]> wrote:

I've created patches to remove Gbase and Health APIs from Zend_Gdata:
Those APIs are no longer supported by Google.  The respective tickets contain the patches as well as an explanation of the method I used to remove each.

Could someone please review my patches to ensure they have the desired effect.  If all is well I will commit to trunk and release-1.11 before the next release.
 
Thanks!

--
Adam Lundrigan, B.Sc, ZCE
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Injecting arrays with DI config

Marco Pivetta (Ocramius)
In reply to this post by Marco Pivetta
Just forwarding again as I think the message got filtered :)

The only way of achieving multiple injections of configured objects is the 'injections' config in Di. You can take a look at ralphs examples for this:
https://github.com/ralphschindler/Zend_DI-Examples/blob/master/example-08.php
https://github.com/ralphschindler/Zend_DI-Examples/blob/master/example-15.php

The problem is that Di doesn't know about your parameters, and cannot know if it should traverse an array passed in looking for instances.

Marco Pivetta

http://twitter.com/Ocramius   

On 7 May 2012 08:32, Marco Pivetta <[hidden email]> wrote:
The only way of achieving multiple injections of configured objects is the 'injections' config in Di. You can take a look at ralphs examples for this:
https://github.com/ralphschindler/Zend_DI-Examples/blob/master/example-08.php
https://github.com/ralphschindler/Zend_DI-Examples/blob/master/example-15.php

The problem is that Di doesn't know about your parameters, and cannot know if it should traverse an array passed in looking for instances.

Marco Pivetta

http://twitter.com/Ocramius     

http://marco-pivetta.com    



On 7 May 2012 07:49, Tim Roediger <[hidden email]> wrote:

Hi all,

 

Browsing the DI code, I understand this kind of config  won’t work (the collection is injected with an array of strings, rather than an array of configured objects):

 

    'di' => array(

        'instance' => array(

            'alias' => array(

                'obj1' => 'Namespace\Class',

                'obj2' => 'Namespace\Class',

                'obj3' => 'Namespace\Class',

            ),

           

           ‘obj1’ => array(

                  ‘parameters’ => array(

                      ‘option’ => ‘Test 1’

           )),

 

           ‘obj2’ => array(

                  ‘parameters’ => array(

                      ‘option’ => ‘Test 2’

           )),

 

           ‘obj3’ => array(

                  ‘parameters’ => array(

                      ‘option’ => ‘Test 2’

           )),

 

            'Namespace\Another\Class' => array(

                'parameters' => array(               

                    'collection' => array(

                        'item1' => 'obj1',

                        'item2' => 'obj2',

                        'item3' => 'obj3',                                 

                    ),

                ),                   

            ),

            ……

 

So, my question is, is there a way to inject an array of arbitrary length of configured objects? If not, why is this not a good idea?

 

Cheers,

            

Tim Roediger