From fumanchu at amor.org Tue Mar 7 00:31:04 2006 From: fumanchu at amor.org (Robert Brewer) Date: Mon, 6 Mar 2006 15:31:04 -0800 Subject: [Web-SIG] httpy -- raise Response(409) Message-ID: <435DF58A933BA74397B42CDEB8145A86539C26@ex9.hostedexchange.local> Chad Whitacre wrote: > I think the trick is that in HTTP, success and error conditions both > produce the same result: a Response message. In Python we distinguish > the two: successful "requests" (i.e., function calls) return > something; bad requests raise something. > > So perhaps the answer is that respond(request) may *either* > return *or* raise a Response? This is the approach CherryPy takes. You can raise HTTPRedirect (for 3xx responses) or HTTPError (for 4xx-5xx responses); however, 2xx responses are usually performed with a normal "return". By far, the biggest issue with this approach is educating users: not every *exception* is an *error*. Robert Brewer System Architect Amor Ministries fumanchu at amor.org From cce at clarkevans.com Wed Mar 15 09:28:48 2006 From: cce at clarkevans.com (Clark C. Evans) Date: Wed, 15 Mar 2006 03:28:48 -0500 Subject: [Web-SIG] WSGI in standard library In-Reply-To: <43F0FFA0.6010005@colorstudy.com> References: <06Feb6.112517pst."58633"@synergy1.parc.xerox.com> <43EF1E8E.3080804@xhaus.com> <43EF2BBE.50705@xhaus.com> <43F0FFA0.6010005@colorstudy.com> Message-ID: <20060315082848.GA7516@prometheusresearch.com> Guido, In the past few weeks it looks like CherryPy people have put in a serious effort cleaning-up their WSGI Server (so it does not have external dependencies, etc.). I'd like to applaud their effort and suggest that we might want to use their implementation as the basis of a built-in Python 2.5 standard library version of WSGI. http://svn.cherrypy.org/trunk/cherrypy/_cpwsgiserver.py Kind Regards, Clark On Mon, Feb 13, 2006 at 03:52:32PM -0600, Ian Bicking wrote: | I'm not set on "production" quality code, but I think the general | sentiment against that is entirely premature. The implementations | brought up -- CherryPy's | (http://svn.cherrypy.org/trunk/cherrypy/_cphttpserver.py) and Paste's | (http://svn.pythonpaste.org/Paste/trunk/paste/httpserver.py) and | wsgiref's | (http://cvs.eby-sarna.com/wsgiref/src/wsgiref/simple_server.py?rev=1.2&view=markup) | are all pretty short. It would be better to discuss the particulars. | Is there a code path in one or more of these servers which you think is | unneeded and problematic? From floydophone at gmail.com Wed Mar 15 13:15:58 2006 From: floydophone at gmail.com (Peter Hunt) Date: Wed, 15 Mar 2006 07:15:58 -0500 Subject: [Web-SIG] WSGI in standard library Message-ID: <6654eac40603150415y7da14b9al3fcdb4963a260cc0@mail.gmail.com> Actually, with the exception of error handling and UNIX sockets, _cpwsgiserver hasn't been changed all that much; it's mostly been the CherryPy WSGI apps and infrastructure. However, I agree with you. _cpwsgiserver rocks! :) Peter Hunt From pywebsig at alan.kennedy.name Wed Mar 15 18:30:57 2006 From: pywebsig at alan.kennedy.name (Alan Kennedy) Date: Wed, 15 Mar 2006 17:30:57 +0000 Subject: [Web-SIG] Standalone WSGI form framework. Message-ID: <4a951aa00603150930h76d658cj1b7154276b53fb7e@mail.gmail.com> Greetings All. I'm looking for a framework-independent form library. I'm using the Quixote forms library at the moment, inside my own framework, but would ideally like something more WSGI oriented, so that it is easier to mock and unittest. My ideal form framework should do the following 1. Parsing of submitted POST requests, etc 2. Binding of incoming form variables to the attributes of a target python data object 3. Customisable validation, with management of validation error messages. 4. Generate unique (hierarchical) field names for sub-attributes of the data object to be edited, which are javascript-identifier-safe, i.e. can be used as the names of HTML form input elements. 5. Handle multipart/form-data 6. Nice-to-have: transparently handle multi-page forms, e.g. hub forms, etc. It should NOT 1. Attempt to generate HTML, or be tied to a specific templating mechanism If anyone is familiar with the Java Spring Framework, it's got pretty much everything I need, but is overly complex, and is written in Java :-( TIA, Alan. From guido at python.org Wed Mar 15 18:40:45 2006 From: guido at python.org (Guido van Rossum) Date: Wed, 15 Mar 2006 09:40:45 -0800 Subject: [Web-SIG] WSGI in standard library In-Reply-To: <20060315082848.GA7516@prometheusresearch.com> References: <43EF1E8E.3080804@xhaus.com> <43EF2BBE.50705@xhaus.com> <43F0FFA0.6010005@colorstudy.com> <20060315082848.GA7516@prometheusresearch.com> Message-ID: Sorry folks, I'm going to have to do some serious load shedding if I ever want to get the Py3K effort under way. You are going to have to argue amongst yourselves about the best wsgi reference implementation to put into the standard library. As a starting point, the code you reference seems particularly underdocumented. --Guido On 3/15/06, Clark C. Evans wrote: > Guido, > > In the past few weeks it looks like CherryPy people have put in a > serious effort cleaning-up their WSGI Server (so it does not have > external dependencies, etc.). I'd like to applaud their effort and > suggest that we might want to use their implementation as the basis > of a built-in Python 2.5 standard library version of WSGI. > > http://svn.cherrypy.org/trunk/cherrypy/_cpwsgiserver.py > > Kind Regards, > > Clark > > > On Mon, Feb 13, 2006 at 03:52:32PM -0600, Ian Bicking wrote: > | I'm not set on "production" quality code, but I think the general > | sentiment against that is entirely premature. The implementations > | brought up -- CherryPy's > | (http://svn.cherrypy.org/trunk/cherrypy/_cphttpserver.py) and Paste's > | (http://svn.pythonpaste.org/Paste/trunk/paste/httpserver.py) and > | wsgiref's > | (http://cvs.eby-sarna.com/wsgiref/src/wsgiref/simple_server.py?rev=1.2&view=markup) > | are all pretty short. It would be better to discuss the particulars. > | Is there a code path in one or more of these servers which you think is > | unneeded and problematic? > -- --Guido van Rossum (home page: http://www.python.org/~guido/) From titus at caltech.edu Wed Mar 15 18:44:23 2006 From: titus at caltech.edu (Titus Brown) Date: Wed, 15 Mar 2006 09:44:23 -0800 Subject: [Web-SIG] Standalone WSGI form framework. In-Reply-To: <4a951aa00603150930h76d658cj1b7154276b53fb7e@mail.gmail.com> References: <4a951aa00603150930h76d658cj1b7154276b53fb7e@mail.gmail.com> Message-ID: <20060315174422.GC32723@caltech.edu> -> I'm looking for a framework-independent form library. I'm using the -> Quixote forms library at the moment, inside my own framework, but -> would ideally like something more WSGI oriented, so that it is easier -> to mock and unittest. hi, Alan, I'm confused by this -- this could mean that you want to separate the quixote forms lib from the Quixote 'request' object, I guess. What else? In any case, please let me (or the list) know if you find something that matches all of your requirements. Apart from the WSGI aspect, the quixote forms lib has #1, #2, #5, and I think #6. It does also attempt to generate HTML, but you can always just not call the render() functions, right? ;) It might be relatively easy to add the features to the quixote forms lib, too... thanks, --titus -> My ideal form framework should do the following -> -> 1. Parsing of submitted POST requests, etc -> 2. Binding of incoming form variables to the attributes of a target -> python data object -> 3. Customisable validation, with management of validation error messages. -> 4. Generate unique (hierarchical) field names for sub-attributes of -> the data object to be edited, which are javascript-identifier-safe, -> i.e. can be used as the names of HTML form input elements. -> 5. Handle multipart/form-data -> 6. Nice-to-have: transparently handle multi-page forms, e.g. hub forms, etc. -> -> It should NOT -> -> 1. Attempt to generate HTML, or be tied to a specific templating mechanism From ben at groovie.org Thu Mar 16 00:38:24 2006 From: ben at groovie.org (Ben Bangert) Date: Wed, 15 Mar 2006 15:38:24 -0800 Subject: [Web-SIG] ANN: Pylons 0.8 Message-ID: James Gardner and myself are pleased to announce release 0.8 of Pylons. Pylons is a modern full-stack Python web development framework that is frequently compared to Ruby on Rails since it uses similar methodologies and includes ports and re-implementations of useful Rails components such as Routes and AJAX Helpers. By combining ideas from Mason, TurboGears Django, and various Python frameworks with a highly extensible API, Pylons provides a toolset that is very flexible and natural for the Python developer to use. === Full Web Server Gateway Interface Stack === Pylons is based on Paste from the ground up. Its heavy use of WSGI wherever possible makes for a sophisticated yet highly flexible system that helps you to get started quickly and enables you to get at the heart of what's going on when you need to. === Powerful URL Design === Pylons integrates Routes to provide a powerful system for designing simple, cruft-free URLs that are as carefully laid out as your application. === Flexible Templates === Pylons uses Myghty templates by default for their power, simplicity and speed but also supports Cheetah and Kid and can be also be used with any Buffet-compatible template language. Choose the templating system that best suits the way you work. === Helper Functions === Pylons web helpers provide a full range of functions that can be used throughout your application and templates so that you don't need to reinvent the wheel for common tasks. All the helpers from Rails are available including full AJAX support and pagination compatible with lists and popular ORM's like SQLObject and SQLAlchemy. === Interactive Debugging === The speed you can develop an application depends a lot on the speed you can correct problems. Pylons error handling middleware provides code snippets, value tables, extra application data and uses AJAX to provide an interactive Python prompt that you can use at any point in the error traceback to track down and solve problems fast. === Other Features in Brief === Pure Python, 2.3.5 and 2.4 compatible tested on Windows/MacOS/Linux/ BSD, deploy via the stand alone server or CGI/FastCGI/SCGI/mod_python on Apache, Lighttpd or other servers, internationalization support, database integration, caching, built-in testing, automatic documentation via Pudge, extensible helper API, JSON support, traceback emails, egg and easy_install compatible, helpful and knowledgeable community. Locations ------------- Web: http://pylonshq.com/install/ Easy Install: easy_install -f http://pylonshq.com/download/ Pylons Mailing List: http://groups.google.com/group/pylons-discuss Developers: Ben Bangert, James Gardner and many others If you want to get serious about Python web development, get Pylons and get started: http://pylonshq.com/docs/0.8/getting_started.html -Ben Bangert From millerdev at gmail.com Thu Mar 16 06:21:19 2006 From: millerdev at gmail.com (Daniel Miller) Date: Thu, 16 Mar 2006 00:21:19 -0500 Subject: [Web-SIG] Standalone WSGI form framework. In-Reply-To: <4a951aa00603150930h76d658cj1b7154276b53fb7e@mail.gmail.com> References: <4a951aa00603150930h76d658cj1b7154276b53fb7e@mail.gmail.com> Message-ID: <4418F5CF.8010305@gmail.com> Alan Kennedy wrote: > I'm looking for a framework-independent form library. I'm using the > Quixote forms library at the moment, inside my own framework, but > would ideally like something more WSGI oriented, so that it is easier > to mock and unittest. Have you looked at Ian Bicking's FormEncode? I'm not sure if it meets all your requirements, but it seems like a good base to start with (most of the hard stuff has already been done). > 1. Parsing of submitted POST requests, etc FormEncode (along with VariableDecode, a subcomponent) can do this. VariableDecode takes a flat dict and turns it into hierarchical structure of lists and dictionaries. FormEncode applies a schema or group of validators to this hierarchical structure, converting strings to python objects. Here FormEncode is a bit different than Spring: all validation occurs completely separate from binding. > 2. Binding of incoming form variables to the attributes of a target > python data object Once they've been validated by FormEncode, it fairly trivial to write code to bind values to objects. Binding is much simpler in Python than it is in Java because Python has a simpler reflection api (and Python is dynamic). > 3. Customisable validation, with management of validation error messages. FormEncode has the most flexible custom validation I've ever used. I wished Spring had something like it before I knew about FormEncode. > 4. Generate unique (hierarchical) field names for sub-attributes of > the data object to be edited, which are javascript-identifier-safe, > i.e. can be used as the names of HTML form input elements. I'm pretty sure FormEncode does this, and if it doesn't it's very simple to write your own "validator" that will do it. > 5. Handle multipart/form-data FormEncode has a FieldStorageUploadConverter (I think it's for this type of thing). > 6. Nice-to-have: transparently handle multi-page forms, e.g. hub forms, etc. FormEncode can do partial validation of a given schema, but I'd probably just write a separate schema for each page and then use them all together on the last page (easily done). > It should NOT > > 1. Attempt to generate HTML, or be tied to a specific templating mechanism As long as you stay away from HTMLForm (is it deprecated??) I think FormEncode is fine here too. > > If anyone is familiar with the Java Spring Framework, it's got pretty > much everything I need, but is overly complex, and is written in Java > :-( > I wrote an app using Spring and I have to say it's the best web framework I've ever used in terms of completeness and flexibility, but it's written in Java... I actually wrote a few simple classes on top of CherryPy that exposes the Spring webmvc Controller interface as well as the SimpleFormController class (those are the two main building blocks I found most useful in Spring's WebMVC). My SimpleFormController implementation uses FormEncode for validation. I'd be willing to share the code if you're interested. I think "the one true web framework" could be made for Python if someone took the best ideas from Spring WebMVC and made a few component-ized building blocks on top of which complex and widely varied applications could be built. However, to make this possible we'd most likely need a standard request object (or at least an interface definition). ~ Daniel From pywebsig at alan.kennedy.name Thu Mar 16 18:33:51 2006 From: pywebsig at alan.kennedy.name (Alan Kennedy) Date: Thu, 16 Mar 2006 17:33:51 +0000 Subject: [Web-SIG] Standalone WSGI form framework. In-Reply-To: <4418F5CF.8010305@gmail.com> References: <4a951aa00603150930h76d658cj1b7154276b53fb7e@mail.gmail.com> <4418F5CF.8010305@gmail.com> Message-ID: <4a951aa00603160933y498add8ey15f719bd55257e8@mail.gmail.com> [Alan Kennedy] > I'm looking for a framework-independent form library. I'm using the > Quixote forms library at the moment, inside my own framework, but > would ideally like something more WSGI oriented, so that it is easier > to mock and unittest. [Daniel Miller] > Have you looked at Ian Bicking's FormEncode? I'm not sure if it > meets all your requirements, but it seems like a good base to start > with (most of the hard stuff has already been done). Thanks Daniel. Indeed, it not only appears that FormEncode is the closest thing to what I need, it also seems to be the only show in town, i.e. the only framework-independent form library. [Alan Kennedy] > If anyone is familiar with the Java Spring Framework, it's got pretty > much everything I need, but is overly complex, and is written in Java [Daniel Miller] > I wrote an app using Spring and I have to say it's the best web > framework I've ever used in terms of completeness and flexibility, > but it's written in Java... Agreed. I find it's interface based design very simple and powerful. But, IMHO, the actual implementations of the classes that implement the interfaces are excessively complex and rigidly structured. [Daniel Miller] > I actually wrote a few simple classes on top of CherryPy that exposes > the Spring webmvc Controller interface as well as the > SimpleFormController class (those are the two main building blocks > I found most useful in Spring's WebMVC). My SimpleFormController > implementation uses FormEncode for validation. I'd be willing to > share the code if you're interested. I'd be very interested to see that, and potentially use it, if you're willing ... [Daniel Miller] > I think "the one true web framework" could be made for Python if > someone took the best ideas from Spring WebMVC and made a few > component-ized building blocks on top of which complex and widely > varied applications could be built. Completely agreed. The term "meta-framework" is most appropriate, I think. If we could agree on a set of interfaces, then everyone would be free to contribute implementations of their own componments. For example, I like the idea of Routes URL-mapping library: it's precisely the kind of task that is simple enough in concept, but yet complex enough to require a dedicated (and thoroughly tested) library. Most of the popular web frameworks make the fundamental mistake of picking a single URL->object mapping mechanism, and making you shoehorn all your requirements into it. IIRC, Django, Turbogears, Pylons, all make this mistake. However, if URL->object mapping were controlled by an interface, then we'd be free to choose from multiple implementations, e.g. routes-style, quixote-style, zope-style, etc, etc. > However, to make this possible we'd most likely need a standard > request object (or at least an interface definition). ISTM that WSGI eliminates the need for that. Is there any specific thing you have in mind that WSGI doesn't cover? Regards, Alan. From pywebsig at alan.kennedy.name Thu Mar 16 18:34:42 2006 From: pywebsig at alan.kennedy.name (Alan Kennedy) Date: Thu, 16 Mar 2006 17:34:42 +0000 Subject: [Web-SIG] Standalone WSGI form framework. In-Reply-To: <20060315174422.GC32723@caltech.edu> References: <4a951aa00603150930h76d658cj1b7154276b53fb7e@mail.gmail.com> <20060315174422.GC32723@caltech.edu> Message-ID: <4a951aa00603160934x1d486e3dr8c3c5612071aed01@mail.gmail.com> [Alan Kennedy] > I'm looking for a framework-independent form library. I'm using the > Quixote forms library at the moment, inside my own framework, but > would ideally like something more WSGI oriented, so that it is easier > to mock and unittest. [Titus Brown] > I'm confused by this -- this could mean that you want to separate the > quixote forms lib from the Quixote 'request' object, I guess. What > else? Hi Titus, I realise that I can rewrite the Quixote form lib to achieve what I want, but at the cost of a fairly significant effort. As it is, I've rewritten the rendering, to work with Kid and ElementTree. But I'm tired of hacking on it to make it do what I want: I'd much prefer to start afresh with my own design than to continue to use Quixote: it's just too limiting. Regards, Alan. From titus at caltech.edu Thu Mar 16 18:36:45 2006 From: titus at caltech.edu (Titus Brown) Date: Thu, 16 Mar 2006 09:36:45 -0800 Subject: [Web-SIG] Standalone WSGI form framework. In-Reply-To: <4a951aa00603160934x1d486e3dr8c3c5612071aed01@mail.gmail.com> References: <4a951aa00603150930h76d658cj1b7154276b53fb7e@mail.gmail.com> <20060315174422.GC32723@caltech.edu> <4a951aa00603160934x1d486e3dr8c3c5612071aed01@mail.gmail.com> Message-ID: <20060316173645.GA20399@caltech.edu> On Thu, Mar 16, 2006 at 05:34:42PM +0000, Alan Kennedy wrote: -> [Alan Kennedy] -> > I'm looking for a framework-independent form library. I'm using the -> > Quixote forms library at the moment, inside my own framework, but -> > would ideally like something more WSGI oriented, so that it is easier -> > to mock and unittest. -> -> [Titus Brown] -> > I'm confused by this -- this could mean that you want to separate the -> > quixote forms lib from the Quixote 'request' object, I guess. What -> > else? -> -> Hi Titus, -> -> I realise that I can rewrite the Quixote form lib to achieve what I -> want, but at the cost of a fairly significant effort. -> -> As it is, I've rewritten the rendering, to work with Kid and ElementTree. -> -> But I'm tired of hacking on it to make it do what I want: I'd much -> prefer to start afresh with my own design than to continue to use -> Quixote: it's just too limiting. I think you mistook my question for a criticism ;). Rewrite or no, I'm mostly interested in what you meant by "WSGI oriented" and what that would mean specifically in the context of the Quixote forms lib. thanks, --titus From pywebsig at alan.kennedy.name Thu Mar 16 18:46:47 2006 From: pywebsig at alan.kennedy.name (Alan Kennedy) Date: Thu, 16 Mar 2006 17:46:47 +0000 Subject: [Web-SIG] Standalone WSGI form framework. In-Reply-To: <20060316173645.GA20399@caltech.edu> References: <4a951aa00603150930h76d658cj1b7154276b53fb7e@mail.gmail.com> <20060315174422.GC32723@caltech.edu> <4a951aa00603160934x1d486e3dr8c3c5612071aed01@mail.gmail.com> <20060316173645.GA20399@caltech.edu> Message-ID: <4a951aa00603160946k51d7894yac190adacf966cd@mail.gmail.com> [Alan Kennedy] > But I'm tired of hacking on it to make it do what I want: I'd much > prefer to start afresh with my own design than to continue to use > Quixote: it's just too limiting. [Titus Brown] > I think you mistook my question for a criticism ;). Rewrite or no, I'm > mostly interested in what you meant by "WSGI oriented" and what that > would mean specifically in the context of the Quixote forms lib. No criticism detected ;-) By WSGI oriented, I mean that I don't have to mock request objects: I can just use a dictionary to mock a WSGI request: I've found that testing approach exceedingly straightforward to work with. Also, I've had problems in the past with Quixote not handling response encodings correctly. And it's html escaping mechanism is excessively PTL oriented: I ended up making too many changes to Quixote, which made me question why I was using it in the first place. Regards, Alan. From ianb at colorstudy.com Thu Mar 16 21:21:57 2006 From: ianb at colorstudy.com (Ian Bicking) Date: Thu, 16 Mar 2006 14:21:57 -0600 Subject: [Web-SIG] Standalone WSGI form framework. In-Reply-To: <4a951aa00603160933y498add8ey15f719bd55257e8@mail.gmail.com> References: <4a951aa00603150930h76d658cj1b7154276b53fb7e@mail.gmail.com> <4418F5CF.8010305@gmail.com> <4a951aa00603160933y498add8ey15f719bd55257e8@mail.gmail.com> Message-ID: <4419C8E5.8070207@colorstudy.com> Alan Kennedy wrote: >>I think "the one true web framework" could be made for Python if >>someone took the best ideas from Spring WebMVC and made a few >>component-ized building blocks on top of which complex and widely >>varied applications could be built. > > > Completely agreed. The term "meta-framework" is most appropriate, I > think. If we could agree on a set of interfaces, then everyone would > be free to contribute implementations of their own componments. > > For example, I like the idea of Routes URL-mapping library: it's > precisely the kind of task that is simple enough in concept, but yet > complex enough to require a dedicated (and thoroughly tested) library. > > Most of the popular web frameworks make the fundamental mistake of > picking a single URL->object mapping mechanism, and making you > shoehorn all your requirements into it. IIRC, Django, Turbogears, > Pylons, all make this mistake. > > However, if URL->object mapping were controlled by an interface, then > we'd be free to choose from multiple implementations, e.g. > routes-style, quixote-style, zope-style, etc, etc. I think WSGI can provide that, through successive rewriting of the environment and dispatching to WSGI applications. So Routes matches against PATH_INFO, and generally consumes everything (though you can make it not consume everything -- but the use cases for that are more limited since Routes is doing whole-path matching). Or in RhubarbTart you traverse through objects, and if you reach a WSGI application it adjusts SCRIPT_NAME and PATH_INFO, so the WSGI application doesn't need to know the algorithm that determined it was selected. And for systems that consume partial URLs, they don't need to know what might consume the rest of the URL. So if you put a Routes-based app in a RhubarbTart project, RhubarbTart only needs to know that it has found a WSGI application. >>However, to make this possible we'd most likely need a standard >>request object (or at least an interface definition). > > > ISTM that WSGI eliminates the need for that. Is there any specific > thing you have in mind that WSGI doesn't cover? We've recently kind of extracted the request object from RhubarbTart and put it into Paste: http://svn.pythonpaste.org/Paste/trunk/paste/request.py (Request class). I generally have been wary of a common request object, but I like this one, mostly because it is just a wrapper around the WSGI request environment. So, while it can provide a common base (e.g., for subclassing, or just using directly), the WSGI environment remains the canonical location for information. So you could have ten different eclectic instances of request objects running off the same single WSGI request, and they should all work together. Probably the biggest challenge I've seen in the past of a common(ish) request object is that of scope. People include lots of different things in request objects -- like the response, or the traversal algorithm. But if you restrict it to what is in the WSGI environment, the choices you have to make are much more constrained. -- Ian Bicking / ianb at colorstudy.com / http://blog.ianbicking.org From ben at groovie.org Thu Mar 16 21:53:16 2006 From: ben at groovie.org (Ben Bangert) Date: Thu, 16 Mar 2006 12:53:16 -0800 Subject: [Web-SIG] Standalone WSGI form framework. In-Reply-To: <4a951aa00603160933y498add8ey15f719bd55257e8@mail.gmail.com> References: <4a951aa00603150930h76d658cj1b7154276b53fb7e@mail.gmail.com> <4418F5CF.8010305@gmail.com> <4a951aa00603160933y498add8ey15f719bd55257e8@mail.gmail.com> Message-ID: <2B59B369-9C26-4087-B2E0-4BC21C58D9A1@groovie.org> On Mar 16, 2006, at 9:33 AM, Alan Kennedy wrote: > Completely agreed. The term "meta-framework" is most appropriate, I > think. If we could agree on a set of interfaces, then everyone would > be free to contribute implementations of their own componments. I've also heard the term micro-framework used, though meta does seem more accurate in the sense that these parts can be used to build frameworks. However, not so accurate in that they aren't really used to build frameworks, as they're composed to actually "be" frameworks. Regarding interfaces, as Ian mentioned, this was one desire in abstracting a fairly common Request wrapper on environ. To try and make it easier for hooks compatible with some of the interesting situations that occur with nested WSGI components, I made a piece of middleware I called the Registry: http://svn.pythonpaste.org/Paste/trunk/paste/registry.py I'm sure some people will hate it because it uses thread locals, but the usability it provides along with a way to expose points in a package make it easy to use for ad-hoc interfaces. For example, in the case of a Form component, one could say: - Provide a session object that acts as a dict - Provide a request object The developer would merely drop into his code the Registry middleware, and register the session/request object with the Form library. All the form classes and functions would then have access to the proper objects during the request without the usability issues of having to try and pass those objects explicitly back and forth all over the place (in my experience, this becomes a huge hassle). Some setuptools entry points that clearly indicate where the session/ request hooks to be plugged into could even automate the process entirely. > Most of the popular web frameworks make the fundamental mistake of > picking a single URL->object mapping mechanism, and making you > shoehorn all your requirements into it. IIRC, Django, Turbogears, > Pylons, all make this mistake. The next version of Pylons is going to have a bit more exposed WSGI path, which would make it easy to drop in other dispatch schemes if desired. As Ian mentioned, RhubarbTart is also doing something like this so that Routes can be dropped in. I won't be too surprised if the implementation end up using the same code and being rather identical. ;) > However, if URL->object mapping were controlled by an interface, then > we'd be free to choose from multiple implementations, e.g. > routes-style, quixote-style, zope-style, etc, etc. Yep, so if your WSGI app does its setup stuff as needed, then calls the dispatch and lets the flow go, a variety of mappings can be plugged in rather easily. However I'm sure there'll always be frameworks or setups incompatible with this flow so it might be better to just expose this section of logic to the web developer. If they want to plugin a different function to handle dispatch, they can, otherwise it goes with the frameworks default. >> However, to make this possible we'd most likely need a standard >> request object (or at least an interface definition). > ISTM that WSGI eliminates the need for that. Is there any specific > thing you have in mind that WSGI doesn't cover? I think everything should work with the WSGI environ by default, and if it wants to wrap environ in a more convenient request object, it can do so easily enough. So in the case of this standalone WSGI form framework, hypothetically, I'd see it acting as middleware though I suppose stand-alone app would work as well. FormEncode does a pretty good job on several of these parts, and it'd be nice to have multi- page forms abstracted into middleware so I don't have to keep dealing with that myself. I'd be interested in helping out on such a project if anyone wants to start one. - Ben From millerdev at gmail.com Fri Mar 17 02:32:22 2006 From: millerdev at gmail.com (Daniel Miller) Date: Thu, 16 Mar 2006 20:32:22 -0500 Subject: [Web-SIG] Standalone WSGI form framework Message-ID: <441A11A6.3030607@gmail.com> Alan Kennedy wrote: > [Alan Kennedy] >> I'm looking for a framework-independent form library. I'm using the >> Quixote forms library at the moment, inside my own framework, but >> would ideally like something more WSGI oriented, so that it is easier >> to mock and unittest. > > [Daniel Miller] >> I actually wrote a few simple classes on top of CherryPy that exposes >> the Spring webmvc Controller interface as well as the >> SimpleFormController class (those are the two main building blocks >> I found most useful in Spring's WebMVC). My SimpleFormController >> implementation uses FormEncode for validation. I'd be willing to >> share the code if you're interested. > > I'd be very interested to see that, and potentially use it, if you're > willing ... Sure. You can download it here: http://www.openpolitics.com/pieces/files/cherrymvc_r83.zip A few additional notes: - I have (temporarily?) named the project CherryMVC. This will probably change in the future (ideas welcome). - There is an experimental WebStack implementation (StackMVC) as well. It has not been tested at all. - I'd like to make this into a more generic WSGI framework that is not directly tied to CherryPy, but I haven't taken time to do that yet. If you make improvements that you'd like to share, by all means send them over so I can put them in the main codebase. > > [Daniel Miller] >> I think "the one true web framework" could be made for Python if >> someone took the best ideas from Spring WebMVC and made a few >> component-ized building blocks on top of which complex and widely >> varied applications could be built. > > ... > >> However, to make this possible we'd most likely need a standard >> request object (or at least an interface definition). > > ISTM that WSGI eliminates the need for that. Is there any specific > thing you have in mind that WSGI doesn't cover? Not that I know of, it's just a bit low-level (i.e. I want a nicer API than the WSGI env). Maybe the new request object in Paste will do? ~ Daniel From mo.babaei at gmail.com Sat Mar 18 11:54:54 2006 From: mo.babaei at gmail.com (Mohamad Babaei) Date: Sat, 18 Mar 2006 15:24:54 +0430 Subject: [Web-SIG] Encoding Message-ID: <5bf3a41f0603180254h7a452a7fneeea99522a75a055@mail.gmail.com> Hi, I'm working on a program that fetches some translated texts from *Altavista online translator , *it works fine with languages like German, french & .. but it can not get translated text in Japanese or Russian or chinese. my code is something like this: ################################## data1 = urllib.urlopen(' http://www.babelfish.altavista.com/babelfish/trurl_pagecontent?lp=en_ru&url=http://www.google.com').read( ) data1=data1.decode('utf-8') f=open('/usr/local/new/tt.html','w') f.write(data1.encode('utf-8')) f.close() ########################################### Any help appreciated. Best Wishes, M.Babaei -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/web-sig/attachments/20060318/1a884cfb/attachment.html From fumanchu at amor.org Sat Mar 18 19:21:19 2006 From: fumanchu at amor.org (Robert Brewer) Date: Sat, 18 Mar 2006 10:21:19 -0800 Subject: [Web-SIG] Encoding References: <5bf3a41f0603180254h7a452a7fneeea99522a75a055@mail.gmail.com> Message-ID: <435DF58A933BA74397B42CDEB8145A86224B77@ex9.hostedexchange.local> Mohamad Babaei wrote: > I'm working on a program that fetches some translated > texts from *Altavista online translator , *it works > fine with languages like German, french & .. but it > can not get translated text in Japanese or Russian > or chinese. my code is something like this: > > data1 = urllib.urlopen('http://www.babelfish. > altavista.com/babelfish/trurl_pagecontent? > lp=en_ru&url=http://www.google.com').read() > data1=data1.decode('utf-8') > f=open('/usr/local/new/tt.html','w') > f.write(data1.encode('utf-8')) > f.close() 1. Have you examined the response headers on a request for Japanese content and verified that the response is encoded in UTF-8? 2. Why decode it just to turn around and encode it again with the same encoding? Robert Brewer System Architect Amor Ministries fumanchu at amor.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/web-sig/attachments/20060318/f0c85399/attachment.htm From fumanchu at amor.org Sun Mar 19 09:49:34 2006 From: fumanchu at amor.org (Robert Brewer) Date: Sun, 19 Mar 2006 00:49:34 -0800 Subject: [Web-SIG] Python REPL in your browser Message-ID: <435DF58A933BA74397B42CDEB8145A86224B7A@ex9.hostedexchange.local> Okay, I think this is "done enough" to show around and get some feedback (and contributions ;) on. I hacked up a REPL-over-HTTP tool yesterday and today. Current code and doc is at http://projects.amor.org/misc/wiki/HTTPREPL. You can deploy it "standalone", maybe to give people a taste of Python. You can also use it to try various interpreter hacks (for example, I mistype "import" as "improt" often enough that I could trap that in HTTPREPL.push). The "cool factor" to me, though, is that once you have an adapter for your web framework, you can embed it in a web application and inspect what's going on in your web app or framework at runtime (in ways that took ugly printlining before). Currently, it's only got a CherryPy adapter (and ;). I'd be glad to include adapters for more frameworks. The code is in the public domain, so enjoy it however you like! Robert Brewer System Architect Amor Ministries fumanchu at amor.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/web-sig/attachments/20060319/4cfddd01/attachment.html From gotcha at bubblenet.be Fri Mar 24 15:56:48 2006 From: gotcha at bubblenet.be (Godefroid Chapelle) Date: Fri, 24 Mar 2006 15:56:48 +0100 Subject: [Web-SIG] EuroPython Web Frameworks track Message-ID: <442408B0.1030204@bubblenet.be> Hi there, EuroPython 2006 will happen July 3-5 by the CERN in Geneva, Switzerland. We would like to invite developers from the various Python web frameworks to present their work to the attendees. The web frameworks track is succeding to the Zope track that EuroPython has had for 4 years in a row. We hope that this event will allow exchange and collaboration between the users of the different communities. Please contact Paul Everitt (paul at zope-europe.org) or myself if you feel like offering a talk. Thanks -- Godefroid Chapelle (aka __gotcha)- BubbleNet http://bubblenet.be From iv at lantic.net Wed Mar 29 14:12:26 2006 From: iv at lantic.net (Iwan Vosloo) Date: 29 Mar 2006 14:12:26 +0200 Subject: [Web-SIG] ANN: Web framework map wiki Message-ID: <87irpx4fh1.fsf@localhost.localdomain> Hi there. About a year ago I mentioned on this list that I am doing a survey of 80 web framework (and related) projects. (It forms part of my Masters dissertation.) Some people here have expressed interest in the results. I've put up a wiki with the results at: http://www.reahl.org/wfmwiki. It would be great if you could join in - especially the serious web framework developers. I include some text from the introduction below. Regards -- Iwan Vosloo ------------------------------------------------------------- Introduction ============ There are many web frameworks available at the moment - new ones pop up very regularly. It takes quite a bit of effort to figure out what the essence of a new framework is. Biologists are faced with a similar problem when they discover a new exotic animal. But they have a valuable tool to their disposal. They have a taxonomy of different kinds of animals. When a new animal is discovered, it is classified according to this taxonomy. This act of classification already attaches a lot of known knowledge about the new animal - a big aid in getting to grips with "yet another animal". This wiki is an attempt at creating a similar tool for people who are interested in studying and comparing web frameworks. The task of keeping an up-to-date and useful map of the web framework world is a little daunting if you think about it: The world is a big place, and there are very many web frameworks in it. New web frameworks pop up regularly. Careful study of each of these takes a lot of time and effort. Each web framework designer seems to invent particular terminology that may or may not mean the same as the terminology used by others. And, of course, these things keep changing and growing. But it is precisely in such an environment that a map of sorts is useful. It gives structure: if you're working with a particular framework, it often helps to know where it fits with the rest of the world: to know its fundamental intention, strengths and weaknesses. When you want to create a new one, a map can show what is new and what is old-hat. This wiki was created with the hope that others may find it useful and that the interested parties can use it to collaborate and keep the web framework map growing and useful. From aurora00 at gmail.com Wed Mar 29 20:55:36 2006 From: aurora00 at gmail.com (aurora) Date: Wed, 29 Mar 2006 10:55:36 -0800 Subject: [Web-SIG] ANN: Web framework map wiki In-Reply-To: <87irpx4fh1.fsf@localhost.localdomain> References: <87irpx4fh1.fsf@localhost.localdomain> Message-ID: <cbd177510603291055g49a8fbb4sb2f9a6b1266e5cc7@mail.gmail.com> Interesting. I spent 3 minutes browsing through http://www.reahl.org/wfmwiki. A lot of words. But where is the map? wy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/web-sig/attachments/20060329/45fc3ff6/attachment.html From sanxiyn at gmail.com Thu Mar 30 09:21:08 2006 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Thu, 30 Mar 2006 16:21:08 +0900 Subject: [Web-SIG] Implementing WSGI server as ASP.NET handler Message-ID: <5b0248170603292321y154ca6edk76ddf723494e2a8a@mail.gmail.com> Hello, I got a proof-of-concept WSGI server as ASP.NET handler working, using IronPython. My development environment is Debian GNU/Linux with latest Mono and XSP, and IronPython 1.0 Beta 4 with patches. All the relevant codes are here. I will write a nice HOWTO when I got some more time. http://sparcs.kaist.ac.kr/~tinuviel/fepy/ Extract IronPython release and copy CPython's Lib directory over. Then download wsgi.py from lib directory to Lib directory. Create a directory (this will be ASP.NET application root directory). Download web.config and wsgi_hello.py from example directory. Create "bin" directory inside the application root directory. Make symbolic links to IronMath.dll, IronPython.dll, and copied-over Lib directory there. Then download WSGI.cs and its Makefile from src directory, and build WSGI.dll. Now just run "xsp2" ("xsp" is for .NET 1.x, and won't work with IronPython) from the application root directory. You should see something like: xsp2 Listening on port: 8080 (non-secure) Listening on address: 0.0.0.0 Root directory: /home/tinuviel/devel/fepy/wsgi Hit Return to stop the server. Do not hit return. Open http://localhost:8080/wsgi_hello.py in your web browser and get greeted. Seo Sanghyeon From fumanchu at amor.org Thu Mar 30 20:18:00 2006 From: fumanchu at amor.org (Robert Brewer) Date: Thu, 30 Mar 2006 10:18:00 -0800 Subject: [Web-SIG] Implementing WSGI server as ASP.NET handler Message-ID: <435DF58A933BA74397B42CDEB8145A8601144074@ex9.hostedexchange.local> Sanghyeon Seo wrote: > Hello, I got a proof-of-concept WSGI server as ASP.NET handler > working, using IronPython. > > My development environment is Debian GNU/Linux with latest Mono and > XSP, and IronPython 1.0 Beta 4 with patches. > > All the relevant codes are here. I will write a nice HOWTO when I got > some more time. > http://sparcs.kaist.ac.kr/~tinuviel/fepy/ > > Extract IronPython release and copy CPython's Lib directory over. Then > download wsgi.py from lib directory to Lib directory. > > Create a directory (this will be ASP.NET application root directory). > Download web.config and wsgi_hello.py from example directory. > > Create "bin" directory inside the application root directory. Make > symbolic links to IronMath.dll, IronPython.dll, and copied-over Lib > directory there. Then download WSGI.cs and its Makefile from src > directory, and build WSGI.dll. > > Now just run "xsp2" ("xsp" is for .NET 1.x, and won't work with > IronPython) from the application root directory. You should see > something like: > > xsp2 > Listening on port: 8080 (non-secure) > Listening on address: 0.0.0.0 > Root directory: /home/tinuviel/devel/fepy/wsgi > Hit Return to stop the server. > > Do not hit return. > > Open http://localhost:8080/wsgi_hello.py in your web browser > and get greeted. Good to see another one out there. Mine's at http://projects.amor.org/misc/wiki/ASPGateway Be careful with request.InputStream--apparently, the whole thing gets copied into memory: http://www.codecomments.com/archive289-2004-10-299287.html You'll also probably want to use ReadBinary to handle "non-text" files. Robert Brewer System Architect Amor Ministries fumanchu at amor.org