Older

• Jul 31, 2009

  issue 10 ([RFC] Allow typed list input parameters.) reported by keesvdb   -   The usual @wsvalidate decorator looks like: @wsvalidate(int) def somecall(self, id): You can call this function like somecall?id=23 But for a project I want to input an array of integers, and I don't want to do this as a comma separated string. This is what i'd like: somecall?id=23&id=24 I want this decorator: @wsvalidate([int]) To get there, I changed this bit of code (~line 85) in iconv.py: converter = input_types[key] if converter == bool: converter = boolean_converter - kw[key] = converter(kw[key]) + if type(converter) == list: + converter = converter[0] + if type(kw[key]) != list: + kw[key] = [kw[key]] + kw[key] = map(lambda n: converter(n), kw[key]) + else: + kw[key] = converter(kw[key]) except ValueError: raise validators.Invalid( "%s value for the '%s' parameter is not a " This is a quick hack that 'works for me'. I'd like to hear how this may be handled by the framework in a better way. Including compatibility for SOAP, for example.

  The usual @wsvalidate decorator looks like: @wsvalidate(int) def somecall(self, id): You can call this function like somecall?id=23 But for a project I want to input an array of integers, and I don't want to do this as a comma separated string. This is what i'd like: somecall?id=23&id=24 I want this decorator: @wsvalidate([int]) To get there, I changed this bit of code (~line 85) in iconv.py: converter = input_types[key] if converter == bool: converter = boolean_converter - kw[key] = converter(kw[key]) + if type(converter) == list: + converter = converter[0] + if type(kw[key]) != list: + kw[key] = [kw[key]] + kw[key] = map(lambda n: converter(n), kw[key]) + else: + kw[key] = converter(kw[key]) except ValueError: raise validators.Invalid( "%s value for the '%s' parameter is not a " This is a quick hack that 'works for me'. I'd like to hear how this may be handled by the framework in a better way. Including compatibility for SOAP, for example.
• Jul 15, 2009

  issue 5 (Allow TGWS to work with TG 1.5) commented on by doug.hellmann   -   Thanks, keesvdb! I'll check out the extra patches you have.

  Thanks, keesvdb! I'll check out the extra patches you have.
• Jul 15, 2009

  issue 5 (Allow TGWS to work with TG 1.5) commented on by keesvdb   -   I'm actively using TG 1.1 (SVN r6033) and maintain the patches in public: http://github.com/kvdb/6pp/tree/master/src/patches I'm using python 2.5.2. It should all work fine. But on heavy API use, I experience memory leakage (think it occurs using SOAP), so when the TG process grows too big, I've got supervisord/memmon killing and restarting it. You might also check the build_tg.sh script in that repository, as it installs TG with its dependencies and applies the patches.

  I'm actively using TG 1.1 (SVN r6033) and maintain the patches in public: http://github.com/kvdb/6pp/tree/master/src/patches I'm using python 2.5.2. It should all work fine. But on heavy API use, I experience memory leakage (think it occurs using SOAP), so when the TG process grows too big, I've got supervisord/memmon killing and restarting it. You might also check the build_tg.sh script in that repository, as it installs TG with its dependencies and applies the patches.
• Jul 15, 2009

  issue 5 (Allow TGWS to work with TG 1.5) commented on by doug.hellmann   -   I'm running into import errors with the dispatch module under Python 2.6.2 and TG 1.1. Going to TG 1.0 isn't an option for me. Is TGWS still being maintained? Is this patch still valid?

  I'm running into import errors with the dispatch module under Python 2.6.2 and TG 1.1. Going to TG 1.0 isn't an option for me. Is TGWS still being maintained? Is this patch still valid?
• Jun 12, 2009

  18 new revisions pushed by cdevienne   -   Revision 9aa96d5d20:Initial directory structure. Revision 041c44418a:Initial import of existing project Revision 79e564051b:Make tgws work on python 2.5 without the need of the external cElementTree and by also correcting the namespace clash of the xml module. Revision 4f4c527121:fix a stupid import error. Revision 726bd3c664:Commit issue #3 : read-write typedproperty attributes can be used on complex types with xml and json input. SOAP support still needs to be validated. Revision ac35240d89:Apply patch from issue 1 : Unicode value can now be returned by the xml frontend. Revision 34b87eea73: * Make use of xml.etree with python 2.5 instead of cElementTree * Add a unitest for read-write typed properties with soap. Revision 50166b0aa4:Prepare the next release: * Version bump * Update the URL and the email * Wrap long lines in description Revision 78b7e91f9b:Filter out the classical properties from complex types. This allow to create internal properties that will not get published without having to prefix them. Revision 518e844541:Fix issue #6 . Since the issue is related to TG1.0.7 handling of the content-type response header, it is now required to have a consistent behavior Revision 786678270c:Version bump Revision 0173fdbf4f:Adding a Sphinx extension to auto-documention a TGWebServices API. Revision 99fe9ebb79:Update dependencies Revision 03f70d5499:update tags Revision 08f4d3da0e:Added ignored file patterns. Revision cdaaf3d410:Increase version for the next release (nothing planned yet) Revision cbcccacc05:Adapted the tgws Sphinx extension to Sphinx 0.6.x Revision f7cae2b2d8:Document the Sphinx extension

  Revision 9aa96d5d20:Initial directory structure. Revision 041c44418a:Initial import of existing project Revision 79e564051b:Make tgws work on python 2.5 without the need of the external cElementTree and by also correcting the namespace clash of the xml module. Revision 4f4c527121:fix a stupid import error. Revision 726bd3c664:Commit issue #3 : read-write typedproperty attributes can be used on complex types with xml and json input. SOAP support still needs to be validated. Revision ac35240d89:Apply patch from issue 1 : Unicode value can now be returned by the xml frontend. Revision 34b87eea73: * Make use of xml.etree with python 2.5 instead of cElementTree * Add a unitest for read-write typed properties with soap. Revision 50166b0aa4:Prepare the next release: * Version bump * Update the URL and the email * Wrap long lines in description Revision 78b7e91f9b:Filter out the classical properties from complex types. This allow to create internal properties that will not get published without having to prefix them. Revision 518e844541:Fix issue #6 . Since the issue is related to TG1.0.7 handling of the content-type response header, it is now required to have a consistent behavior Revision 786678270c:Version bump Revision 0173fdbf4f:Adding a Sphinx extension to auto-documention a TGWebServices API. Revision 99fe9ebb79:Update dependencies Revision 03f70d5499:update tags Revision 08f4d3da0e:Added ignored file patterns. Revision cdaaf3d410:Increase version for the next release (nothing planned yet) Revision cbcccacc05:Adapted the tgws Sphinx extension to Sphinx 0.6.x Revision f7cae2b2d8:Document the Sphinx extension
• Apr 23, 2009

  r16 (Update dependencies) committed by cdevienne   -   Update dependencies

  Update dependencies
• Apr 15, 2009

  issue 9 (Dependencies...) reported by eprparadocs   -   You might want to inform people that Genshi is one of the dependencies. Without tgsw will not install and will give an interesting error about not having write permission to the egg cache directory.

  You might want to inform people that Genshi is one of the dependencies. Without tgsw will not install and will give an interesting error about not having write permission to the egg cache directory.
• Apr 06, 2009

  issue 8 (TGWS 1.2.2 DOCTYPE removal in SOAP WDSL) reported by keesvdb   -   The following patch keeps the the SOAP WSDL from having a DOCTYPE header just below the <?xml ?> definition while using TG 1.1.

  The following patch keeps the the SOAP WSDL from having a DOCTYPE header just below the <?xml ?> definition while using TG 1.1.
• Mar 05, 2009

  issue 7 (JSONP support for TGWS 1.2.2) reported by keesvdb   -   This patch adds JSONP support to TGWS. I'm not sure if I've covered all cases, but the added test passes ;-)

  This patch adds JSONP support to TGWS. I'm not sure if I've covered all cases, but the added test passes ;-)
• Jan 12, 2009

  issue 5 (Allow TGWS to work with TG 1.5) commented on by keesvdb   -   Also applies (using patch -p1) to TGWS 1.2.2. Also works with TG 1.1 (tested with r6033).

  Also applies (using patch -p1) to TGWS 1.2.2. Also works with TG 1.1 (tested with r6033).
• Dec 15, 2008

  r15 (Adding a Sphinx extension to auto-documention a TGWebService...) committed by cdevienne   -   Adding a Sphinx extension to auto-documention a TGWebServices API.

  Adding a Sphinx extension to auto-documention a TGWebServices API.
• Dec 08, 2008

  issue 4 (Missing templates/wsdl.html in both source and egg distribu...) Status changed by cdevienne   -   The problem did not occur when releasing 1.2.2.

  Status: Fixed

  The problem did not occur when releasing 1.2.2.

  Status: Fixed
• Dec 08, 2008

  r14 (Releasing TGWebServices 1.2.2 ) committed by cdevienne   -   Releasing TGWebServices 1.2.2

  Releasing TGWebServices 1.2.2
• Dec 08, 2008

  r13 (Version bump) committed by cdevienne   -   Version bump

  Version bump
• Dec 08, 2008

  issue 6 (XML output is not totally valid) Status changed by cdevienne   -   This issue is related to a change in how TG 1.0.7 handle the response content type header. A fix has been commited in r12.

  Status: Fixed

  This issue is related to a change in how TG 1.0.7 handle the response content type header. A fix has been commited in r12.

  Status: Fixed
• Dec 08, 2008

  r12 (Fix issue #6. Since the issue is related to TG1.0.7 handling...) committed by cdevienne   -   Fix issue #6 . Since the issue is related to TG1.0.7 handling of the content-type response header, it is now required to have a consistent behavior

  Fix issue #6 . Since the issue is related to TG1.0.7 handling of the content-type response header, it is now required to have a consistent behavior
• Nov 10, 2008

  issue 6 (XML output is not totally valid) commented on by keesvdb   -   Patch to return XML mimetype headers.

  Patch to return XML mimetype headers.
• Nov 05, 2008

  issue 6 (XML output is not totally valid) commented on by keesvdb   -   I'm using TG 1.0 r5549.

  I'm using TG 1.0 r5549.
• Nov 05, 2008

  issue 6 (XML output is not totally valid) reported by keesvdb   -   Christophe, as discussed: > In xml_.py, it clearly states: > > def get_content_type(self, user_agent): > return "text/xml" > > But the result I see is just text/html: > Response Headers - http://6pp.kvdb.net/lookup?postcode=2987XS > Date: Tue, 04 Nov 2008 21:36:14 GMT > Server: CherryPy/2.3.0 > Content-Length: 224 > Content-Type: text/html; charset=utf-8 > Via: 1.1 6pp.kvdb.net > Keep-Alive: timeout=15, max=99 > Connection: Keep-Alive > > 200 OK > > I tried fiddling with cherrypy headers to return text/xml, but that didn't make a difference.

  Christophe, as discussed: > In xml_.py, it clearly states: > > def get_content_type(self, user_agent): > return "text/xml" > > But the result I see is just text/html: > Response Headers - http://6pp.kvdb.net/lookup?postcode=2987XS > Date: Tue, 04 Nov 2008 21:36:14 GMT > Server: CherryPy/2.3.0 > Content-Length: 224 > Content-Type: text/html; charset=utf-8 > Via: 1.1 6pp.kvdb.net > Keep-Alive: timeout=15, max=99 > Connection: Keep-Alive > > 200 OK > > I tried fiddling with cherrypy headers to return text/xml, but that didn't make a difference.
• Aug 09, 2008

  issue 5 (Allow TGWS to work with TG 1.5) reported by keesvdb   -   The attached patch restores (at least some) functionality when running TGWS with TurboGears 1.5 (r5113) I've tested simple xml and json output, that works. The complete test suite still fails though.

  The attached patch restores (at least some) functionality when running TGWS with TurboGears 1.5 (r5113) I've tested simple xml and json output, that works. The complete test suite still fails though.