Skip to main content
Known Participant
July 8, 2008
Question

Process for adding a boolean option to the web service API

  • July 8, 2008
  • 4 replies
  • 633 views
Hey guys,

Here's a little background:

I'm currently working on adding an optional "strict" mode to some of the unmarshalling functions in SchemaMarshaller that will throw exceptions when receiving bad data for certain fields, and also improving the date handling while I'm at it (I want null instead of mangled dates when receiving bad data when strict mode is off).


This is for my benefit at the moment as I'm tired of spending time debugging Flex code when XFire and Oracle are spitting out rubbish (like empty xsd:DateTime nodes, DateTimes in xsd:Date nodes, etc) - but I'm sure other people would like to use it too while we don't have a response validator, so I'd like to do it in a way that I can submit as a feature request (with patch) on Jira.


My questions are about the procedure for stuff like this- where should this option be made public in the API, and who would I talk to about it? Or would it be best for it to always be strict? - That's how I'd like it 🙂 Perhaps it should just log errors when it encounters bad data?


This is the first thing I'd like to "add" to the SDK rather than a simple bug-fix, so I just want to do things in a kosher manner. Sorry if I come across like a total noob :)

Cheers,

-Josh


--
"Therefore, send not to know For whom the bell tolls. It tolls for thee."

:: Josh 'G-Funk' McDonald
:: 0437 221 380 :: josh@gfunk007.com
This topic has been closed for replies.

4 replies

Known Participant
July 9, 2008
Thanks a lot Pete, that's a great starting point. Feel free to email me on or off-list if you'd like more info on what I'm messing about with. And don't worry, I'm pretty swamped at the moment too, so this is on my backburner at work, and after some IOC stuff and AS parsing utils in my home queue :)


-Josh

On Wed, Jul 9, 2008 at 1:18 PM, Peter Farland < member@adobeforums.com> wrote:

A new message was posted by Peter Farland in



Developers --

 Process for adding a boolean option to the web service API



Hey Josh,



I'm swamped at the moment but appreciate your interest and your

contributions to Flex and WebServices thus far. I'll try and get some

time to look into your specific request and what you're hoping to do at

the code level, but to answer your question about test cases, you should

consider the NIST testsuite for XML Schema datatypes.



BlazeDS has historically maintained the WebService implementation, so it

appears their test case for NIST based schema tests starts out here (and

refers to many data type test cases in the /nist subdirectory).



http://opensource.adobe.com/svn/opensource/blazeds/branches/3.0.x/qa/app


s/qa-regress/testsuites/flexunit/src/tests/flexunit/xml/NISTXMLSchemaTes


t.as



Pete




--
"Therefore, send not to know For whom the bell tolls. It tolls for thee."

:: Josh 'G-Funk' McDonald
:: 0437 221 380 :: josh@gfunk007.com
Participating Frequently
July 9, 2008
Hey Josh,<br /><br />I'm swamped at the moment but appreciate your interest and your<br />contributions to Flex and WebServices thus far. I'll try and get some<br />time to look into your specific request and what you're hoping to do at<br />the code level, but to answer your question about test cases, you should<br />consider the NIST testsuite for XML Schema datatypes.<br /><br />BlazeDS has historically maintained the WebService implementation, so it<br />appears their test case for NIST based schema tests starts out here (and<br />refers to many data type test cases in the /nist subdirectory).<br /><br />http://opensource.adobe.com/svn/opensource/blazeds/branches/3.0.x/qa/app<br />s/qa-regress/testsuites/flexunit/src/tests/flexunit/xml/NISTXMLSchemaTes<br />t.as<br /><br />Pete <br /><br />________________________________<br /><br />From: dznuts@gmail.com [mailto:dznuts@gmail.com] On Behalf Of Josh<br />McDonald<br />Sent: Tuesday, July 08, 2008 8:21 PM<br />To: flexsdk-dev@adobeforums.com<br />Subject: Re: Process for adding a boolean option to the web service API<br /><br /><br />A new message was posted by Josh McDonald in <br /><br />Developers --<br /> Process for adding a boolean option to the web service API<br /><br />Yeah I knew it'd have to be somewhere outside of SchemaMarshaller, as<br />it's [ExcludeClass] anyway so end users don't see it, nor is it<br />documented in the api docs. Just wasn't sure where it should be. I'll<br />have a think about it some more when I get some down time to work on it,<br />but webservice was where I was thinking it should be too. Didn't think<br />about having it settable on operation as well though, so thanks for that<br />:)<br /><br />Anybody know a good source of valid values for various XSI types (date<br />and DateTime mainly) for testing purposes? Or even who I should contact<br />to get access to that sort of thing? I assume the W3C will take 6 months<br />to answer me, and the answer will be "buy our $10,000 compliance testing<br />suite" or something along those lines.<br /><br />-Josh<br /><br />On Wed, Jul 9, 2008 at 9:46 AM, Matt Chotin <member@adobeforums.com><br />wrote:<br /><br /><br /> A new message was posted by Matt Chotin in<br /> <br /> Developers --<br /> Process for adding a boolean option to the web service API<br /> <br /> I think for a top-level user option I would put the new option<br />on the mx.rpc.soap.Operation class (I think that's the name). You'd<br />then have that propagate through to the underlying schema classes as<br />they are used. I'd then also add an option to the WebService class<br />itself, and basically in the Operation it should see if it has its own<br />value set and if not check the value on the WebService. We do this for<br />a couple of other flags too I think.<br /> <br /> End users in general wouldn't look at any classes other than the<br />WebService and maybe the Operation classes, so asking them to set<br />options on the schema classes themselves probably wouldn't work.<br /> <br /> Matt<br /> <br /> <br /><br /><br /><br />-- <br />"Therefore, send not to know For whom the bell tolls. It tolls for<br />thee."<br /><br />:: Josh 'G-Funk' McDonald<br />:: 0437 221 380 :: josh@gfunk007.com <br /><br /><br />________________________________<br /><br />View/reply at Process for adding a boolean option to the web service API<br /><a href=http://www.adobeforums.com/webx?13@@.59b5be89/1> <br />Replies by email are OK.<br />Use the unsubscribe<br /><a href=http://www.adobeforums.com/webx?280@@.59b5be89!folder=.3c060fa3> form<br />to cancel your email subscription.
Known Participant
July 8, 2008
Yeah I knew it'd have to be somewhere outside of SchemaMarshaller, as it's [ExcludeClass] anyway so end users don't see it, nor is it documented in the api docs. Just wasn't sure where it should be. I'll have a think about it some more when I get some down time to work on it, but webservice was where I was thinking it should be too. Didn't think about having it settable on operation as well though, so thanks for that :)


Anybody know a good source of valid values for various XSI types (date and DateTime mainly) for testing purposes? Or even who I should contact to get access to that sort of thing? I assume the W3C will take 6 months to answer me, and the answer will be "buy our $10,000 compliance testing suite" or something along those lines.


-Josh

On Wed, Jul 9, 2008 at 9:46 AM, Matt Chotin < member@adobeforums.com> wrote:

A new message was posted by Matt Chotin in



Developers --

 Process for adding a boolean option to the web service API



I think for a top-level user option I would put the new option on the mx.rpc.soap.Operation class (I think that's the name).  You'd then have that propagate through to the underlying schema classes as they are used.  I'd then also add an option to the WebService class itself, and basically in the Operation it should see if it has its own value set and if not check the value on the WebService.  We do this for a couple of other flags too I think.




End users in general wouldn't look at any classes other than the WebService and maybe the Operation classes, so asking them to set options on the schema classes themselves probably wouldn't work.



Matt




--
"Therefore, send not to know For whom the bell tolls. It tolls for thee."

:: Josh 'G-Funk' McDonald
:: 0437 221 380 :: josh@gfunk007.com
matt_chotin
Inspiring
July 8, 2008
I think for a top-level user option I would put the new option on the mx.rpc.soap.Operation class (I think that's the name). You'd then have that propagate through to the underlying schema classes as they are used. I'd then also add an option to the WebService class itself, and basically in the Operation it should see if it has its own value set and if not check the value on the WebService. We do this for a couple of other flags too I think.<br /><br />End users in general wouldn't look at any classes other than the WebService and maybe the Operation classes, so asking them to set options on the schema classes themselves probably wouldn't work.<br /><br />Matt<br /><br /><br />On 7/8/08 4:15 PM, "Josh McDonald" <member@adobeforums.com> wrote:<br /><br />A new discussion was started by Josh McDonald in<br /><br />Developers --<br /> Process for adding a boolean option to the web service API<br /><br />Hey guys,<br /><br />Here's a little background:<br /><br />I'm currently working on adding an optional "strict" mode to some of the unmarshalling functions in SchemaMarshaller that will throw exceptions when receiving bad data for certain fields, and also improving the date handling while I'm at it (I want null instead of mangled dates when receiving bad data when strict mode is off).<br /><br />This is for my benefit at the moment as I'm tired of spending time debugging Flex code when XFire and Oracle are spitting out rubbish (like empty xsd:DateTime nodes, DateTimes in xsd:Date nodes, etc) - but I'm sure other people would like to use it too while we don't have a response validator, so I'd like to do it in a way that I can submit as a feature request (with patch) on Jira.<br /><br />My questions are about the procedure for stuff like this- where should this option be made public in the API, and who would I talk to about it? Or would it be best for it to always be strict? - That's how I'd like it :) Perhaps it should just log errors when it encounters bad data?<br /><br />This is the first thing I'd like to "add" to the SDK rather than a simple bug-fix, so I just want to do things in a kosher manner. Sorry if I come across like a total noob :)<br /><br />Cheers,<br /><br />-Josh