Re: UPS Package

Philippe Jausions wrote: >Hi, > >Hummm... I think that would need clarification. What do you call >"Tracking"? Is it the ability to register a parcel and get a tracking >number or some kind of in-transit status information using a tracking >number? > >Also what does the "rates" service would provide? Cost for one parcel on >one shipping service (i.e. Ground, Air, 2nd Air...), or comparative cost >of one parcel for those multiple shipping services. This leads to the >having a feature that returns a list of shipping services for that >shipper (hint: use caching mechanism.) Should that list be standardized >between shipper drivers? Answer is mixed: "Yes" to do easy rate >comparison, but "No" for expansion/maintenance. > >I'm not sure what you mean by the "Delivery Notification", would it be a >pull or a push-registration if provided by shipper? > >One thing to add, is Shipping Label link reference if supported. But I >guess that could be part of returned values from a parcel "registration"... > >As I said, before, a Wiki would be great to discuss all that... I like Services_Shipping_Parcel idea too. 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). Let me know what you think. Bertrand Mansion Mamasam