[PEPr] Comment on Web Services::Service_Geo
| From: | Nedjo Rogers | 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