[phpsoa] Re: Time for DUNLIN to peck its way out?
Hi Caroline, Thanks for the clarification. As I see it TUSCANY-1297 should be assigned to #11012. #11004 is an issue that I feel I was able to solve by hacking the SCA WSDL generator code. I think Matthew may disagree with my raised issue (looking forward to his response), but it is entirely solvable in the PHP code. Best, Mike -Original Message- From: phpsoa@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Caroline Maynard Sent: June 11, 2007 12:15 PM To: phpsoa@googlegroups.com Subject: [phpsoa] Re: Time for DUNLIN to peck its way out? Michael Caplan wrote: I'd like to petition to get Bug #11004 (WSDL Generated Does Not Validate) and Request #10994 (Business Exceptions Data Returned to Client) in this release. Judging from [EMAIL PROTECTED] (sorry not sure who that is) final comment on #11004, I think this ticket is being confused with Request #11012 (Visual Studio Consumption of SCA Generated WSDL) as suggested by the referenced by the Tuscany ticket. I believe #11012 should have the Tuscany ticket associated. If #11004 is being confused, I'd like to raise it hear again. The gist of #11004 is WSDL validation, and if I am correct about this, the fix seems to be simple, and outlined in the ticket. It was me, but only from the point of view of getting that bug processed according to our standard procedure for handing off bugs to Tuscany. Matthew had already raised it as a Tuscany JIRA, and my contribution was to update his link from 11004 to the Tuscany defect with one that would be clickable from within the PECL bug tracker. The Tuscany issue: http://issues.apache.org/jira/browse/TUSCANY-1297 is indeed the one about suppressing the xsi:type attribute, so I see what you mean. But I'm not sure whether the other one is also in Tuscany or in Matthew's WSDL generation code. I'll hope that he responds ... 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 http://groups.google.co.uk/group/phpsoa?hl=en -~--~~~~--~~--~--~---
[phpsoa] Re: nillable
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 element http://Schema_NameSpace Description
Becomes:
@return http://Schema_NameSpace#element Description
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:
* @return http://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 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
[phpsoa] Re: nillable
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
* @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 ...
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
[phpsoa] Re: Off Topic. Visual Studio WS Consuming
Hi Simon,
Thanks again for your feedback. The example code is immensely helpful.
Unfortunately, I seem to be suffering from a Visual Studio issue related
to the consumption of the WSDL. If I understand how web services work
in Visual Studio C#, it generates proxy code that handles routing web
service calls. The proxy code is built off of the imported web
reference WSDL.
The WSDL imports fine as a web reference, with the noted WSDL mods.
But, VS seems to be chocking on the creation of this proxy code. I'm
getting an error when building that DiscoCodeGenerator unable to
initialize code generator. No code generated.
This doesn't seem to be an isolated issue (Google brings up many hits),
although I can't find anything on MSDN about this. I also can't find
any meaningful details on this issue, other than other people have run
across it. I can't for the life of me figure out how to debug this
DiscoCodeGenerator error. My best guess is, contrary to the simple
Hello World example, I have defined many imported schema types. Maybe
it is chocking on that?.!?!
Best,
Mike
-Original Message-
From: phpsoa@googlegroups.com [mailto:[EMAIL PROTECTED] On
Behalf Of [EMAIL PROTECTED]
Sent: May 14, 2007 6:39 AM
To: phpsoa
Subject: [phpsoa] Re: Off Topic. Visual Studio WS Consuming
Hi Mike
I had a go at this a while back so I repeated the simple experiment I
carried out back then. I took the greeting.wsdl from examples/SCA/
helloworldscawsservice/wsdl. I fixed it to remove the xsi:type
attributes ( :-( need to fix this) and then imported it into my
VisualStudio environment. Now I currently have a fairly old 2003 copy
of VS.net so your experience may differ but I imported it as a web
reference.
I then wrote a little bit of C# relying heavily on code completion to
tell me what to do.
using System;
namespace HelloWorld
{
/// summary
/// Summary description for Class1.
/// /summary
class Class1
{
/// summary
/// The main entry point for the application.
/// /summary
[STAThread]
static void Main(string[] args)
{
//
// TODO: Add code to start application here
//
Console.WriteLine(Hello World Test);
WebReference1.GreetingService greetingService =
new
WebReference1.GreetingService();
WebReference1.greet request = new
WebReference1.greet();
request.name = Fred;
WebReference1.greetResponse response =
greetingService.greet(request);
Console.WriteLine(response.greetReturn);
}
}
}
I then ran up the PHP SCA samples by copying examples into htdocs.
Then I ran this C# app in a console and got.
C:\simon\Projects\VisualStudio\phpsoa\HelloWorld\bin
\DebugHelloWorld.exe
Hello World Test
hello Fred
Clearly not an exhaustive test but it can be made to work at the very
basic level.
Hope that helps
Simon
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
http://groups.google.co.uk/group/phpsoa?hl=en
-~--~~~~--~~--~--~---
[phpsoa] Off Topic. Visual Studio WS Consuming
Hi there, Sorry for the (slightly) off topic posting. I'm wondering if anyone has had any success consuming a SCA web service in Visual Studio (VB or C#)? I know very, very little about VB, C#, and Visual Studio. But, I want to make sure that end users of my service can actually consume it in this environment. I've gotten as far as fixing the SCA generated WSDL so VS can create a reference to it. Beyond that, all the online tutorials I've come across just aren't doing it. I'm not sure if I am rubbing against VS issues, or SCA WSDL issues. Is there anyone out there that has had success in this area that I can toss a few questions off of? Super appreciate it, Mike 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 http://groups.google.co.uk/group/phpsoa?hl=en -~--~~~~--~~--~--~---
