Removing Zend_Gdata_Gbase and Zend_Gdata_Health

[Adam Lundrigan]

I've created patches to remove Gbase and Health APIs from Zend_Gdata:

• ZF-12187 - Remove Google Base API from Zend_Gdata
• ZF-12188 - Remove Google Health API 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]

[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:

• ZF-12187 - Remove Google Base API from Zend_Gdata
• ZF-12188 - Remove Google Health API 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]

[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:

• ZF-12187 - Remove Google Base API from Zend_Gdata
• ZF-12188 - Remove Google Health API 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]

[Adam Lundrigan]

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:

• ZF-12187 - Remove Google Base API from Zend_Gdata
• ZF-12188 - Remove Google Health API 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]

[robertbasic]

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:

• ZF-12187 - Remove Google Base API from Zend_Gdata
• ZF-12188 - Remove Google Health API 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]

[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:

• ZF-12187 - Remove Google Base API from Zend_Gdata
• ZF-12188 - Remove Google Health API 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]

[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

[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

[Adam Lundrigan]

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:

• ZF-12187 - Remove Google Base API from Zend_Gdata
• ZF-12188 - Remove Google Health API 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]

[Marco Pivetta (Ocramius)]

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   

  

http://marco-pivetta.com

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