Re: [PEPr] Comment on Web Services::Service_Geo

Nedjo Rogers wrote:

I don't really understand what you mean by 'defaults should be isolated'. Could you explain? e.g. for the property defaultType: instead of

$this->defaultType = isset($parameters['defaultType']) ? $parameters['defaultType'] : 'WMS'; I think it's better to have in the var section: /** * Default service, will apply if service's name is not specified * * @var string $defaultType */ var $defaultType = 'WMS'; And then in the constructor: if (isset($parameters['defaultType'])) {

       $this->defaultType = $parameters['defaultType'];

} It's longer code but IMHO easier to understand, that apply to each property what will unconditionnaly set. Better to have them "declared". Should I suggest: foreach ( array( 'defaultType', 'title', 'abstract', ....) as $pnam) {

    if (isset($parameters[$pNam])) {
           $this->$pNam = $parameters[$pNam];
    }

}

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. In fact better studying your geo.php I can see that your var $featureTypes is somewhat the same as Net_SMS's $_params. So, you allready have such a feature, even less opaque.

But I understand it's a mess to distinguish what is or should be common among the services, and what is peculiar to WMS for example.

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 That's the best way to have a practical idea on the parameters topology (whom they belong).

I believe your OO structure can do that. (in a first glance) BTW how do you come clear with all these WMS.php everywhere ? ;) PEAR's file/class naming doesn't bring only good effects: /dura lex sed lex/

- 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. Looks fine ! I love your factories !

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. OK, with your explanations, I understand better your structure, thanx.

Proposal information: http://pear.php.net/pepr/pepr-proposal-show.php?id=195 Bravo, you can be confident !

For the CS aspects, did you try PHPBeautifier ? à+ -- bertrand Gugger (toggg)