Hi Mike, One of the goals of the SCA annotations has been to try to preserve phpDocumentor generation, so I like your suggestion a lot. I took a look at the phpDocumentor documentation and could only see mention of the pipe for multiple function returns, but not for parameters. I gave it a whirl for both and phpDocumentor 1.3.0 doesn't appear to do anything special with the pipe and doesn't care if it's included in an @param.
If we include the modification suggested in another thread where we would change the way complex types are specified to use the # character (will improve the quality of the phpDocumentor generation), then an example SCA component might look like this: /** * Service for managing email contacts * * @service * @binding.soap * @types http://example.org/contacts contacts.xsd * */ class ContactService { /** * Retrieve contact details * * @param string|null $shortname The short name of the contact * @return http://example.org/contacts#contact|null The full contact details */ public function retrieve($shortname) { } } Let me know if I've misunderstood your proposal. The only reason I can think for the generation of nillable all the time would be to support as many calling options with as little configuration as possible. I can understand why the other way round might be preferable and adding control through the annotations gets my +1. Graham On 11 May, 18:40, Michael Caplan <[EMAIL PROTECTED]> wrote: > I've been looking into this issue further. The condition(s) to > determine if a callable method parameter is nillable more tricky than > I initially thought. I was hoping that a simple > ReflectionParameter::allowsNull() call would be all that is > necessary. However, and this makes perfect sense, all calls to > allowsNull() will return true, with exception to parameters that use > type hinting. Since type hinting does not cover primitives, this does > not cut it. > > I'm thinking that this boils down primarily to a PHPdoc issue. With > the @param tag in PEAR's PHPDocumentor, you can split types with a > pipe to indicate multiple acceptable types. So a "@param string|null > $var" could be used to determine if the parameter is nillable or not. > ReflectionParameter::allowsNull() could also be called to validate > claims of something being nillable, should it be not using type hints. > > This would require a change to how SCA parses doc blocks to support > piped types. However, probably there should be only one case where > multiple types can be defined (this case), as it doesn't make sense in > other SCA circumstances. > > Setting everything to nillable (as it currently does) does not make > sense as I see it. If a system does not get put into place that > allows for users to control how nillable is used in the generated > WSDL, as a minimum, I think it should be suppressed. I think it makes > more sense to assume all parameters as not accepting null values, then > the reverse. > > Thoughts? > > Mike > > On May 9, 8:02 am, Caroline Maynard <[EMAIL PROTECTED]> wrote: > > > Caplan, Michael wrote: > > > Forgive my ignorance, but why does the WSDL generator define all types > > > as nillable? Should that not be defined depending on the prototype of > > > the method it is bound to? > > > You're right, there's a lot of information available from the > > ReflectionParameter methods (allowsNull(), isOptional(), > > isDefaultValueAvailable(), ...) which isn't being exploited at the > > moment, but could potentially be used to improve the fidelity of the > > generated WSDL. It's likely that Matthew already thought about this when > > he developed that code and will know what the issues are. I'd say these > > enhancements sound like wish-list items for someone ... --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "phpsoa" group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~----------~----~----~----~------~----~------~--~---
