This list is closed, nobody may subscribe to it.
2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(149) |
Jun
(174) |
Jul
(41) |
Aug
(118) |
Sep
(72) |
Oct
(111) |
Nov
(69) |
Dec
(147) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(242) |
Feb
(276) |
Mar
(363) |
Apr
(704) |
May
(183) |
Jun
(209) |
Jul
(173) |
Aug
(230) |
Sep
(80) |
Oct
(306) |
Nov
(338) |
Dec
(291) |
2002 |
Jan
(273) |
Feb
(294) |
Mar
(303) |
Apr
(463) |
May
(319) |
Jun
(182) |
Jul
(160) |
Aug
(140) |
Sep
(192) |
Oct
(302) |
Nov
(238) |
Dec
(176) |
2003 |
Jan
(179) |
Feb
(222) |
Mar
(256) |
Apr
(167) |
May
(139) |
Jun
(145) |
Jul
(113) |
Aug
(259) |
Sep
(146) |
Oct
(124) |
Nov
(143) |
Dec
(66) |
2004 |
Jan
(58) |
Feb
(128) |
Mar
(193) |
Apr
(228) |
May
(111) |
Jun
(107) |
Jul
(93) |
Aug
(78) |
Sep
(48) |
Oct
(99) |
Nov
(104) |
Dec
(119) |
2005 |
Jan
(115) |
Feb
(124) |
Mar
(86) |
Apr
(41) |
May
(52) |
Jun
(21) |
Jul
(32) |
Aug
(14) |
Sep
(52) |
Oct
(30) |
Nov
(19) |
Dec
(19) |
2006 |
Jan
(43) |
Feb
(35) |
Mar
(68) |
Apr
(21) |
May
(38) |
Jun
(46) |
Jul
(19) |
Aug
(38) |
Sep
(58) |
Oct
(15) |
Nov
(12) |
Dec
(30) |
2007 |
Jan
(49) |
Feb
(23) |
Mar
(29) |
Apr
(19) |
May
(33) |
Jun
(4) |
Jul
(10) |
Aug
(26) |
Sep
(2) |
Oct
(9) |
Nov
(1) |
Dec
(21) |
2008 |
Jan
(15) |
Feb
(3) |
Mar
(10) |
Apr
(8) |
May
(4) |
Jun
(2) |
Jul
(2) |
Aug
|
Sep
|
Oct
(2) |
Nov
(13) |
Dec
|
2009 |
Jan
(11) |
Feb
(4) |
Mar
|
Apr
(6) |
May
|
Jun
(16) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(9) |
2010 |
Jan
(6) |
Feb
(4) |
Mar
(2) |
Apr
(12) |
May
(20) |
Jun
(9) |
Jul
(7) |
Aug
|
Sep
(1) |
Oct
(5) |
Nov
|
Dec
(4) |
2011 |
Jan
|
Feb
|
Mar
(10) |
Apr
|
May
|
Jun
|
Jul
(9) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
2012 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(6) |
Oct
(3) |
Nov
(8) |
Dec
(11) |
2013 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(6) |
Dec
|
2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
(2) |
Dec
|
2017 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
(3) |
Dec
|
2020 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
2021 |
Jan
(1) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2022 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
(2) |
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Christoph Z. <ci...@on...> - 2010-06-08 20:56:21
|
Am 08.06.2010 21:44 schrieb Steve Schwarz: > Yep. Looks like we are experiencing GIL contention on our compute heavy > pages. Refactoring is also going on in the application to solve that > problem. Adding an alternative to the MultiThreadedAppServer has been on my todo list for Webware for quite a while already (at least as long we're still running on Python 2 - the GIL may become less problematic with Py 3.2). Maybe a MultiProcessAppServer could be the alternative or somethin with an approach like Concurrence or Twisted. -- Christoph |
From: Steve S. <st...@ag...> - 2010-06-08 19:50:49
|
On Tue, Jun 8, 2010 at 2:35 PM, Christoph Zwerschke <ci...@on...> wrote: > Am 08.06.2010 21:27 schrieb Steve Schwarz: > > We'd like to simplify our deployment. Now our admins have to install > > Webware multiple times for each appserver instance on multiple servers. > > It would be easier to just deploy once and have all instance refer to > > that one check out. > > Ok, as I understand, your working dir is on a shared directory? > In the process pool install each server would have one checkout shared by 10-20 SingleThreadedAppServer Webware instances. > > > We also see better performance running with a pool of single threaded > > appservers instead of using the ThreadedAppServer. > > Are you using multi-core/multi-processing machines? > Yep. Looks like we are experiencing GIL contention on our compute heavy pages. Refactoring is also going on in the application to solve that problem. Steve |
From: Christoph Z. <ci...@on...> - 2010-06-08 19:35:47
|
Am 08.06.2010 21:27 schrieb Steve Schwarz: > We'd like to simplify our deployment. Now our admins have to install > Webware multiple times for each appserver instance on multiple servers. > It would be easier to just deploy once and have all instance refer to > that one check out. Ok, as I understand, your working dir is on a shared directory? > We also see better performance running with a pool of single threaded > appservers instead of using the ThreadedAppServer. Are you using multi-core/multi-processing machines? -- Christoph |
From: Steve S. <st...@ag...> - 2010-06-08 19:27:29
|
On Tue, Jun 8, 2010 at 2:00 PM, Christoph Zwerschke <ci...@on...> wrote: > Am 07.06.2010 22:00 schrieb Steve Schwarz: > > We are looking to run multiple Webware instances from a single Webware > > directory/checkout and can do so by providing configuration differences > > via command line args. > > Just out of curiosity, why do you want to do that? I'm usually running > different instances from different working dirs only. > We'd like to simplify our deployment. Now our admins have to install Webware multiple times for each appserver instance on multiple servers. It would be easier to just deploy once and have all instance refer to that one check out. We also see better performance running with a pool of single threaded appservers instead of using the ThreadedAppServer. So we are looking to substantially increase the number of AppServers running and don't want to setup dozens of Webware directories that only differ in port number and some logging parameters. > > But I noticed that ThreadedAppServer.addSocketHandler() creates files > > like http.address and adapter.address containing the address:port for > > each adapter: ... > > Can anyone explain the purpose? Trying to stop running multiple > > appservers on the same address/port? If so the port will already be > > bound so the appserver will fail... > > I think they are only used as a way to communicate the appserver port to > some of the adapters, e.g. the CGIAdapter. > We're only using the HTTP adapter for our current tests and it didn't seem to care if that file exists. So I didn't look any further... > > If you start a second instance, the file should be overwritten with a > warning, doesn't this work for you? > > If you don't want this, you can set a different name for it in the 2nd > instance via the AppServer setting "AddressFiles", e.g. '%s.address2' > Thanks I didn't see that config. We'll just specify it also on the command line and now I won't have to override addSocketHandler() anymore > see > > http://www.webwareforpython.org/WebKit/Docs/Configuration.html#appserver-config > > -- Christoph > Best Regards, Steve |
From: Christoph Z. <ci...@on...> - 2010-06-08 19:01:04
|
Am 07.06.2010 22:00 schrieb Steve Schwarz: > We are looking to run multiple Webware instances from a single Webware > directory/checkout and can do so by providing configuration differences > via command line args. Just out of curiosity, why do you want to do that? I'm usually running different instances from different working dirs only. > But I noticed that ThreadedAppServer.addSocketHandler() creates files > like http.address and adapter.address containing the address:port for > each adapter: ... > Can anyone explain the purpose? Trying to stop running multiple > appservers on the same address/port? If so the port will already be > bound so the appserver will fail... I think they are only used as a way to communicate the appserver port to some of the adapters, e.g. the CGIAdapter. If you start a second instance, the file should be overwritten with a warning, doesn't this work for you? If you don't want this, you can set a different name for it in the 2nd instance via the AppServer setting "AddressFiles", e.g. '%s.address2' see http://www.webwareforpython.org/WebKit/Docs/Configuration.html#appserver-config -- Christoph |
From: Steve S. <st...@ag...> - 2010-06-07 21:07:14
|
Hi, We are looking to run multiple Webware instances from a single Webware directory/checkout and can do so by providing configuration differences via command line args. But I noticed that ThreadedAppServer.addSocketHandler() creates files like http.address and adapter.address containing the address:port for each adapter: # write text file with server address adrFile = self.addressFileName(handlerClass) if os.path.exists(adrFile): print "Warning: %s already exists" % adrFile try: os.unlink(adrFile) except OSError: # we cannot remove the file if open(adrFile).read() == adrStr: return # same content, so never mind else: print "Error: Could not remove", adrFile sys.stdout.flush() raise try: f = open(adrFile, 'w') f.write(adrStr) f.close() except IOError: print "Error: Could not write", adrFile sys.stdout.flush() raise Can anyone explain the purpose? Trying to stop running multiple appservers on the same address/port? If so the port will already be bound so the appserver will fail... Thanks, Steve |
From: Christoph Z. <ci...@on...> - 2010-05-16 12:58:48
|
Am 15.05.2010 23:56 schrieb Roger Haase: > For the benefit of anyone else who is using flush on a few long > running transactions, mod_deflate can be turned off for a single > servlet by adding a line to the apache conf: > SetEnvIf Request_URI ^/webkit/MyXaction no-gzip=1 Thanks for the feedback. I've addded this and hints about other possbile to the flush() docstring now. -- Christoph |
From: Roger H. <cro...@ya...> - 2010-05-15 21:57:04
|
--- On Fri, 5/14/10, Christoph Zwerschke <ci...@on...> wrote: > From: Christoph Zwerschke <ci...@on...> > Subject: Re: [Webware-discuss] self.response().flush() on 1.1b1 with WSGI > To: "Discussion of Webware for Python including feedback and proposals." <web...@li...> > Date: Friday, May 14, 2010, 1:14 PM > Am 14.05.2010 20:26 schrieb Roger > Haase: > > I use a call to self.response().flush() on a couple of > long running > > transactions. With the WSGI adapter on 1.1.b1 > the transaction runs > > to completion, but nothing is transferred until the > transaction > > completes. > > > > I haven't tested this with other adapters. > Anyone else notice this? > > Just tested it with mod_webkit, mod_scgi and mod_wsgi and > it worked > nicely with all of them. > > Are you sure you're using the adapter? It does not work > with the > built-in webserver. Also, some Firefox plugins tend to pile > up response > data. Did you test with different browsers? > > There have been some changes to the WSGI adapter after > 1.1b1, you can > try with the current version (but it should also work with > 1.1b1): > http://svn.webwareforpython.org/Webware/trunk/WebKit/Adapters/WSGIAdapter.py > > -- Christoph I am bringing up a new server with Ubuntu 10.04. The problem was that Apache now comes with mod_deflate on by default and mod_deflate waits for and compresses the entire transaction's output before sending it on. For the benefit of anyone else who is using flush on a few long running transactions, mod_deflate can be turned off for a single servlet by adding a line to the apache conf: SetEnvIf Request_URI ^/webkit/MyXaction no-gzip=1 Thanks for all your help on the Webware enhancements Christoph! Roger Haase |
From: Christoph Z. <ci...@on...> - 2010-05-14 20:15:06
|
Am 14.05.2010 20:26 schrieb Roger Haase: > I use a call to self.response().flush() on a couple of long running > transactions. With the WSGI adapter on 1.1.b1 the transaction runs > to completion, but nothing is transferred until the transaction > completes. > > I haven't tested this with other adapters. Anyone else notice this? Just tested it with mod_webkit, mod_scgi and mod_wsgi and it worked nicely with all of them. Are you sure you're using the adapter? It does not work with the built-in webserver. Also, some Firefox plugins tend to pile up response data. Did you test with different browsers? There have been some changes to the WSGI adapter after 1.1b1, you can try with the current version (but it should also work with 1.1b1): http://svn.webwareforpython.org/Webware/trunk/WebKit/Adapters/WSGIAdapter.py -- Christoph |
From: Roger H. <cro...@ya...> - 2010-05-14 18:26:50
|
I use a call to self.response().flush() on a couple of long running transactions. With the WSGI adapter on 1.1.b1 the transaction runs to completion, but nothing is transferred until the transaction completes. I haven't tested this with other adapters. Anyone else notice this? Roger Haase |
From: Christoph Z. <ci...@on...> - 2010-05-14 12:04:36
|
Am 13.05.2010 18:14 schrieb Georg Balmer: > Next I try generate the code for the "form_template" using "WebHelpers". > HTMLgeneration is mentioned in the "future" list. > Has this something to do with what I try to do with Webhelpers? Yes, webhelpers.html seems to do these things. Maybe it's good enough. -- Christoph |
From: Georg B. <gb...@bl...> - 2010-05-13 16:14:44
|
I am all set now for working on the wiki. Thanks for your tip. The revamped FormEncode example shows me the correct schema specifications for the color checkboxes. The usage for "preAction" and "postAction" is new to me. Next I try generate the code for the "form_template" using "WebHelpers". HTMLgeneration is mentioned in the "future" list. Has this something to do with what I try to do with Webhelpers? Regards Georg ------------------------------------------------------------------- Am 13.05.2010 17:03, schrieb Christoph Zwerschke: > Am 13.05.2010 15:39 schrieb Georg Balmer: > > I tried to find a way how I could work offline on my Sphinx document > > an then upload the document to the wiki, but I didn't succeed. > > Do you have a hint for a wiki dummy? > > Since both Sphinx and Wiki use ReST format, you can just click on "Edit > -> Edit this page" and then post your content using cut& paste. > > Btw, I just fixed the original Webware example in FormEncode which was > broken because of the missing HTMLForms and had some more small problems > (e.g. the Unicode issue you reported). It works nicely now with both > Webware 1.1 and Paste WebKit. > > -- Christoph > > ------------------------------------------------------------------------------ > > _______________________________________________ > Webware-discuss mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webware-discuss > |
From: Christoph Z. <ci...@on...> - 2010-05-13 15:03:28
|
Am 13.05.2010 15:39 schrieb Georg Balmer: > I tried to find a way how I could work offline on my Sphinx document > an then upload the document to the wiki, but I didn't succeed. > Do you have a hint for a wiki dummy? Since both Sphinx and Wiki use ReST format, you can just click on "Edit -> Edit this page" and then post your content using cut & paste. Btw, I just fixed the original Webware example in FormEncode which was broken because of the missing HTMLForms and had some more small problems (e.g. the Unicode issue you reported). It works nicely now with both Webware 1.1 and Paste WebKit. -- Christoph |
From: Georg B. <gb...@bl...> - 2010-05-13 13:39:22
|
OK I just registered on the wiki an opened my first page. ===================== Formgen - First steps ===================== I tried to find a way how I could work offline on my Sphinx document an then upload the document to the wiki, but I didn't succeed. Do you have a hint for a wiki dummy? Regards Georg --------------------------------------------------------------------- Am 13.05.2010 14:05, schrieb Christoph Zwerschke: > Am 13.05.2010 07:42 schrieb Georg Balmer: > > What do I want? (random work in progress) > > Sounds good. Sphinx is already on our "future" list: > http://wiki.w4py.org/futurework.html > > You can use the Wiki to add recipes and tutorials as drafts; they don't > need to be polished. The Wiki and the existing docs can then be used as > a starting basis for creating the Sphinx docs (which should be tested > and proof-read). Anything that has become obsolete or has been taken > over to the Sphinx docs can then be removed from the Wiki. > > -- Christoph > > ------------------------------------------------------------------------------ > > _______________________________________________ > Webware-discuss mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webware-discuss > |
From: Christoph Z. <ci...@on...> - 2010-05-13 12:05:11
|
Am 13.05.2010 07:42 schrieb Georg Balmer: > What do I want? (random work in progress) Sounds good. Sphinx is already on our "future" list: http://wiki.w4py.org/futurework.html You can use the Wiki to add recipes and tutorials as drafts; they don't need to be polished. The Wiki and the existing docs can then be used as a starting basis for creating the Sphinx docs (which should be tested and proof-read). Anything that has become obsolete or has been taken over to the Sphinx docs can then be removed from the Wiki. -- Christoph |
From: Georg B. <gb...@bl...> - 2010-05-13 05:42:33
|
What do I want? (random work in progress) [1] Development path to port Webware applications using FunFormKit to Webware-1.1 and FormEncode + WebHelpers + ... with existing and new tools. [2] Development path for new Webware(?) applications with existing and new tools. [3] The target platform (at the time) for these applications is: . Linux CentOS . Apache . Python 2.4 . MySQL 5.0 [4] Documentation using Sphinx. To do [1] in a form that can be published on the Webware Wiki somebody must proofread my code and text. I am not a writer nor a very talented programmer. In doing [1] I gain the experience and knowledge to do [2]. My next steps are: . Using Webhelpers to generate the forms. .. first steps .. input specifications (repository in DB) Regards Georg --------------------------------------------------------------------------- Am 13.05.2010 00:33, schrieb Christoph Zwerschke: > > Actually I'm not using FormEncode with Webware, so I cannot contribute > any best practices to the Wiki, but the Wiki is editable by anybody. > > It would be nice if we could add a standard form validation and > generation plugin to Webware, though. There had been some attempts in > the past with FunFormKit and FormKit4Python, but nothing ever got > integrated and they are not maintained any more. > > -- Christoph > > ------------------------------------------------------------------------------ > > _______________________________________________ > Webware-discuss mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webware-discuss > |
From: Christoph Z. <ci...@on...> - 2010-05-12 22:33:11
|
Am 12.05.2010 10:00 schrieb Georg Balmer: > . elaborate examples "Fields OK-exit" That's simple, just add names to your submit buttons and check them with the hasField() method. Actually I'm not using FormEncode with Webware, so I cannot contribute any best practices to the Wiki, but the Wiki is editable by anybody. It would be nice if we could add a standard form validation and generation plugin to Webware, though. There had been some attempts in the past with FunFormKit and FormKit4Python, but nothing ever got integrated and they are not maintained any more. -- Christoph |
From: Georg B. <gb...@bl...> - 2010-05-12 08:00:01
|
Right now I have questions like: What's needed to get the basic example in an application? --------------------------------------------------------- . elaborate examples "Fields OK-exit" . References to helpful documentation like .. The Definitve Guide to Pylons (James Gardner): Chapter 6 ... Will be nice to have everything in one place on the wiki. Regards Georg ------------------------------------------------------------------------- Am 11.05.2010 23:09, schrieb Christoph Zwerschke: > Am 11.05.2010 13:33 schrieb Georg Balmer: > > Next step is your SchemaBuilder suggestion. > > Just tried it, but it doesn't seem to be very useful since you cannot > specify and validator arguments, and I had to fix some things first (see > http://bitbucket.org/cito/formencode/changeset/e39881f76131). > > I've added the examples to our Wiki now: > http://wiki.w4py.org/webwareandformencode.html > > -- Christoph > > ------------------------------------------------------------------------------ > > _______________________________________________ > Webware-discuss mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webware-discuss > |
From: Christoph Z. <ci...@on...> - 2010-05-11 21:10:04
|
Am 11.05.2010 13:33 schrieb Georg Balmer: > Next step is your SchemaBuilder suggestion. Just tried it, but it doesn't seem to be very useful since you cannot specify and validator arguments, and I had to fix some things first (see http://bitbucket.org/cito/formencode/changeset/e39881f76131). I've added the examples to our Wiki now: http://wiki.w4py.org/webwareandformencode.html -- Christoph |
From: Georg B. <gb...@bl...> - 2010-05-11 11:33:21
|
Thank your for your excellent help. The basic example works. Next step is your SchemaBuilder suggestion. Regards Georg --------------------------------------------------------------------- Am 11.05.2010 11:44, schrieb Christoph Zwerschke: > Am 11.05.2010 08:53, schrieb Georg Balmer: >> I got the example from a direct download from formencode.org: >> . [2] svn co http://svn.colorstudy.com/FormEncode/trunk FormEncode >> (examples directory: WebwareExamples/index.py) > > Thanks, I was not aware of that example. Seems it was actually written > for Paste WebKit (http://pythonpaste.org/webkit/). > > As you noticed it uses htmlform which is deprecated; you must use > htmlfill directly. You must also add a name="color" attribute to the > checkboxes to make these work. > > It seems your problem is that the formencode errors are now unicode, so > you must encode these. Here is how I got it working with the current > Webware (I simplified it a bit by not using Webware actions): > > > class form(Page): > > schema = FormSchema() > > def awake(self, trans): > Page.awake(self, trans) > try: > fields = self.request().fields() > if 'name' in fields: > fields = self.schema.to_python(fields, self) > else: > fields = self.getDefaults() > except formencode.Invalid, e: > errors = dict((k, v.encode('utf-8')) > for k, v in e.unpack_errors().iteritems()) > else: > errors = None > self.rendered_form = formencode.htmlfill.render(form_template, > defaults=fields, errors=errors) > > def writeContent(self): > self.write(page_style % self.rendered_form) > > def getDefaults(self): > return dict(age='enter your age', color=['blue']) > > > Let me know how it works for you. > > Btw, instead of using a schema, you could also embed the validation info > in the form template and use the SchemaBuilder to parse these. > > -- Christoph > > ------------------------------------------------------------------------------ > > _______________________________________________ > Webware-discuss mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webware-discuss > |
From: Christoph Z. <ci...@on...> - 2010-05-11 09:45:01
|
Am 11.05.2010 08:53, schrieb Georg Balmer: > I got the example from a direct download from formencode.org: > . [2] svn co http://svn.colorstudy.com/FormEncode/trunk FormEncode > (examples directory: WebwareExamples/index.py) Thanks, I was not aware of that example. Seems it was actually written for Paste WebKit (http://pythonpaste.org/webkit/). As you noticed it uses htmlform which is deprecated; you must use htmlfill directly. You must also add a name="color" attribute to the checkboxes to make these work. It seems your problem is that the formencode errors are now unicode, so you must encode these. Here is how I got it working with the current Webware (I simplified it a bit by not using Webware actions): class form(Page): schema = FormSchema() def awake(self, trans): Page.awake(self, trans) try: fields = self.request().fields() if 'name' in fields: fields = self.schema.to_python(fields, self) else: fields = self.getDefaults() except formencode.Invalid, e: errors = dict((k, v.encode('utf-8')) for k, v in e.unpack_errors().iteritems()) else: errors = None self.rendered_form = formencode.htmlfill.render(form_template, defaults=fields, errors=errors) def writeContent(self): self.write(page_style % self.rendered_form) def getDefaults(self): return dict(age='enter your age', color=['blue']) Let me know how it works for you. Btw, instead of using a schema, you could also embed the validation info in the form template and use the SchemaBuilder to parse these. -- Christoph |
From: Georg B. <gb...@bl...> - 2010-05-11 06:53:31
|
Thank you for your reply My test setup is: . fedora 11 . python 2.6 . formencode in site-packages/formencode (had to add the i18n directory) from [2] . webware-1.1.b1 . using utf-8 I got the example from a direct download from formencode.org: . [2] svn co http://svn.colorstudy.com/FormEncode/trunk FormEncode (examples directory: WebwareExamples/index.py) . you may switch language for formencode in awake . some lines in "save" are experimental. I made some changes following your suggestions. The german version doesn't break HTTPResponse anymore, but I still don't understand the mechanics of error catching and so on. My aim is to have a basic example I can use for my next steps. Regards Georg -------------------------------------------------------------------------------- Am 10.05.2010 23:10, schrieb Christoph Zwerschke: > Am 10.05.2010 12:57 schrieb Georg Balmer: >> The orginal WebwareExample by Ian Bicking is working after eliminating HTMLForm >> but some german error messages produce a UnicodeEncodeError in HTTPResponse. > > Sorry, I cannot find this example you're referring to, where is it? > Generally, you must output ordinary (encoded) strings in Webware, not > unicode. It's best to always use the same encoding (e.g. latin-1 or > utf-8) and work with encoded strings everywhere inside Webware. > > -- Christoph > > ------------------------------------------------------------------------------ > > _______________________________________________ > Webware-discuss mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webware-discuss > |
From: Georg B. <gb...@bl...> - 2010-05-11 04:18:00
|
Thank you for your reply My test setup is: . fedora 11 . python 2.6 . formencode in site-packages/formencode (had to add the i18n directory) from [2] . webware-1.1.b1 . using utf-8 I got the example from a direct download from formencode.org: . [2] svn co http://svn.colorstudy.com/FormEncode/trunk FormEncode (examples directory: WebwareExamples/index.py) . you may switch language for formencode in awake . some lines in "save" are experimental My aim is to have a basic example I can use for my next steps. Regards Georg -------------------------------------------------------------------------------- Am 10.05.2010 23:10, schrieb Christoph Zwerschke: > Am 10.05.2010 12:57 schrieb Georg Balmer: >> The orginal WebwareExample by Ian Bicking is working after eliminating HTMLForm >> but some german error messages produce a UnicodeEncodeError in HTTPResponse. > > Sorry, I cannot find this example you're referring to, where is it? > Generally, you must output ordinary (encoded) strings in Webware, not > unicode. It's best to always use the same encoding (e.g. latin-1 or > utf-8) and work with encoded strings everywhere inside Webware. > > -- Christoph > > ------------------------------------------------------------------------------ > > _______________________________________________ > Webware-discuss mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webware-discuss > |
From: Christoph Z. <ci...@on...> - 2010-05-10 21:10:51
|
Am 10.05.2010 12:57 schrieb Georg Balmer: > The orginal WebwareExample by Ian Bicking is working after eliminating HTMLForm > but some german error messages produce a UnicodeEncodeError in HTTPResponse. Sorry, I cannot find this example you're referring to, where is it? Generally, you must output ordinary (encoded) strings in Webware, not unicode. It's best to always use the same encoding (e.g. latin-1 or utf-8) and work with encoded strings everywhere inside Webware. -- Christoph |
From: Georg B. <gb...@bl...> - 2010-05-10 10:57:55
|
I am trying to find a very basic example using FormEncode with Webware-1.1b1. The orginal WebwareExample by Ian Bicking is working after eliminating HTMLForm but some german error messages produce a UnicodeEncodeError in HTTPResponse. The comment in HTTPResponse.py (around Line 260) let's me assume that something needs to be done in my example code but I don't know exactly what. Any help or advice is very welcome. Regards Georg Balmer |