Re: UPS Package

Bertrand Mansion wrote:

Here are some design notes I already sent to Joe. But as we don't have the wiki yet, I will post them here too for discussion. I suggest using the Strategy pattern for that package: http://home.earthlink.net/~huston2/dp/strategy.html http://www.phppatterns.com/index.php/article/articleview/13/1/1/ And maybe the Proxy pattern too: http://www.phppatterns.com/index.php/article/articleview/20/1/1/

|   Services_Shipping  |    Services_Shipping_USPS
|                      |                                Context ---> Strategy ---> Proxy ---> Free implementation of Service
    1           2            3                      4

Then Object 4 could be developped independently from other packages by different developers using different APIs. The good thing is that it could also be used independently. For example, if I only need Chronopost, I won't need the Context object nor the Strategy. Furthermore, the 4th object will also be more complete and offer more methods than the Strategy alone, if possible. Each Shipping package will have to come with a Proxy interface compatible with the main Shipping package. Actually, this ends up a bit like the Adapter pattern but I tend to think that Proxy + Strategy are more flexible and you get rid of a lot of if/else structures in the code. Plus you are free to add your own Strategy if it is not provided by PEAR (for example, if you have an offline cached version of the Shipper tables).

IMHO, most of those patterns wouldn't be part of that PEAR "Service_Shipping" package(s). Since this is PEAR (with all the CS) "we" can and will define the common minimal API to all shippers. This should take care of the Proxy patterm. I see it useful to bridge the gap between PEAR and non-PEAR classes, but it is a specific of an application, hence not a PEAR problem. If someone wants to use a third-party class, they can either ask the author to include it in PEAR or write a proxy to it for their own use. I don't see PEAR accepting proxy packages... It appears to me that all this would apply more to a shipper-selector type-of package. Something like "Find the cheapest shipper for a 2-day delivery". This would certainly be useful for a automated warehouse application, but maybe not as a starting point for this PEAR shipping package... As someone said before, each shipper "driver" could have a whole lot more than the common API to be used alone. As far as the cached shipper table, are you refering to shipping cost or list shippers. I don't think rates should be cached, too complicated and rates change all the time. This would be rewriting the shipper web service itself as PEAR ones... I don't see the advantage. IMHO, what is being attempted is to write web service *client" packages. -Philippe