Zend_Service_* guidelines/conventions?

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

Zend_Service_* guidelines/conventions?

Jack Sleight
Hi,
I'm writing a library to interact with the API of the accounting/time
tracking service I use (freeagentcentral.com), and have written it for
ZF (as in, with the same coding style, it uses Zend_Http_Client etc.), I
may even contribute it to ZF if there's any demand.

My question is are there any written or formal guidelines/conventions
for writing Zend_Service_* classes? For example many of the existing
classes do a similar job, send XML requests and receive XML responses,
however some simply return SimpleXML elements or array data, whereas
others have their own list/item classes that can be used in a similar
fashion to Zend_Db_Table_Rows and Rowsets.

I was just wondering if there's a best approach really,
Thanks,
--
Jack
Reply | Threaded
Open this post in threaded view
|

Re: Zend_Service_* guidelines/conventions?

Simone Carletti
You should consider that part of Zend_Service_* classes were created in the early epoch of the framework thus they might expose an outdated architecture compared with the current state of the framework.
Additionally, some web services are more complex than others thus they require to code a Response object instead of returning a simple Array.

I personally prefer to return objects instead of associative arrays just because they better follow an object oriented coding style and they are more flexible in case of complex web services.
For instance, when I created Zend_Service_Technorati it was difficult to provide the same level of features returning arrays just because I wasn't able to benefit of meta programming, inheritance and much more nice properties.

On the other hand, if your response simply returns an integer it could be pointless to code a full object for filling one attribute with the integer value.

About SimpleXML, I personally find harmful to return a SimpleXML object instead of a specific object or an array just because I force the end user to know all SimpleXML features and I definitively links the low level implementation of the library to SimpleXML. Changing the implementation in the future, for example using XPath calls, will cause some BC break and probably major changes in the public API of my class.

Bye,
Simone

On Wed, Mar 26, 2008 at 5:07 PM, Jack Sleight <[hidden email]> wrote:
Hi,
I'm writing a library to interact with the API of the accounting/time
tracking service I use (freeagentcentral.com), and have written it for
ZF (as in, with the same coding style, it uses Zend_Http_Client etc.), I
may even contribute it to ZF if there's any demand.

My question is are there any written or formal guidelines/conventions
for writing Zend_Service_* classes? For example many of the existing
classes do a similar job, send XML requests and receive XML responses,
however some simply return SimpleXML elements or array data, whereas
others have their own list/item classes that can be used in a similar
fashion to Zend_Db_Table_Rows and Rowsets.

I was just wondering if there's a best approach really,
Thanks,
--
Jack

Reply | Threaded
Open this post in threaded view
|

Re: Zend_Service_* guidelines/conventions?

Jack Sleight
Hi Simone,
Thanks for your advice. I think I'll probably go with returning custom objects, rather than arrays or SimpleXML objects.

Simone Carletti wrote:
You should consider that part of Zend_Service_* classes were created in the early epoch of the framework thus they might expose an outdated architecture compared with the current state of the framework.
Additionally, some web services are more complex than others thus they require to code a Response object instead of returning a simple Array.

I personally prefer to return objects instead of associative arrays just because they better follow an object oriented coding style and they are more flexible in case of complex web services.
For instance, when I created Zend_Service_Technorati it was difficult to provide the same level of features returning arrays just because I wasn't able to benefit of meta programming, inheritance and much more nice properties.

On the other hand, if your response simply returns an integer it could be pointless to code a full object for filling one attribute with the integer value.

About SimpleXML, I personally find harmful to return a SimpleXML object instead of a specific object or an array just because I force the end user to know all SimpleXML features and I definitively links the low level implementation of the library to SimpleXML. Changing the implementation in the future, for example using XPath calls, will cause some BC break and probably major changes in the public API of my class.

Bye,
Simone

On Wed, Mar 26, 2008 at 5:07 PM, Jack Sleight <[hidden email]> wrote:


--
Jack