Hi Graham,

Thanks for the feedback.  Last I checked against phpDocumentor output (and 
maybe I should validated this again), phpDocumentor will handle pipes for 
@param.  If I remember correctly, the @return parser uses the same parsing 
logic as the @param parser.  I too didn't see any mention of this in the 
phpDocumentor manual, but perhaps this is an omission.  Perhaps we could 
clarify this with the package developers. 

Otherwise, I do like # notation in the referenced schema.



-----Original Message-----
From: phpsoa@googlegroups.com on behalf of Graham Charters
Sent: Sat 5/12/2007 6:15 PM
To: phpsoa
Subject: [phpsoa] Re: nillable

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

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


On 11 May, 18:40, Michael Caplan <[EMAIL PROTECTED]>
> 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 ...

E-mail messages may contain viruses, worms, or other malicious code. By reading 
the message and opening any attachments, the recipient accepts full 
responsibility for taking protective action against such code. Henry Schein is 
not liable for any loss or damage arising from this message.

The information in this email is confidential and may be legally privileged. It 
is intended solely for the addressee(s). Access to this e-mail by anyone else 
is unauthorized.

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 

<<inline: winmail.dat>>

Reply via email to