[PEPr] Comment on Web Services::Service_Geo

From: Date: Wed, 19 Jan 2005 23:37:30 +0000
Subject: [PEPr] Comment on Web Services::Service_Geo
References: 1  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-35625@lists.php.net to get a copy of this message
Nedjo Rogers (http://pear.php.net/user/nedjo) has commented on the proposal for Web Services::Service_Geo. Comment: Thanks for the detailed suggestions, Justin. I'll get to work on bringing the code into line with the formatting standards. Regarding private variables and methods, I'm a bit sketchy on what I should be doing and don't find this covered in the PEAR manual. Could anyone point me to guidelines or good examples to work from? Should I simply be designating as private all variables and methods not referenced from outside an object? I appreciate your thoughts on structure, Bertrand. I don't really understand what you mean by 'defaults should be isolated'. Could you explain? I'll study the Net_SMS package to see if I can understand what you're suggesting. Meanwhile, I'll try to explain better the reasoning behind the current structure. Service_Geo differs somewhat from some other Service packages in that it relates to a defined set of standards, rather than a loose standard with implementations that vary significantly between different vendors or suppliers. I plan to add support for one further Open Geospatial Consortium standard - the Web Feature Service standard - but don't foresee that other non-OGC standards would fit here. Since the base parameters (service title and abstract, contact info, etc.) are fairly uniform across OGC Service specs, I'm thinking that most of these parameters will work fine for, at least, both Web Map and Web Feature Service implementations. How the objects are structured reflects the aim of ensuring that a single Service_Geo instance can function as more than one service type (e.g., can handle both WMS and WFS requests--that is, when WFS support is in place). The approach to make this possible is: * Service_Geo instance is created and assigned parameters. Then, * Specific handlers (WMS or WFS) are set dynamically depending on the client request. This is why I've assigned the basic properties to the base service object. They can then be passed to (or, in this case, referenced by) sub-object 'handlers' when those are created. As this is my first time writing for PEAR, I'd particularly appreciate additional pointers/tips/critique from experienced developers. Thanks! Proposal information: http://pear.php.net/pepr/pepr-proposal-show.php?id=195 -- Sent by PEPr, the automatic proposal system at http://pear.php.net

« previous php.pear.dev (#35625) next »