[phpsoa] Re: nillable

[Graham Charters]

Hi Mike,

Thanks for clarifying the use of pipe with the phpDocumentor
developer.

Yes, the # notation was simply an alternative way to identify a
complex type in a schema.  It's largely orthogonal to nillable but I
mentioned it for a few reasons:

1.  To raise the idea of us making both changes together since they
will be in the same area of code.
2.  As an example where we could improve preserving the phpDocumentor
generation (at the moment the namespace gets generated into the
description :-( ).
3.  To solicit more feedback.

My apologies if I caused some confusion.  I hope this helps clarify my
intentions.

Graham.

On 15 May, 18:14, Caplan, Michael [EMAIL PROTECTED]
wrote:
 Hi Matthew,

 I guess I am a little confused about the # notation that Graham outlined
 (and wondered if that was just a slightly different way to handle the
 problem).  Am I correct that Graham is getting at a new notation for
 specifying elements from a schema?

 IE:

 @return elementhttp://Schema_NameSpaceDescription

 Becomes:

 @returnhttp://Schema_NameSpace#elementDescription

 As for implementing pipe support in types, I spent some time in the code
 thinking through what this could programmatically look like.  But, I'm
 not so sure about the structural changes I came up with and possible
 side effects.  Also, I wouldn't want to interfere with an architecture
 choices that may be tied to future initiatives.  This said, I could
 submit a patch if it would be of assistance, but I wouldn't be able to
 get to it for at least a week.  The sort of it, yes please implement it.
 Let me know if I can help in any way.

 Best,

 Mike





  -Original Message-
  From: phpsoa@googlegroups.com [mailto:[EMAIL PROTECTED] On
  Behalf Of Matthew Peters
  Sent: May 15, 2007 1:47 PM
  To: phpsoa
  Subject: [phpsoa] Re: nillable

  (Joining this thread a week late :-))

  Mike, you have done a fantastic job of researching the options. I'm
  puzzled why you say _two_ options: isn't there just one surviving
  idea, which is what you and Graham have converged upon, the use of the
  pipe symbol for both @param and @return, as in:
* @returnhttp://example.org/contacts#contact|null The full
  contact details

  I agree that this is a fine idea. Would you like me to go ahead and
  implement it? The parsing of the annotations is a bit of a rough area
  of the code so it does not seem fair that you should have to implement
  it as well, especially as you have made several other contributions in
  quick succession recently. But you would however be very welcome to do
  so if you wanted :-)

  Matthew

  On May 14, 2:37 pm, Caplan, Michael [EMAIL PROTECTED]
  wrote:
   Hi Graham,

   FYI, I just got word back from a PHPDocumentor developer re: @param
   support for multiple types:

   Hello Mike,

   That functionality is both in there and supported, though it looks
  like
   we could improve on how we demonstrate it in our manual.  I've
 opened
   PEAR bug #11032
   (http://pear.php.net/bugs/bug.php?id=11032) to get the manual
 updated
   with better examples showing that param type1|type2 usage, and
 will
   also add more detail to the return tag's doc.

   Thanks for the posting...
   Chuck

   Now that we know that this is supported behavior, any thoughts on
 the
   two outlined methods for supporting nillable parameters?

   Best,

   Mike

-Original Message-
From: phpsoa@googlegroups.com [mailto:[EMAIL PROTECTED] On
Behalf Of Graham Charters
Sent: May 12, 2007 6:16 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
@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
 * @typeshttp://example.org/contactscontacts.xsd
 *
 */
class ContactService {

/**
 * Retrieve contact details
 *
 * @param string|null $shortname The short name of the contact
 * @returnhttp://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 

[phpsoa] Re: How much data should flow back from a business exception?

[Graham Charters]

I think Mike is right that we shouldn't always flow this information.
It is a potential security hole as it could divulge more information
than we would like.  I had similar concerns about the information we
flow back in http responses for things like Atompub and the conclusion
was to not give any implementation details away.

I think we have two scenarios here, which are potentially conflicting.

1.  I want to expose a service to a thirdparty and only want to flow
back information relation to the integration of our businesses
(business exceptions without any implementation detail).
2.  I want to be able to define 'module' boundaries which can be
running on the same server or potentially remote.  I want the same
semantics and details to flow across the interfaces, including
exception details when remote using Web services (this is within my
organisation).

I can think of a couple ways to resolve this:

1.  We give the developer more control over what flows (either through
a config setting or through the exceptions they throw (perhaps one
class of exception (e.g business) does not flow backtrace, and another
class (e.g. system) does.  It's then up to the developer to define
which services are business boundaries and which are module
boundaries.
2.  We create another binding (there is this concept of binding.sca in
the specifications), whos purpose is to be used for scenario 2.  This
binding would flow the backtrace, and we would remove the backtrace
for binding.soap.

Graham.



On 15 May, 18:08, Matthew Peters [EMAIL PROTECTED]
wrote:
 Mike Caplan (in pecl bug #10994) has raised the question of whether,
 when a business exception is raised in a component that has been
 called remotely - through a web service, say - the exception should be
 serialised and flowed back, then deserialised and rethrown in its
 entirety on the calling end. At the moment the exception is recreated
 in loving detail, with the same backtrace, line number, file name,
 that it had on the remote end. This makes the exception identical
 regardless of whether the components are local or remote. Mike
 suggests that that is too much information and it would be better to
 keep just the text and number. I can see his point. Perhaps it was a
 step too far to flow back the backtrace. One possibility is to put the
 behaviour under control of a config setting somewhere.

 What do other people think?

 Matthew


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---