[Web-SIG] WSGI-ISAPI
After installed Python 2.4 and the latest Pythonwin, I discovered a new cool ISAPI module. If anyone wants to assist me with WSGI-ISAPI, I'd be glad for the help. I'm still at the "Hello, world" stage, but I think this (along with mod_python) will be a huge selling point for WSGI. ___ Web-SIG mailing list [EMAIL PROTECTED] Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
[Web-SIG] twisted_wsgi.py license
Due to many requests, I'm announcing that the twisted_wsgi.py library is released under the MIT license. This basically means you can do whatever you want with it. Happy hacking! Peter Hunt ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
[Web-SIG] Re: Just lost another one to Rails
Ruby on Rails, ColdFusion, ASP.NET, and to a lesser degree PHP and ASP share two important traits that no Python web framework currently embraces. First, when one writes an application for these frameworks, one spends the vast majority of time writing code for their application, writing the logic that their application specifically requires. Contrast this with J2EE or Zope. In writing a Zope 3 application, for example, one must design objects that fit the Zope interface requirements, write a couple of XML configuration files to document the object, and figure out the entire API all at once. Contrast this to PHP, where one spends time simply writing what their application needs to do, and does not need to write a single ambiguous XML configuration file. This extends to deployment. In a J2EE application, you need to deploy a WAR, while with PHP, you just need to drop a few .php files on the server and it works. Second, these frameworks have "batteries included". Rails is a "full-stack" framework, which, according to its API documentation, "includes everything needed to create database-backed web-applications according to the Model-View-Control pattern of separation." It handles everything from form validation to database integration to sending email. No Python framework currently embodies such functionality with such good integration. I really want to be able to say that we should all come together to improve Zope, the "king" of Python web frameworks . . . but I can't say that. Zope 2 was a mess, and Zope 3 is so overengineered that it's painful to write code. The ideal framework should allow the programmer to be organized, while still allowing a monkey to write Hello, World. My two cents . . . what's yours? ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
[Web-SIG] Re: WSGIKit and frameworks
Ian: does it support plugging in a custom WSGI application yet? ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
[Web-SIG] Re: Preferred set of WSGI servers
Actually, I think a mod_wsgi for Apache and IIS would be one of _the_ most important things for WSGI. I think that it would search for a __wsgi__.py file (or maybe something with a better name) which would expose a WSGI application named "application" that would handle requests for the directory in which it exists. This would allow a user to simply drop a file on the webserver and have it work. It would be excellent for shared hosting solutions. Thoughts? Peter Hunt___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] JavaScript libraries
Hello everyone,
A long time ago (before the advent of IronPython), I wrote a small
Python module that compiled a python file to a JScript.NET file and
compiled it. Seeing as JScript and _javascript_ are very similar, I bet
this could be very helpful. See
http://subway.python-hosting.com/attachment/wiki/Py2Js/pyc.2.py for the
code.
I envision a world where we can write something like:
And it will do a server-side RPC to the onButtonClick() method, which could do something like this:
def onButtonClick(ctx):
ctx.document.writeln("Button clicked")
ctx would serve as a magical proxy for method calls back to the client.
This would allow seamless integration of _javascript_ and Python without
even writing a line of JS. What do you think?
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] and now for something completely different!
Phillip - I agree with you on all counts, except for the issue of how to determine when a session ends (timeouts, etc), and how to clean up the associated objects (Carts etc) with them. Peter Hunt ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
[Web-SIG] Standardized template API
Hi guys -I think a lot of web frameworks and applications are using a template engine. We should probably have an officially sanctioned templating engine plugin API, as it would ease adoption of existing Python web framework solutions. I think all it would take is a Web-Sig (and perhaps a PEP) blessing the TurboGears template engine plugin API [1].Thoughts?Peter Hunt[1] http://www.turbogears.org/docs/plugins/template.html ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Standardized template API
On 1/31/06, Robert Brewer <[EMAIL PROTECTED]> wrote: That's true, but I'd caution that "it's just something you use" hides amountain of difficulties. A standard like WSGI can be relatively free in its interface design (in order to meet a host of specialized needs),because it has a limited user group. A template standard, in contrast,will need much more attention paid to "ease of use", which will constrain its interface design. The user group of a standardized template API would be a framework author. Different frameworks would still access their templating engines in different ways, but with a standardized template engine API, you'd be able to plug different templating engines ( i.e. django, cheetah, kid, zpt, psp) into different frameworks, and have it Just Work.Peter Hunt ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] WSGI in standard library
I think CherryPy's WSGI server should go in: it's stable, and the best-performing WSGI HTTP server out there.Peter ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] WSGI in standard library
Alan, you're looking at cherrypy._cphttpserver. You should be looking at cherrypy._cpwsgiserver. That's the primary server nowadays; cherrypy._cphttpserver is an artifact for the most part.Peter Hunt ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] WSGI in standard library
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 ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] [Fwd: Summer of Code preparation]
Hi guys,I think an interesting project would be complete integration of the client and server via AJAX. That is, whenever a DHTML event handler needs to be called on the client-side, the document state is serialized and it is sent along with the DHTML event information to the server, informing it that an event occured. Then, using something similar to Nevow's LivePage, it could asynchronously send back _javascript_ code to update client state based on actions on the server. Ideally, on the server-side we'd have a magic document object which is updated with the document state every request, and whenever a property is written or a method is called, corresponding _javascript_ is sent via our LivePage mechanism to the client. Thoughts?Peter Hunt ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
