From mmzeeman at xs4all.nl Sun May 1 10:20:25 2005 From: mmzeeman at xs4all.nl (Maas-Maarten Zeeman) Date: Sun May 1 10:20:26 2005 Subject: [Web-SIG] Status of PEP 268 References: <426DE062.8000107@xs4all.nl> <200504261716.21862.paul@boddie.org.uk> Message-ID: <42749149.6070700@xs4all.nl> > > > > >>It looks like no one is interested in completing/implementing/finishing >>this PEP. Is this the case? >> >> > >I think that the urllib, urllib2, httplib modules (and so on) really need >reviewing and a more coherent package structure introduced, possibly with >more accessible classes for cases where one needs to change the default >behaviour, especially in the simple cases. Perhaps there'll be a sprint at >EuroPython around such things... > That sounds like a good idea. The http libraries are indeed lack coherence. To list a couple of problems: * httplib can do http 1.1, but no basic or digest authentication. * urllib2 can do basic and digest authentication, although very inefficiently, but no http 1.1. * urllib2 does not know anything about http connections (I guess it was build for http 1.0). This makes it hard to make extensions for connection oriented authentication mechanisms like NTLM, Negotiate and Kerberos. A sprint would really help to get things into shape again. Regards, Maas From gvwilson at cs.utoronto.ca Sun May 1 18:04:17 2005 From: gvwilson at cs.utoronto.ca (Greg Wilson) Date: Sun May 1 18:05:41 2005 Subject: [Web-SIG] Re: Just lost another one to Rails In-Reply-To: <20050429202207.GA26081@detroit.slack.net> References: <57015.66.192.34.8.1114784644.squirrel@66.192.34.8> <20050429202207.GA26081@detroit.slack.net> Message-ID: > Todd Grimason wrote: > ...i'm coming to > the conclusion that what's lacking most on any of the number of > existing, good frameworks is just "spit & polish". > In other words, good docs, good tutorials, sample applications (beyond > 10-liners), and yes, as much as many coders seem to distain it, > good-looking websites. * Good installers for major platforms (where "good" means "contain everything you need in a single download", so that you don't have to play the 'where do I get ClearSilver for Python 2.3 for Macintosh' game when you'd rather be building the application that's due on Tuesday) * A good app generator (click, click, click, and the first version of your app is up except for the business logic) * AJAX support (I think Rails' most compelling feature may turn out to be the fact that it does more AJAX straight out of the box than anything else --- they're definitely going to ride that wave) Thanks Greg From ianb at colorstudy.com Mon May 2 06:49:32 2005 From: ianb at colorstudy.com (Ian Bicking) Date: Sun, 01 May 2005 23:49:32 -0500 Subject: [Web-SIG] Just lost another one to Rails In-Reply-To: References: <57015.66.192.34.8.1114784644.squirrel@66.192.34.8> <20050429202207.GA26081@detroit.slack.net> Message-ID: <4275B15C.1090004@colorstudy.com> Greg Wilson wrote: > * AJAX support (I think Rails' most compelling feature may turn out to > be the fact that it does more AJAX straight out of the box than anything > else --- they're definitely going to ride that wave) My own take on this is that the web development community on the whole is still very uneducated when it comes to Ajax stuff, so it's intimidating. Rails covers up a few details and provides some suggestions (e.g., a specific Javascript helper library), so it helps people get past the initial barriers. But as Ajax becomes part of the normal web developer's toolkit, what Rails provides won't be that important. I think things will change radically as actual Javascript developer communities start to come about -- right now they are uncommon and usually attached to other projects (like Rails or Nevow), but that's not driven by any technical issue, just by cultural issues (Javascript isn't the core skill for many developers). I believe strongly that the future of Ajax needs to be backend-neutral. -- Ian Bicking / ianb at colorstudy.com / http://blog.ianbicking.org From faassen at infrae.com Mon May 2 12:40:02 2005 From: faassen at infrae.com (Martijn Faassen) Date: Mon, 02 May 2005 12:40:02 +0200 Subject: [Web-SIG] Just lost another one to Rails In-Reply-To: <20050429202207.GA26081@detroit.slack.net> References: <57015.66.192.34.8.1114784644.squirrel@66.192.34.8> <20050429202207.GA26081@detroit.slack.net> Message-ID: <42760382.7030603@infrae.com> Todd Grimason wrote: [snip] > In other words, good docs, good tutorials, sample applications (beyond > 10-liners), and yes, as much as many coders seem to distain it, > good-looking websites. If someone coming to web programming from X or Y > language (X or Y not being python or ruby), and looks at the Rails site > compared to almost any of the python frameworks, they'd very likely > conclude it [Rails] is a more mature, widely used, and professional > toolkit -- even though in many cases that's completely not true. Right, Rails does buzz and marketing right. For more on my thinking on that, see here: http://faassen.n--tree.net/blog/view/weblog/2005/04/06/0 > There is probably more sample code (test apps, example sites) on the > Rails site in teh past 6 months than a bunch of the python kits all > combined over years. Zope 3 actually has a lot of sample code in the Zope 3 book by Stephan Richter, which is online, just extremely well hidden in an obscure and scary wiki, last I checked. :) I agree very much that much of the reason Rails has the buzz now is because it does marketing right. Plone is another example of a project which does marketing well. Good marketing is a lot of work that developers might not want to do; they may not have the skills or insight, and beside that they'd rather write code instead. But assuming your goal is to compete with Rails, you're going to have to do a good marketing job. For marketing to developers, this also means writing good tutorials and introductions and making them easy to find. Regards, Martijn From faassen at infrae.com Mon May 2 12:47:48 2005 From: faassen at infrae.com (Martijn Faassen) Date: Mon, 02 May 2005 12:47:48 +0200 Subject: [Web-SIG] Just lost another one to Rails In-Reply-To: <4275B15C.1090004@colorstudy.com> References: <57015.66.192.34.8.1114784644.squirrel@66.192.34.8> <20050429202207.GA26081@detroit.slack.net> <4275B15C.1090004@colorstudy.com> Message-ID: <42760554.2040806@infrae.com> Ian Bicking wrote: [snip] > But as Ajax becomes part of the normal web developer's toolkit, what > Rails provides won't be that important. I think things will change > radically as actual Javascript developer communities start to come > about -- right now they are uncommon and usually attached to other > projects (like Rails or Nevow), but that's not driven by any > technical issue, just by cultural issues (Javascript isn't the core > skill for many developers). I believe strongly that the future of > Ajax needs to be backend-neutral. I've observed fairly closely the evolution of Kupu (kupu.oscom.org) over the last couple of years. The Kupu developers are exactly as you describe; an actual Javascript developer community. They originate in the Zope world in this case and thus are Python hackers (which is a good start for Javascript, as Javascript is like a badly broken Python, which is a compliment to Javascript :), though they're not *attached* to it -- Kupu is backend-neutral and used far outside the Zope context. A nice article about Kupu appeared recently on onlamp: http://www.onlamp.com/pub/a/onlamp/2005/04/28/kupu.html The Javascript world is nice currently as it isn't so filled up with actual developers yet, though is rapidly changing. A competent developer who writes Javascript can do stuff that few people have done before fairly easily, just by applying knowledge from, say, Python development. Regards, Martijn From jjinux at gmail.com Mon May 2 20:20:29 2005 From: jjinux at gmail.com (Shannon -jj Behrens) Date: Mon, 2 May 2005 11:20:29 -0700 Subject: [Web-SIG] JavaScript libraries In-Reply-To: <4275B15C.1090004@colorstudy.com> References: <57015.66.192.34.8.1114784644.squirrel@66.192.34.8> <20050429202207.GA26081@detroit.slack.net> <4275B15C.1090004@colorstudy.com> Message-ID: It sure would be nice to have a common JavaScript library that we could all share. People are wanting this for Aquarium, but I really don't want Aquarium to have its own JavaScript library. It's too much of a niche within a niche. Do you guys think it'd be possible to use the RoR one? I've often talked with Donnovan about using LivePage from Nevow. Do you guys know of any other really solid JavaScript libraries? Thanks, -jj On 5/1/05, Ian Bicking wrote: > Greg Wilson wrote: > > * AJAX support (I think Rails' most compelling feature may turn out to > > be the fact that it does more AJAX straight out of the box than anything > > else --- they're definitely going to ride that wave) > > My own take on this is that the web development community on the whole > is still very uneducated when it comes to Ajax stuff, so it's > intimidating. Rails covers up a few details and provides some > suggestions (e.g., a specific Javascript helper library), so it helps > people get past the initial barriers. But as Ajax becomes part of the > normal web developer's toolkit, what Rails provides won't be that > important. I think things will change radically as actual Javascript > developer communities start to come about -- right now they are uncommon > and usually attached to other projects (like Rails or Nevow), but that's > not driven by any technical issue, just by cultural issues (Javascript > isn't the core skill for many developers). I believe strongly that the > future of Ajax needs to be backend-neutral. > > -- > Ian Bicking / ianb at colorstudy.com / http://blog.ianbicking.org > _______________________________________________ > Web-SIG mailing list > Web-SIG at python.org > Web SIG: http://www.python.org/sigs/web-sig > Unsubscribe: http://mail.python.org/mailman/options/web-sig/jjinux%40gmail.com > -- I have decided to switch to Gmail, but messages to my Yahoo account will still get through. From ianb at colorstudy.com Mon May 2 20:24:48 2005 From: ianb at colorstudy.com (Ian Bicking) Date: Mon, 02 May 2005 13:24:48 -0500 Subject: [Web-SIG] JavaScript libraries In-Reply-To: References: <57015.66.192.34.8.1114784644.squirrel@66.192.34.8> <20050429202207.GA26081@detroit.slack.net> <4275B15C.1090004@colorstudy.com> Message-ID: <42767070.7040500@colorstudy.com> Shannon -jj Behrens wrote: > It sure would be nice to have a common JavaScript library that we > could all share. People are wanting this for Aquarium, but I really > don't want Aquarium to have its own JavaScript library. It's too much > of a niche within a niche. Do you guys think it'd be possible to use > the RoR one? I've often talked with Donnovan about using LivePage > from Nevow. Do you guys know of any other really solid JavaScript > libraries? I was just asking the Paste list about this, actually. Here's what I sent them: I've been playing around with javascript o lait (http://jsolait.net/) in an Ajax application (examples/console), but i'm having a hard time getting the Javascript to work. I'm wondering if anyone has particular opinions on libraries to use. I've looked just very briefly at Dojo: http://dojotoolkit.org/ and Sajax: http://www.modernmethod.com/sajax/ There's also LivePage, but I don't know that it's very well documented. Ditto Rails' prototype. I strongly prefer Javascript that is backend-neutral. Does anyone have experience with anything specific? I've only really tried Javascript O Lait, which has its good and bad points. I think the author of that library must be a Python fan too, as it adds Python-like ideas to Javascript, and he has some Python libraries to go with it. Actually, if I could just get the damn thing to load I don't know if I have any other complaints :-/ Trying to make Javascript modular is a PITA. But I haven't followed up with the jsolait list either. -- Ian Bicking / ianb at colorstudy.com / http://blog.ianbicking.org From paul at boddie.org.uk Mon May 2 20:35:52 2005 From: paul at boddie.org.uk (Paul Boddie) Date: Mon, 2 May 2005 20:35:52 +0200 Subject: [Web-SIG] JavaScript libraries In-Reply-To: <42767070.7040500@colorstudy.com> References: <42767070.7040500@colorstudy.com> Message-ID: <200505022035.52098.paul@boddie.org.uk> On Monday 02 May 2005 20:24, Ian Bicking wrote: > Shannon -jj Behrens wrote: > > Do you guys know of any other really solid JavaScript libraries? > > There's also LivePage, but I don't know that it's very well documented. > Ditto Rails' prototype. I strongly prefer Javascript that is > backend-neutral. Does anyone have experience with anything specific? I was meaning to look into Sarissa (http://sarissa.sourceforge.net/doc/) which was mentioned somewhere at some point fairly recently. It doesn't interact with specific server-side functionality, but we can whip that up quite easily, can't we? ;-) Paul From jjinux at gmail.com Mon May 2 20:39:24 2005 From: jjinux at gmail.com (Shannon -jj Behrens) Date: Mon, 2 May 2005 11:39:24 -0700 Subject: [Web-SIG] JavaScript libraries In-Reply-To: <200505022035.52098.paul@boddie.org.uk> References: <42767070.7040500@colorstudy.com> <200505022035.52098.paul@boddie.org.uk> Message-ID: > I was meaning to look into Sarissa (http://sarissa.sourceforge.net/doc/) which > was mentioned somewhere at some point fairly recently. It doesn't interact > with specific server-side functionality, but we can whip that up quite > easily, can't we? ;-) Wouldn't it be interesting if the web-sig community picked a JavaScript library they all liked and mass invaded/contributed to it ;) Gees, with the WSGI thing, and the JavaScript thing, we'd definitely be going in the right direction! Best Regards, -jj -- I have decided to switch to Gmail, but messages to my Yahoo account will still get through. From mike_mp at zzzcomputing.com Mon May 2 20:58:50 2005 From: mike_mp at zzzcomputing.com (mike bayer) Date: Mon, 2 May 2005 14:58:50 -0400 (EDT) Subject: [Web-SIG] JavaScript libraries In-Reply-To: References: <42767070.7040500@colorstudy.com> <200505022035.52098.paul@boddie.org.uk> Message-ID: <5978.66.192.34.8.1115060330.squirrel@66.192.34.8> what kind of features are you looking for in these javascript libraries ? I see sarissa is just the XMLHttpRequest method tied to writing the guts of DOM objects, and then some more elaborate DOM inspection methods that seem less useful. it seems to me that the "server-neutral" javascript part of AJAX is nothing more than a single function to connect an XMLHttpRequest and feed it to a callback function, and perhaps a couple of generic callback functions, i.e. "execute the javascript returned" and "write the HTML returned into this DOM element". everything else is specific to a particular application and/or server side approach. I went and took the single connection function from the Sajax demo and built a bunch of stuff off of that... once you can connect and get data, document.getElementById('foo').innerHTML = can draw anything anywhere you want. >> I was meaning to look into Sarissa (http://sarissa.sourceforge.net/doc/) >> which >> was mentioned somewhere at some point fairly recently. It doesn't >> interact >> with specific server-side functionality, but we can whip that up quite >> easily, can't we? ;-) > > Wouldn't it be interesting if the web-sig community picked a > JavaScript library they all liked and mass invaded/contributed to it > ;) Gees, with the WSGI thing, and the JavaScript thing, we'd > definitely be going in the right direction! > > Best Regards, > -jj > > -- > I have decided to switch to Gmail, but messages to my Yahoo account will > still get through. > _______________________________________________ > Web-SIG mailing list > Web-SIG at python.org > Web SIG: http://www.python.org/sigs/web-sig > Unsubscribe: > http://mail.python.org/mailman/options/web-sig/mike_mp%40zzzcomputing.com > From ianb at colorstudy.com Mon May 2 21:22:10 2005 From: ianb at colorstudy.com (Ian Bicking) Date: Mon, 02 May 2005 14:22:10 -0500 Subject: [Web-SIG] JavaScript libraries In-Reply-To: <5978.66.192.34.8.1115060330.squirrel@66.192.34.8> References: <42767070.7040500@colorstudy.com> <200505022035.52098.paul@boddie.org.uk> <5978.66.192.34.8.1115060330.squirrel@66.192.34.8> Message-ID: <42767DE2.4090801@colorstudy.com> mike bayer wrote: > what kind of features are you looking for in these javascript libraries ? > I see sarissa is just the XMLHttpRequest method tied to writing the guts > of DOM objects, and then some more elaborate DOM inspection methods that > seem less useful. > > it seems to me that the "server-neutral" javascript part of AJAX is > nothing more than a single function to connect an XMLHttpRequest and feed > it to a callback function, and perhaps a couple of generic callback > functions, i.e. "execute the javascript returned" and "write the HTML > returned into this DOM element". everything else is specific to a > particular application and/or server side approach. I agree that this is pretty much it. There's a few ways you might make the request -- ad hoc XML, a normal request with HTTP/url-encoded fields, XML-RPC, JSON. But they are all largely equivalent. And then a few helper methods, to make things like "call this server method and write its output to id X" easy to express. Underlying this is some cruftiness, compatibility and whatnot, but the core is pretty small. jsolait, which is the only library I've tried to use enough to have an opinion on, is relatively simple. My only criticism is that it seems to try to be too clever, when Javascript doesn't always support that cleverness. For instance, there is a server proxy object similar to xmlrpclib.ServerProxy; but because Javascript doesn't have a __getattr__ equivalent you have to enumerate all the methods. At which point it wouldn't be that much harder to simply create multiple proxy objects. The module stuff is also a bit difficult; it does keep the namespace clean, but "import" doesn't work well at all, and I doubt that is resolvable. And some things, like an equivalent to Python's string % operator, seem unnecessary to me. But then, it's not like they hurt. Mostly what I personally seek is a limited set of documented functionality that covers what I need, and does so reliably; something that covers over all the crufty corner cases, which are so easy to fall into in Javascript because there's lots of stuff that *does* work reliably, but many problem cases you can't predict without experience. I'm hoping to get the benefit of other people's experience through code and documentation. > I went and took the single connection function from the Sajax demo and > built a bunch of stuff off of that... once you can connect and get data, > document.getElementById('foo').innerHTML = can draw anything > anywhere you want. Incidentally, the Rails people felt pretty strongly that innerHTML was the way to go, because DOM manipulation is hard to maintain, and innerHTML is very consistent across browsers. -- Ian Bicking / ianb at colorstudy.com / http://blog.ianbicking.org From roberto at dealmeida.net Mon May 2 21:36:24 2005 From: roberto at dealmeida.net (Roberto Antonio Ferreira de Almeida) Date: Mon, 02 May 2005 16:36:24 -0300 Subject: [Web-SIG] JavaScript libraries In-Reply-To: <42767DE2.4090801@colorstudy.com> References: <42767070.7040500@colorstudy.com> <200505022035.52098.paul@boddie.org.uk> <5978.66.192.34.8.1115060330.squirrel@66.192.34.8> <42767DE2.4090801@colorstudy.com> Message-ID: <42768138.3030707@dealmeida.net> Ian Bicking wrote: > Incidentally, the Rails people felt pretty strongly that innerHTML was > the way to go, because DOM manipulation is hard to maintain, and > innerHTML is very consistent across browsers. I had problems with innerHTML in pages served as application/xhtml+xml -- it doesn't work. My solution was to write a function that converts HTML to Javascript code to manipulate the DOM: http://dealmeida.net/en/Programming/Python/from_xhtml_to_dom.html I'm not sure how well it works in IE, though. Roberto From jjinux at gmail.com Mon May 2 22:30:26 2005 From: jjinux at gmail.com (Shannon -jj Behrens) Date: Mon, 2 May 2005 13:30:26 -0700 Subject: [Web-SIG] JavaScript libraries In-Reply-To: <5978.66.192.34.8.1115060330.squirrel@66.192.34.8> References: <42767070.7040500@colorstudy.com> <200505022035.52098.paul@boddie.org.uk> <5978.66.192.34.8.1115060330.squirrel@66.192.34.8> Message-ID: On 5/2/05, mike bayer wrote: > what kind of features are you looking for in these javascript libraries ? The "Dynamic HTML" book from O'Reilly has the beginnings of what I'm looking for. It is a compatibility layer so that things like layers, repositioning, etc. work cross-platform. I think the code could have been better and more extensive, so I'm hoping someone out there has seen such a library. A lot of things in JavaScript are very rough and basic, sort of like C. I fear I've steered this mailing list very off topic, for which I apologize. Accept it as a compliment for the shared brain power of this list. ;) Best Regards, -jj -- I have decided to switch to Gmail, but messages to my Yahoo account will still get through. From carribeiro at gmail.com Mon May 2 23:29:32 2005 From: carribeiro at gmail.com (Carlos Ribeiro) Date: Mon, 2 May 2005 18:29:32 -0300 Subject: [Web-SIG] JavaScript libraries In-Reply-To: References: <57015.66.192.34.8.1114784644.squirrel@66.192.34.8> <20050429202207.GA26081@detroit.slack.net> <4275B15C.1090004@colorstudy.com> Message-ID: <864d370905050214292f09ccb0@mail.gmail.com> On 5/2/05, Shannon -jj Behrens wrote: > It sure would be nice to have a common JavaScript library that we > could all share. People are wanting this for Aquarium, but I really > don't want Aquarium to have its own JavaScript library. It's too much > of a niche within a niche. Do you guys think it'd be possible to use > the RoR one? I've often talked with Donnovan about using LivePage > from Nevow. Do you guys know of any other really solid JavaScript > libraries? Just for the record. I have spent six months writing a web-based workflow framework using CherryPy on my own time. I experimented a little bit with several templating systems, and one of the main problems that I had was with the integration of JavaScript code. I thought, "I want to code in one language as much as possible, and that's Python". So I wanted to have a templating system that allowed me to forget about writing custom Javascript code. After lots of painful experiments, I wrote a simple form-based library drawing on my experience with Delphi and other event-based toolsets. Forms are composed of components; each component has associated events. Event handlers are split in two parts: the form library itself generates a Javascript callback using an IFrame (the code was borrowed almost line-by-line from the example in the Apple's Developers site, and worked off the shelf!). This callback in turn is automatically associated with the even handler that is written in Python. The system was amazingly simple and intuitive. The best part, I didn't had to write custom Javascript code; I could rely on Python to handle events that were fired into the web browser, using my two-way glue code. All of this was prior to Ajax. I heard about it and it seemed to be something along the same lines of the work that I was doing, but at that time, I was hired for another project (I am a network architect by profession, not a programmer!), and I had to spend the last two months reading the latest Cisco manuals :-( Now I am beginning to find some time for my happy workflow hacking... and things have changed a lot, it seems. I think it's about time for it to happen. It may seem a little bit simplistic of my part, but I truly believe that the programmer's nirvana can only be attained when we manage to hide the dozen different tools that are necessary today behind a single & comprehensive framework. It makes no sense to me that we have to learn Python, JavaScript, HTML, CSS & SQL -- at a minimum! -- to become productive in this profession. The situation reminds me something about the beginnings of Windows programming; one had to know C, the Windows API, the format of resource files, the internals of event handling, memory models... just to write a simple application. Tools like VB & Delphi managed to hide all this complexity. I just feels that it's about time for it to happen for Web programming. -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: carribeiro at gmail.com mail: carribeiro at yahoo.com From faassen at infrae.com Mon May 2 23:29:47 2005 From: faassen at infrae.com (Martijn Faassen) Date: Mon, 02 May 2005 23:29:47 +0200 Subject: [Web-SIG] JavaScript libraries In-Reply-To: References: <42767070.7040500@colorstudy.com> <200505022035.52098.paul@boddie.org.uk> Message-ID: <42769BCB.7060709@infrae.com> Shannon -jj Behrens wrote: >>I was meaning to look into Sarissa (http://sarissa.sourceforge.net/doc/) which >>was mentioned somewhere at some point fairly recently. It doesn't interact >>with specific server-side functionality, but we can whip that up quite >>easily, can't we? ;-) > > > Wouldn't it be interesting if the web-sig community picked a > JavaScript library they all liked and mass invaded/contributed to it > ;) Gees, with the WSGI thing, and the JavaScript thing, we'd > definitely be going in the right direction! The kupu community (kupu.oscom.org) is full of Python hackers doing Javascript. They're also using Sarissa and know the guy who does that. I'd definitely get in touch with them if you want to invade Javascript space. :) Regards, Martijn From jjinux at gmail.com Mon May 2 23:34:28 2005 From: jjinux at gmail.com (Shannon -jj Behrens) Date: Mon, 2 May 2005 14:34:28 -0700 Subject: [Web-SIG] JavaScript libraries In-Reply-To: <864d370905050214292f09ccb0@mail.gmail.com> References: <20050429202207.GA26081@detroit.slack.net> <4275B15C.1090004@colorstudy.com> <864d370905050214292f09ccb0@mail.gmail.com> Message-ID: On 5/2/05, Carlos Ribeiro wrote: > On 5/2/05, Shannon -jj Behrens wrote: > > It sure would be nice to have a common JavaScript library that we > > could all share. People are wanting this for Aquarium, but I really > > don't want Aquarium to have its own JavaScript library. It's too much > > of a niche within a niche. Do you guys think it'd be possible to use > > the RoR one? I've often talked with Donnovan about using LivePage > > from Nevow. Do you guys know of any other really solid JavaScript > > libraries? > > Just for the record. > > I have spent six months writing a web-based workflow framework using > CherryPy on my own time. I experimented a little bit with several > templating systems, and one of the main problems that I had was with > the integration of JavaScript code. I thought, "I want to code in one > language as much as possible, and that's Python". So I wanted to have > a templating system that allowed me to forget about writing custom > Javascript code. > > After lots of painful experiments, I wrote a simple form-based library > drawing on my experience with Delphi and other event-based toolsets. > Forms are composed of components; each component has associated > events. Event handlers are split in two parts: the form library itself > generates a Javascript callback using an IFrame (the code was borrowed > almost line-by-line from the example in the Apple's Developers site, > and worked off the shelf!). This callback in turn is automatically > associated with the even handler that is written in Python. The system > was amazingly simple and intuitive. The best part, I didn't had to > write custom Javascript code; I could rely on Python to handle events > that were fired into the web browser, using my two-way glue code. Yes, this sounds like Nevow's LivePage. I saw Donnovan give a talk on it both at Bay Piggies and at PyCon, and it's really nice. I agree that this is cool stuff! > All of this was prior to Ajax. I heard about it and it seemed to be > something along the same lines of the work that I was doing, but at > that time, I was hired for another project (I am a network architect > by profession, not a programmer!), and I had to spend the last two > months reading the latest Cisco manuals :-( You have my sympathies. > Now I am beginning to find some time for my happy workflow hacking... > and things have changed a lot, it seems. I think it's about time for > it to happen. It may seem a little bit simplistic of my part, but I > truly believe that the programmer's nirvana can only be attained when > we manage to hide the dozen different tools that are necessary today > behind a single & comprehensive framework. It makes no sense to me > that we have to learn Python, JavaScript, HTML, CSS & SQL -- at a > minimum! -- to become productive in this profession. > > The situation reminds me something about the beginnings of Windows > programming; one had to know C, the Windows API, the format of > resource files, the internals of event handling, memory models... just > to write a simple application. Tools like VB & Delphi managed to hide > all this complexity. I just feels that it's about time for it to > happen for Web programming. Perhaps you're right. Best Regards, -jj -- I have decided to switch to Gmail, but messages to my Yahoo account will still get through. From dp at ulaluma.com Tue May 3 00:02:30 2005 From: dp at ulaluma.com (Donovan Preston) Date: Mon, 2 May 2005 15:02:30 -0700 Subject: [Web-SIG] JavaScript libraries In-Reply-To: References: <42767070.7040500@colorstudy.com> <200505022035.52098.paul@boddie.org.uk> <5978.66.192.34.8.1115060330.squirrel@66.192.34.8> Message-ID: On May 2, 2005, at 1:30 PM, Shannon -jj Behrens wrote: > On 5/2/05, mike bayer wrote: > >> what kind of features are you looking for in these javascript >> libraries ? >> > > The "Dynamic HTML" book from O'Reilly has the beginnings of what I'm > looking for. It is a compatibility layer so that things like layers, > repositioning, etc. work cross-platform. I think the code could have > been better and more extensive, so I'm hoping someone out there has > seen such a library. A lot of things in JavaScript are very rough and > basic, sort of like C. I fear I've steered this mailing list very off > topic, for which I apologize. Accept it as a compliment for the > shared brain power of this list. ;) I think there is no substitute for experience. Personally I have found that using abstractions which try to shield you from browser unpleasantness merely obscure the real source of the error or incompatibility which inevitably happens anyway. Of course, not everyone has the time or patience to accumulate the needed experience. With the renewed interest in DHTML thanks to gmail, Google Maps, and AJAX, I think it is time to set up some community specifically to discuss modern javascript techniques. Searching the web yields pitiful results, with lots of ancient javascript designed for copy-and-pasters who want rollovers on their animated gifs. The shared brain power of a new list and web site which attracted users from communities other than the Python community could be valuable, as well. At the same time, we could subtly enlighten people to the joys of Python just by exposing them to it. Donovan From dp at ulaluma.com Tue May 3 00:23:15 2005 From: dp at ulaluma.com (Donovan Preston) Date: Mon, 2 May 2005 15:23:15 -0700 Subject: [Web-SIG] JavaScript libraries In-Reply-To: <864d370905050214292f09ccb0@mail.gmail.com> References: <57015.66.192.34.8.1114784644.squirrel@66.192.34.8> <20050429202207.GA26081@detroit.slack.net> <4275B15C.1090004@colorstudy.com> <864d370905050214292f09ccb0@mail.gmail.com> Message-ID: <8C4832D5-6702-4490-8419-B1B2C6EC61FE@ulaluma.com> On May 2, 2005, at 2:29 PM, Carlos Ribeiro wrote: > On 5/2/05, Shannon -jj Behrens wrote: > >> It sure would be nice to have a common JavaScript library that we >> could all share. People are wanting this for Aquarium, but I really >> don't want Aquarium to have its own JavaScript library. It's too >> much >> of a niche within a niche. Do you guys think it'd be possible to use >> the RoR one? I've often talked with Donnovan about using LivePage >> from Nevow. Do you guys know of any other really solid JavaScript >> libraries? >> > > Just for the record. > > I have spent six months writing a web-based workflow framework using > CherryPy on my own time. I experimented a little bit with several > templating systems, and one of the main problems that I had was with > the integration of JavaScript code. I thought, "I want to code in one > language as much as possible, and that's Python". So I wanted to have > a templating system that allowed me to forget about writing custom > Javascript code. > > After lots of painful experiments, I wrote a simple form-based library > drawing on my experience with Delphi and other event-based toolsets. > Forms are composed of components; each component has associated > events. Event handlers are split in two parts: the form library itself > generates a Javascript callback using an IFrame (the code was borrowed > almost line-by-line from the example in the Apple's Developers site, > and worked off the shelf!). This callback in turn is automatically > associated with the even handler that is written in Python. The system > was amazingly simple and intuitive. The best part, I didn't had to > write custom Javascript code; I could rely on Python to handle events > that were fired into the web browser, using my two-way glue code. You just described what LivePage in both Woven and Nevow has been doing for 4 years now. I'm not saying you should have discovered or used LivePage instead, I'm glad other people are finally starting to realize what my vision was, and realize that I'm not crazy! > All of this was prior to Ajax. I heard about it and it seemed to be > something along the same lines of the work that I was doing, but at > that time, I was hired for another project (I am a network architect > by profession, not a programmer!), and I had to spend the last two > months reading the latest Cisco manuals :-( Ajax is just a re-branding of things that have been possible cross- browser for a long time; it's just that nobody's boss believed them (including mine). DHTML is too 1998 for it to be a good boss- convincing tool, so Ajax was born. It took a company that was seriously dedicated to the web (Google) and some apps that were willing to throw the rules out the window and keep the scope small so they could succeed (gmail, Google Suggest and Google Maps), but finally bosses around the world are able to point at something and say "I want that!" Ajax is just a convenient way to talk about it. > Now I am beginning to find some time for my happy workflow hacking... > and things have changed a lot, it seems. I think it's about time for > it to happen. It may seem a little bit simplistic of my part, but I > truly believe that the programmer's nirvana can only be attained when > we manage to hide the dozen different tools that are necessary today > behind a single & comprehensive framework. It makes no sense to me > that we have to learn Python, JavaScript, HTML, CSS & SQL -- at a > minimum! -- to become productive in this profession. I agree it would be nice, but I am convinced it is currently unrealistic. The only reason for the current renaissance in rich browser UI is that people are willing to actually dig in and write lots of JavaScript. There is a Nirvana out there, but you are not going to get there through a modern web browser. Too many bugs remain on both sides of the fence and too many old browsers must be supported. I had this dream when I first started writing Woven. I finally had to admit to myself that there were too many corner cases, and a framework which doesn't let you work around a bug in a browser is just a straightjacket, not a framework. With Nevow I have tried to take things more slowly, starting from the bottom, trying to build a thin, simple, sane way to get HTML into a browser which tries as much as possible to get out of your way and let you do your work. Someday I hope we can get to a place where you write an app entirely in Python and deploy it in a Python, JavaScript, HTML, CSS, and SQL environment... but it'll be a while. > The situation reminds me something about the beginnings of Windows > programming; one had to know C, the Windows API, the format of > resource files, the internals of event handling, memory models... just > to write a simple application. Tools like VB & Delphi managed to hide > all this complexity. I just feels that it's about time for it to > happen for Web programming. The problem is that there are good abstractions, and leaky abstractions. Good abstractions are built on top of solid foundations, which the current browser bug mess is not. Leaky abstractions are when the guts of the implementation of the browsers leak through, and a leaky abstraction is worse than no abstraction because it is harder to debug. I have a dream that something better will arise and replace the browser, but I'm not holding my breath there, either. I hope I don't sound too pessimistic... I'm still optimistic that web programming can become enjoyable. I'm just being realistic after being beaten down too many times before :-) Donovan From mike_mp at zzzcomputing.com Tue May 3 00:23:56 2005 From: mike_mp at zzzcomputing.com (mike bayer) Date: Mon, 2 May 2005 18:23:56 -0400 (EDT) Subject: [Web-SIG] JavaScript libraries In-Reply-To: <864d370905050214292f09ccb0@mail.gmail.com> References: <57015.66.192.34.8.1114784644.squirrel@66.192.34.8> <20050429202207.GA26081@detroit.slack.net> <4275B15C.1090004@colorstudy.com> <864d370905050214292f09ccb0@mail.gmail.com> Message-ID: <58335.66.192.34.8.1115072636.squirrel@66.192.34.8> > Now I am beginning to find some time for my happy workflow hacking... > and things have changed a lot, it seems. I think it's about time for > it to happen. It may seem a little bit simplistic of my part, but I > truly believe that the programmer's nirvana can only be attained when > we manage to hide the dozen different tools that are necessary today > behind a single & comprehensive framework. It makes no sense to me > that we have to learn Python, JavaScript, HTML, CSS & SQL -- at a > minimum! -- to become productive in this profession. > I can see the great value of abstracting away javascript events into a clean Python layer, so that custom application logic from client to server back to client again is coded in pure Python. All the Ajax libraries are trying to achieve this in various ways. I would agree less with regards to HTML and CSS, where I'd rather have HTML designers bringing their pre-made pages to me (and also allowing them to maintain the layout)...its less like a low level application library and more like the graphical facade placed on an application. Of course if someone ever designed a graphical WYSIWYG HTML/CSS editor that could do everything any designer ever wanted, and it generated sets of Python objects, that might make it more practical. With SQL an excessive amount of abstraction on the query side makes it hard to analyze and optimize queries, factor out performance bottlenecks, or to interface well with DBAs who would prefer to dictate the style and shape of queries from a pure SQL perspective. Abstration of the object-relational properties of result sets are a lot easier to manage, if you can flexibly define the information that should come out of those result sets. I think the query side of SQL wont be totally ignorable until true object databases begin gaining widespread acceptance. From renesd at gmail.com Tue May 3 01:37:41 2005 From: renesd at gmail.com (Rene Dudfield) Date: Tue, 3 May 2005 09:37:41 +1000 Subject: [Web-SIG] JavaScript libraries In-Reply-To: <42767070.7040500@colorstudy.com> References: <20050429202207.GA26081@detroit.slack.net> <4275B15C.1090004@colorstudy.com> <42767070.7040500@colorstudy.com> Message-ID: <64ddb72c050502163730abd19c@mail.gmail.com> Hello, I've been doing a lot of javascript stuff recently with http://www.pretendpaper.com/ So far javascript has been 90% of the time I have spent on the site. At the begining I was using dynapi for some javascript stuff. Which is quite an ok javascript library. However as the abstraction was really big fixing the many bugs for new things I was doing was harder. If you can live with what you get with dynapi, it is a really good library which can go a long way towards making code compatible to even NS 4.0. So definitely look at DynAPI, as well as the quirksmode, and jsolait sites for javascript libraries and ideas. I have a bunch of javascript stuff which is not on the pretendpaper.com live site because it crashes browsers hard. So far I have crashed most browsers many times. Most recently a safari crash which made the browser unusable on that computer despite best efforts to wipe the cache, and all settings :( Then there are event timing issues, which are all different with each browser. I haven't quite figured out all the work arounds with different versions of IE yet. I am also forced to use iframes for scrolling at the moment. As it has been quite hard to get javascript scrolling of layers working nicely even across the latest versions of safari, firefox and ie. It might be one place where I will need different implementations for different browsers. Once the DHTML version of the site is working nicely with the latest browsers I am going to do a static version of the site. The static version will be very light on css(which is also very crashable), and pretty much no js/flash. I am using xmlrpc for the python -> javascript comunication. With jsolait. This could be swapped out with jsonrpc later if needed. As xmlrpc is a little bit slow with js. jsonrpc doesn't have to parse xml with javascript, so it is lots faster. xmlrpc can also be used to talk to flash, as well as lots of other libraries easily like C++/php etc. Exporting stuff later from python is simple... exporting things to SOAP/JSONRPC/Pyro will be quite trivial. Javascript is a really nice language. It is well worth learning for people doing web development, as there are so many good things you can do with it. You can also use it within flash too. As flash actionscript is pretty much javascript with a different api. However the biggest problem is still working around the bugs, and different implementations behaviours. Cheers, Rene Dudfield e: "@".join( reversed(['madecollective.com', 'rene']) ) w: http://www.madecollective.com/ w: http://www.pretendpaper.com/ For creative, and technical services contact us @ made. From floydophone at gmail.com Tue May 3 02:47:23 2005 From: floydophone at gmail.com (Peter Hunt) Date: Mon, 2 May 2005 20:47:23 -0400 Subject: [Web-SIG] JavaScript libraries Message-ID: <6654eac405050217474cb95c1f@mail.gmail.com> 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? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/web-sig/attachments/20050502/607a8eb5/attachment.htm From foom at fuhm.net Tue May 3 02:51:22 2005 From: foom at fuhm.net (James Y Knight) Date: Mon, 2 May 2005 20:51:22 -0400 Subject: [Web-SIG] JavaScript libraries In-Reply-To: <6654eac405050217474cb95c1f@mail.gmail.com> References: <6654eac405050217474cb95c1f@mail.gmail.com> Message-ID: On May 2, 2005, at 8:47 PM, Peter Hunt wrote: > 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? I think that's exactly what Donovan's LivePage does. James From jjinux at gmail.com Tue May 3 03:22:52 2005 From: jjinux at gmail.com (Shannon -jj Behrens) Date: Mon, 2 May 2005 18:22:52 -0700 Subject: [Web-SIG] JavaScript libraries In-Reply-To: References: <6654eac405050217474cb95c1f@mail.gmail.com> Message-ID: On 5/2/05, James Y Knight wrote: > On May 2, 2005, at 8:47 PM, Peter Hunt wrote: > > 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? > > I think that's exactly what Donovan's LivePage does. Yep. Exactly. -jj -- I have decided to switch to Gmail, but messages to my Yahoo account will still get through. From dp at ulaluma.com Tue May 3 03:23:22 2005 From: dp at ulaluma.com (Donovan Preston) Date: Mon, 2 May 2005 18:23:22 -0700 Subject: [Web-SIG] JavaScript libraries In-Reply-To: <6654eac405050217474cb95c1f@mail.gmail.com> References: <6654eac405050217474cb95c1f@mail.gmail.com> Message-ID: On May 2, 2005, at 5:47 PM, Peter Hunt wrote: > 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. This is awesome, thank you for posting the link. I had planned on doing something similar to this for a long time, for both JavaScript and ActionScript (flash bytecode instead of text script). However LivePage is just a hobby for me, so I never found time. > 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? Yep, this is almost exactly what LivePage looks like. def onButtonClick(client): client.sendScript("alert('hello world')") class Foo(LivePage): def render_clickable(self, ctx, _): return ctx.tag(onclick=handler(onButtonClick)) docFactory = loaders.htmlstr('') I think I like your proposed syntax, with a "server" object in javascript; I'll mess around with adding support for something like it to LivePage. I'm not sure I like the magical proxy server-side interface too much. nevow.livepage.ClientHandle has a nice API which provides convenient methods for mutating the client side dom: set - replace an old node's contents with some new contents append - append a new node as a child of an old one prepend - prepend a new node as the first child of an old one alert - show the user an alert call - call a client side javascript function with some arguments sendScript - send arbitrary javascript for execution Donovan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/web-sig/attachments/20050502/96ade40c/attachment.html From ianb at colorstudy.com Tue May 3 04:11:40 2005 From: ianb at colorstudy.com (Ian Bicking) Date: Mon, 02 May 2005 21:11:40 -0500 Subject: [Web-SIG] JavaScript libraries In-Reply-To: References: <42767070.7040500@colorstudy.com> <200505022035.52098.paul@boddie.org.uk> <5978.66.192.34.8.1115060330.squirrel@66.192.34.8> Message-ID: <4276DDDC.2080901@colorstudy.com> Donovan Preston wrote: > I think there is no substitute for experience. Personally I have > found that using abstractions which try to shield you from browser > unpleasantness merely obscure the real source of the error or > incompatibility which inevitably happens anyway. I don't think you can Make Anything Possible given the right library, and I think overambitious efforts (especially ones that cover up Javascript entirely) are unlike to succede. But the library can give direction, and help keep wary developers from venturing into difficult territory. Libraries embody a lot of knowledge beyond their functionality. If you emphasize innerHTML-based functionality because it works, then you've indirectly saved the library users time and headaches. In this way a more limited library that emphasizes the easiest constructs could be very useful. This is why I personally am looking for that small library that does all the convenient or particularly useful things I'm interested in, and does them really well, but doesn't get too fancy. > Of course, not everyone has the time or patience to accumulate the > needed experience. With the renewed interest in DHTML thanks to > gmail, Google Maps, and AJAX, I think it is time to set up some > community specifically to discuss modern javascript techniques. > Searching the web yields pitiful results, with lots of ancient > javascript designed for copy-and-pasters who want rollovers on their > animated gifs. > > The shared brain power of a new list and web site which attracted > users from communities other than the Python community could be > valuable, as well. At the same time, we could subtly enlighten people > to the joys of Python just by exposing them to it. The Javascript development community is young in other ways. Public repositories and basic open source project management practices are uncommon. We're still getting over a stage where everything is presented as recipes instead of working code; I think that's widely recognized, but it doesn't mean that there are a lot of good patterns for how to do that. And the prototype stuff makes it hard for OO programmers to get their bearings. Little things have left me feeling unsure. Just to give one example, how should I "activate" a library? Should it run onload automatically and search the page for activating elements? I guess that's kind of the "unobtrusive" technique, but it often seems rather wasteful. Should it be activated by a function call? How are options passed in (and later managed)? Should it involve a prototype for storing options, then methods for attaching the object to elements on the page? Hell, I still don't understand prototypes in Javascript at all. It's this stuff where I get confused, and so I'm actually looking for more than a Javascript library to smooth out a few rough edges -- I want a model for good Javascript development that I can learn from. -- Ian Bicking / ianb at colorstudy.com / http://blog.ianbicking.org From jjinux at gmail.com Tue May 3 07:01:27 2005 From: jjinux at gmail.com (Shannon -jj Behrens) Date: Mon, 2 May 2005 22:01:27 -0700 Subject: [Web-SIG] JavaScript libraries In-Reply-To: <4276DDDC.2080901@colorstudy.com> References: <42767070.7040500@colorstudy.com> <200505022035.52098.paul@boddie.org.uk> <5978.66.192.34.8.1115060330.squirrel@66.192.34.8> <4276DDDC.2080901@colorstudy.com> Message-ID: I actually read the Dynamic HTML book and have a lot of good ideas on how to make a good JavaScript library. I was just hoping I wouldn't have to ;) I'm hoping Kupu meets my needs. JavaScript's not a bad language. It's just very misunderstood, very abused, and a bit undeveloped. It's really the DOM that causes the most problems. :-/ Oh well, sorry for the distraction. Best Regards, -jj On 5/2/05, Ian Bicking wrote: > Donovan Preston wrote: > > I think there is no substitute for experience. Personally I have > > found that using abstractions which try to shield you from browser > > unpleasantness merely obscure the real source of the error or > > incompatibility which inevitably happens anyway. > > I don't think you can Make Anything Possible given the right library, > and I think overambitious efforts (especially ones that cover up > Javascript entirely) are unlike to succede. But the library can give > direction, and help keep wary developers from venturing into difficult > territory. Libraries embody a lot of knowledge beyond their > functionality. If you emphasize innerHTML-based functionality because > it works, then you've indirectly saved the library users time and > headaches. In this way a more limited library that emphasizes the > easiest constructs could be very useful. > > This is why I personally am looking for that small library that does all > the convenient or particularly useful things I'm interested in, and does > them really well, but doesn't get too fancy. > > > Of course, not everyone has the time or patience to accumulate the > > needed experience. With the renewed interest in DHTML thanks to > > gmail, Google Maps, and AJAX, I think it is time to set up some > > community specifically to discuss modern javascript techniques. > > Searching the web yields pitiful results, with lots of ancient > > javascript designed for copy-and-pasters who want rollovers on their > > animated gifs. > > > > The shared brain power of a new list and web site which attracted > > users from communities other than the Python community could be > > valuable, as well. At the same time, we could subtly enlighten people > > to the joys of Python just by exposing them to it. > > The Javascript development community is young in other ways. Public > repositories and basic open source project management practices are > uncommon. We're still getting over a stage where everything is > presented as recipes instead of working code; I think that's widely > recognized, but it doesn't mean that there are a lot of good patterns > for how to do that. And the prototype stuff makes it hard for OO > programmers to get their bearings. > > Little things have left me feeling unsure. Just to give one example, > how should I "activate" a library? Should it run onload automatically > and search the page for activating elements? I guess that's kind of the > "unobtrusive" technique, but it often seems rather wasteful. Should it > be activated by a function call? How are options passed in (and later > managed)? Should it involve a prototype for storing options, then > methods for attaching the object to elements on the page? Hell, I still > don't understand prototypes in Javascript at all. It's this stuff where > I get confused, and so I'm actually looking for more than a Javascript > library to smooth out a few rough edges -- I want a model for good > Javascript development that I can learn from. > > -- > Ian Bicking / ianb at colorstudy.com / http://blog.ianbicking.org > _______________________________________________ > Web-SIG mailing list > Web-SIG at python.org > Web SIG: http://www.python.org/sigs/web-sig > Unsubscribe: http://mail.python.org/mailman/options/web-sig/jjinux%40gmail.com > -- I have decided to switch to Gmail, but messages to my Yahoo account will still get through. From fumanchu at amor.org Tue May 3 08:46:13 2005 From: fumanchu at amor.org (Robert Brewer) Date: Mon, 2 May 2005 23:46:13 -0700 Subject: [Web-SIG] JavaScript libraries Message-ID: <3A81C87DC164034AA4E2DDFE11D258E3771F2A@exchange.hqamor.amorhq.net> Ian Bicking wrote: > Donovan Preston wrote: > > I think there is no substitute for experience. Personally I have > > found that using abstractions which try to shield you from browser > > unpleasantness merely obscure the real source of the error or > > incompatibility which inevitably happens anyway. > > I don't think you can Make Anything Possible given the right library, > and I think overambitious efforts (especially ones that cover up > Javascript entirely) are unlike to succede. But the library can give > direction, and help keep wary developers from venturing into > difficult territory. Libraries embody a lot of knowledge beyond > their functionality. If you emphasize innerHTML-based > functionality because it works, then you've indirectly saved > the library users time and headaches. In this way a more > limited library that emphasizes the easiest constructs > could be very useful. > > This is why I personally am looking for that small library > that does all the convenient or particularly useful things > I'm interested in, and does them really well, but doesn't > get too fancy. Jumping off of that, the thing that's highest on my list of "getting too fancy" right now is Creating Yet Another RPC Mechanism. But perhaps I've been drinking too much RESTful Kool-Aid lately, cf. http://naeblis.cx/rtomayko/2005/04/22/on-http-abuse. I'm much more interested in giving Javascript developers access to Python-backed web services, than in getting a Python library which generates Javascript. The problem I see with shoving Javascript-generation into your (Python) backend is that the server and the client cannot then be developed independently. Ajax is a stellar recent example of this, because many current instances of Ajax are simply retoolings of POST pages--the consumer has found a new request technique and _does not need_ that to be integrated into the server in order to improve itself. I guess I'm looking for an approach with looser coupling between browser and server than what I've seen either in form-generation frameworks, or those which push Javascript statements to the browser at whatever pace. I mention "statements" as opposed to "just data", whether in XML or JSON or some other form. So I suppose I'm already in the doghouse with respect to -jj, who started this thread talking about LivePage. ;) /thinking *really* hard now about never hard-refreshing a web page again, Robert Brewer MIS Amor Ministries fumanchu at amor.org From david at sundayta.com Tue May 3 10:59:56 2005 From: david at sundayta.com (Dave Warnock) Date: Tue, 03 May 2005 09:59:56 +0100 Subject: [Web-SIG] JavaScript libraries In-Reply-To: <3A81C87DC164034AA4E2DDFE11D258E3771F2A@exchange.hqamor.amorhq.net> References: <3A81C87DC164034AA4E2DDFE11D258E3771F2A@exchange.hqamor.amorhq.net> Message-ID: <42773D8C.3050309@sundayta.com> Robert, I am with you. Ian mentioned wanting the javascript to be agnostic about the back end (ie work for servers in any python framework and even ones in other languages). I think the same should be true for the front end. The server should not be producing special output for a javascript front end. Instead the server should have a standard RESTful API that any front end tool can use. One thing I have found is that when you have a good RESTful api to the server it becomes much much easier to script the server. If the server spurts javascript you lose this ability. If the server is RESTful then frontends in flash or whatever are just as possible. Dave From faassen at infrae.com Tue May 3 11:38:33 2005 From: faassen at infrae.com (Martijn Faassen) Date: Tue, 03 May 2005 11:38:33 +0200 Subject: [Web-SIG] JavaScript libraries In-Reply-To: References: <42767070.7040500@colorstudy.com> <200505022035.52098.paul@boddie.org.uk> <5978.66.192.34.8.1115060330.squirrel@66.192.34.8> Message-ID: <42774699.40708@infrae.com> Donovan Preston wrote: [snip] > The shared brain power of a new list and web site which attracted > users from communities other than the Python community could be > valuable, as well. At the same time, we could subtly enlighten people > to the joys of Python just by exposing them to it. Sounds good. I could see whether I could rope codespeak.net into hosting this. Theyr'e already hosting kupu, too. It's a nice informal and neutral place. Want me to? Regards, Martijn From faassen at infrae.com Tue May 3 11:40:49 2005 From: faassen at infrae.com (Martijn Faassen) Date: Tue, 03 May 2005 11:40:49 +0200 Subject: [Web-SIG] JavaScript libraries In-Reply-To: References: <42767070.7040500@colorstudy.com> <200505022035.52098.paul@boddie.org.uk> <5978.66.192.34.8.1115060330.squirrel@66.192.34.8> <4276DDDC.2080901@colorstudy.com> Message-ID: <42774721.4080301@infrae.com> Shannon -jj Behrens wrote: > I actually read the Dynamic HTML book and have a lot of good ideas on > how to make a good JavaScript library. I was just hoping I wouldn't > have to ;) I'm hoping Kupu meets my needs. JavaScript's not a bad > language. It's just very misunderstood, very abused, and a bit > undeveloped. It's really the DOM that causes the most problems. :-/ > Just to clarify: Kupu is *not* a generic javascript library, it's a framework for building WYSIWYG editors. It just involves a ton of javascript and it's done by mature software developers with experience in other programming languages, so it's version controlled, there's release management, etc. Regards, Martijn From jjinux at gmail.com Tue May 3 19:29:27 2005 From: jjinux at gmail.com (Shannon -jj Behrens) Date: Tue, 3 May 2005 10:29:27 -0700 Subject: [Web-SIG] JavaScript libraries In-Reply-To: <42774699.40708@infrae.com> References: <42767070.7040500@colorstudy.com> <200505022035.52098.paul@boddie.org.uk> <5978.66.192.34.8.1115060330.squirrel@66.192.34.8> <42774699.40708@infrae.com> Message-ID: On 5/3/05, Martijn Faassen wrote: > Donovan Preston wrote: > [snip] > > The shared brain power of a new list and web site which attracted > > users from communities other than the Python community could be > > valuable, as well. At the same time, we could subtly enlighten people > > to the joys of Python just by exposing them to it. > > Sounds good. I could see whether I could rope codespeak.net into hosting > this. Theyr'e already hosting kupu, too. It's a nice informal and > neutral place. Want me to? I'm personally hesitant to reinvent the wheel just yet. *Someone* must have done a really good, general-purpose, widely-supported JavaScript library! Has anyone looked jsLib ? Best Regards, -jj -- I have decided to switch to Gmail, but messages to my Yahoo account will still get through. From dp at ulaluma.com Tue May 3 19:57:38 2005 From: dp at ulaluma.com (Donovan Preston) Date: Tue, 3 May 2005 10:57:38 -0700 Subject: [Web-SIG] JavaScript libraries In-Reply-To: References: <42767070.7040500@colorstudy.com> <200505022035.52098.paul@boddie.org.uk> <5978.66.192.34.8.1115060330.squirrel@66.192.34.8> <42774699.40708@infrae.com> Message-ID: On May 3, 2005, at 10:29 AM, Shannon -jj Behrens wrote: > On 5/3/05, Martijn Faassen wrote: > >> Donovan Preston wrote: >> [snip] >> >>> The shared brain power of a new list and web site which attracted >>> users from communities other than the Python community could be >>> valuable, as well. At the same time, we could subtly enlighten >>> people >>> to the joys of Python just by exposing them to it. >>> >> >> Sounds good. I could see whether I could rope codespeak.net into >> hosting >> this. Theyr'e already hosting kupu, too. It's a nice informal and >> neutral place. Want me to? >> > > I'm personally hesitant to reinvent the wheel just yet. *Someone* > must have done a really good, general-purpose, widely-supported > JavaScript library! Has anyone looked jsLib > application=firefox&category=Developer%20Tools&numpg=10&id=257>? I didn't say that I wanted to reinvent the wheel of javascript libraries. What I was proposing was creating a mailing list and web site focused on advanced javascript techniques (with no libraries. I have said before that I don't think JS libraries really work). My main goal would be to have more discussions like the one we are having now, except with a wider community than the Python community. Martijn, if codespeak would like to host a forum for these discussions, keeping in mind the goal is not to produce a JS library, that would be nice. I can also host it myself with no trouble. I'll look into how much work it would be to host it myself -- I might as well put my money where my mouth is :-) Donovan From jjinux at gmail.com Tue May 3 20:01:10 2005 From: jjinux at gmail.com (Shannon -jj Behrens) Date: Tue, 3 May 2005 11:01:10 -0700 Subject: [Web-SIG] JavaScript libraries In-Reply-To: References: <42767070.7040500@colorstudy.com> <200505022035.52098.paul@boddie.org.uk> <5978.66.192.34.8.1115060330.squirrel@66.192.34.8> <42774699.40708@infrae.com> Message-ID: On 5/3/05, Donovan Preston wrote: > > On May 3, 2005, at 10:29 AM, Shannon -jj Behrens wrote: > > > On 5/3/05, Martijn Faassen wrote: > > > >> Donovan Preston wrote: > >> [snip] > >> > >>> The shared brain power of a new list and web site which attracted > >>> users from communities other than the Python community could be > >>> valuable, as well. At the same time, we could subtly enlighten > >>> people > >>> to the joys of Python just by exposing them to it. > >>> > >> > >> Sounds good. I could see whether I could rope codespeak.net into > >> hosting > >> this. Theyr'e already hosting kupu, too. It's a nice informal and > >> neutral place. Want me to? > >> > > > > I'm personally hesitant to reinvent the wheel just yet. *Someone* > > must have done a really good, general-purpose, widely-supported > > JavaScript library! Has anyone looked jsLib > > > application=firefox&category=Developer%20Tools&numpg=10&id=257>? > > I didn't say that I wanted to reinvent the wheel of javascript > libraries. What I was proposing was creating a mailing list and web > site focused on advanced javascript techniques (with no libraries. I > have said before that I don't think JS libraries really work). My > main goal would be to have more discussions like the one we are > having now, except with a wider community than the Python community. I apologize for misunderstanding you. > Martijn, if codespeak would like to host a forum for these > discussions, keeping in mind the goal is not to produce a JS library, > that would be nice. I can also host it myself with no trouble. I'll > look into how much work it would be to host it myself -- I might as > well put my money where my mouth is :-) SF.net is not perfect, but it gets my vote. Best Regards, -jj -- I have decided to switch to Gmail, but messages to my Yahoo account will still get through. From dp at ulaluma.com Tue May 3 20:16:59 2005 From: dp at ulaluma.com (Donovan Preston) Date: Tue, 3 May 2005 11:16:59 -0700 Subject: [Web-SIG] JavaScript libraries In-Reply-To: References: <42767070.7040500@colorstudy.com> <200505022035.52098.paul@boddie.org.uk> <5978.66.192.34.8.1115060330.squirrel@66.192.34.8> <42774699.40708@infrae.com> Message-ID: <6255E639-EDFA-4C12-96B0-6100D00BD60A@ulaluma.com> On May 3, 2005, at 11:01 AM, Shannon -jj Behrens wrote: > On 5/3/05, Donovan Preston wrote: >> I didn't say that I wanted to reinvent the wheel of javascript >> libraries. What I was proposing was creating a mailing list and web >> site focused on advanced javascript techniques (with no libraries. I >> have said before that I don't think JS libraries really work). My >> main goal would be to have more discussions like the one we are >> having now, except with a wider community than the Python community. > > I apologize for misunderstanding you. No problem -- it's email :-) I originally misunderstood what Martijn said, and it wasn't until I reread it in the context of your quote that I understood. Before I reinvent the wheel of creating new mailing lists, I will spend some time scouring weblogs and web framework project pages for projects which are incorporating AJAX features (rails, etc). If I find another community which is suitable, I'll suggest interested people join that instead. In case I don't find something which looks suitable, how many people on this list would be interested? Any suggestions for what it should be called, and what it should cover? I am generally interested in sparking discussion of modern JavaScript techniques in general, not just AJAX out of band client to server communication. > SF.net is not perfect, but it gets my vote. I wouldn't want to touch SF with a ten-foot pole, sorry. :-( Donovan From ianb at colorstudy.com Tue May 3 21:00:06 2005 From: ianb at colorstudy.com (Ian Bicking) Date: Tue, 03 May 2005 14:00:06 -0500 Subject: [Web-SIG] JavaScript libraries In-Reply-To: <6255E639-EDFA-4C12-96B0-6100D00BD60A@ulaluma.com> References: <42767070.7040500@colorstudy.com> <200505022035.52098.paul@boddie.org.uk> <5978.66.192.34.8.1115060330.squirrel@66.192.34.8> <42774699.40708@infrae.com> <6255E639-EDFA-4C12-96B0-6100D00BD60A@ulaluma.com> Message-ID: <4277CA36.8050609@colorstudy.com> Donovan Preston wrote: > Before I reinvent the wheel of creating new mailing lists, I will > spend some time scouring weblogs and web framework project pages for > projects which are incorporating AJAX features (rails, etc). If I > find another community which is suitable, I'll suggest interested > people join that instead. That would be very helpful. I think whatever it is we want is out there, somewhere, at least in some early form, but I'm not sure I'd know it if I found it. Like a lot of people here, I'm just looking for the opinion of someone with more domain experience; otherwise it's the blind leading the blind when we ask the Python web group about Javascript ;) -- Ian Bicking / ianb at colorstudy.com / http://blog.ianbicking.org From mike_mp at zzzcomputing.com Tue May 3 21:18:09 2005 From: mike_mp at zzzcomputing.com (mike bayer) Date: Tue, 3 May 2005 15:18:09 -0400 (EDT) Subject: [Web-SIG] JavaScript libraries In-Reply-To: <6255E639-EDFA-4C12-96B0-6100D00BD60A@ulaluma.com> References: <42767070.7040500@colorstudy.com> <200505022035.52098.paul@boddie.org.uk> <5978.66.192.34.8.1115060330.squirrel@66.192.34.8> <42774699.40708@infrae.com> <6255E639-EDFA-4C12-96B0-6100D00BD60A@ulaluma.com> Message-ID: <3334.66.192.34.8.1115147889.squirrel@66.192.34.8> > >> SF.net is not perfect, but it gets my vote. > > I wouldn't want to touch SF with a ten-foot pole, sorry. :-( > thats interesting, what problems do you see with sf.net (just curious?) ? From jjinux at gmail.com Tue May 3 22:08:56 2005 From: jjinux at gmail.com (Shannon -jj Behrens) Date: Tue, 3 May 2005 13:08:56 -0700 Subject: [Web-SIG] JavaScript libraries In-Reply-To: <3334.66.192.34.8.1115147889.squirrel@66.192.34.8> References: <5978.66.192.34.8.1115060330.squirrel@66.192.34.8> <42774699.40708@infrae.com> <6255E639-EDFA-4C12-96B0-6100D00BD60A@ulaluma.com> <3334.66.192.34.8.1115147889.squirrel@66.192.34.8> Message-ID: > > I wouldn't want to touch SF with a ten-foot pole, sorry. :-( (humor) I've touched SF.net without a ten-foot pole, and lived to tell about it!!! -jj -- I have decided to switch to Gmail, but messages to my Yahoo account will still get through. From tracer at axiomfire.com Wed May 4 00:26:46 2005 From: tracer at axiomfire.com (Tracy S. Ruggles) Date: Tue, 3 May 2005 17:26:46 -0500 Subject: [Web-SIG] JavaScript libraries In-Reply-To: <6255E639-EDFA-4C12-96B0-6100D00BD60A@ulaluma.com> References: <42767070.7040500@colorstudy.com> <200505022035.52098.paul@boddie.org.uk> <5978.66.192.34.8.1115060330.squirrel@66.192.34.8> <42774699.40708@infrae.com> <6255E639-EDFA-4C12-96B0-6100D00BD60A@ulaluma.com> Message-ID: <9C9E0427-E798-4D25-83D0-4378D2D8E9D4@axiomfire.com> On May 3, 2005, at 1:16 PM, Donovan Preston wrote: > > In case I don't find something which looks suitable, how many people > on this list would be interested? Any suggestions for what it should > be called, and what it should cover? I am generally interested in > sparking discussion of modern JavaScript techniques in general, not > just AJAX out of band client to server communication. Count me in for participating in an advanced js discussion list. A name? Don't know. How about "grassroots-js", and the topics: - ajax (or any other form of asynchronous web app techniques) - form manipulation - design patterns in js - cross-platform abstraction layers - javascript with RESTian architectures - livepage'ish server to client techniques/applications - how to avoid using js - security - more? --Tracy From janssen at parc.com Wed May 4 00:42:37 2005 From: janssen at parc.com (Bill Janssen) Date: Tue, 3 May 2005 15:42:37 PDT Subject: [Web-SIG] JavaScript libraries In-Reply-To: Your message of "Tue, 03 May 2005 15:26:46 PDT." <9C9E0427-E798-4D25-83D0-4378D2D8E9D4@axiomfire.com> Message-ID: <05May3.154243pdt."58617"@synergy1.parc.xerox.com> >From the Python point of view, it might be interesting to have a Javascript (isn't it properly called ECMAscript?) interpreter that functions like one of the Python HTML parsers. That is, every time some javascript action happens, there's the opportunity to interpose some Python code. Bill From pje at telecommunity.com Wed May 4 01:38:50 2005 From: pje at telecommunity.com (Phillip J. Eby) Date: Tue, 03 May 2005 19:38:50 -0400 Subject: [Web-SIG] WSGI, PEP 340, and the close() method Message-ID: <5.1.1.6.0.20050503192912.029c53b0@mail.telecommunity.com> FYI, Guido has a new PEP under discussion on Python-Dev: PEP 340. Part of this PEP includes a new proposed mechanism for generator finalization that would eliminate PEP 325. Unfortunately, because I originally thought PEP 325 was a shoo-in, I made WSGI use a 'close()' method, thinking it would be automatically forward-compatible once PEP 325 landed. Now, however, it looks as though you'd have to do something like: if hasattr(retval,'__exit__'): try: retval.__exit__(StopIteration) except StopIteration: pass In order to "close" a generator. I don't know how important this actually is to PEP 333; I suspect that the number of times generators are being used as WSGI application objects is probably quite small, and of course reliance on this feature must currently be non-existent. Guido suggested that a simple decorator around generators used as WSGI applications should suffice to implement this behavior, and he's right. This wouldn't require any spec changes, except to clarify that generator finalization requires such a decorator, and to perhaps offer sample source for one. From faassen at infrae.com Wed May 4 13:03:47 2005 From: faassen at infrae.com (Martijn Faassen) Date: Wed, 04 May 2005 13:03:47 +0200 Subject: [Web-SIG] JavaScript libraries In-Reply-To: <6255E639-EDFA-4C12-96B0-6100D00BD60A@ulaluma.com> References: <42767070.7040500@colorstudy.com> <200505022035.52098.paul@boddie.org.uk> <5978.66.192.34.8.1115060330.squirrel@66.192.34.8> <42774699.40708@infrae.com> <6255E639-EDFA-4C12-96B0-6100D00BD60A@ulaluma.com> Message-ID: <4278AC13.9030205@infrae.com> Donovan Preston wrote: [snip] > Before I reinvent the wheel of creating new mailing lists, I will > spend some time scouring weblogs and web framework project pages for > projects which are incorporating AJAX features (rails, etc). If I > find another community which is suitable, I'll suggest interested > people join that instead. I'll wait until the result of this research, it would be good to not reinvent the wheel there. :) > In case I don't find something which looks suitable, how many people > on this list would be interested? Any suggestions for what it should > be called, and what it should cover? I am generally interested in > sparking discussion of modern JavaScript techniques in general, not > just AJAX out of band client to server communication. I'd be interested, though I don't know how much time I could spend on it. I imagine some of the Kupu people would also be interested. modern-javascript? advanced-javascript? >>SF.net is not perfect, but it gets my vote. > > I wouldn't want to touch SF with a ten-foot pole, sorry. :-( I'd prefer something else than SF too. Regards, Martijn From dstanek at dstanek.com Wed May 4 13:20:09 2005 From: dstanek at dstanek.com (david stanek) Date: Wed, 4 May 2005 06:20:09 -0500 Subject: [Web-SIG] JavaScript libraries In-Reply-To: References: <57015.66.192.34.8.1114784644.squirrel@66.192.34.8> <20050429202207.GA26081@detroit.slack.net> <4275B15C.1090004@colorstudy.com> Message-ID: <20050504112009.GA7865@goliath.hsd1.oh.comcast.net> Lots of suggestions in this thread, but has a concensus been reached? For a webmail application I am working on I have been creating JS client widgets and server communication code. It would definitely been nice to use a library from some of this, but there are too many variations. Sometimes it's just easier to do it from scratch. On Mon, May 02, 2005 at 11:20:29AM -0700, Shannon -jj Behrens wrote: > It sure would be nice to have a common JavaScript library that we > could all share. People are wanting this for Aquarium, but I really > don't want Aquarium to have its own JavaScript library. It's too much > of a niche within a niche. Do you guys think it'd be possible to use > the RoR one? I've often talked with Donnovan about using LivePage > from Nevow. Do you guys know of any other really solid JavaScript > libraries? -- david stanek www.roninds.net GPG keyID #6272EDAF on http://pgp.mit.edu Key fingerprint = 8BAA 7E11 8856 E148 6833 655A 92E2 3E00 6272 EDAF -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mail.python.org/pipermail/web-sig/attachments/20050504/3454e6a7/attachment.pgp From faassen at infrae.com Wed May 4 14:46:07 2005 From: faassen at infrae.com (Martijn Faassen) Date: Wed, 04 May 2005 14:46:07 +0200 Subject: [Web-SIG] JavaScript libraries In-Reply-To: <6255E639-EDFA-4C12-96B0-6100D00BD60A@ulaluma.com> References: <42767070.7040500@colorstudy.com> <200505022035.52098.paul@boddie.org.uk> <5978.66.192.34.8.1115060330.squirrel@66.192.34.8> <42774699.40708@infrae.com> <6255E639-EDFA-4C12-96B0-6100D00BD60A@ulaluma.com> Message-ID: <4278C40F.8090104@infrae.com> Donovan Preston wrote: [snip] > Before I reinvent the wheel of creating new mailing lists, I will > spend some time scouring weblogs and web framework project pages for > projects which are incorporating AJAX features (rails, etc). If I > find another community which is suitable, I'll suggest interested > people join that instead. I asked Infrae's resident Javascript guru (Guido Wesdorp), and he said he didn't know of such a advanced javascript forum. He had some discussions with other javascript hackers to set up such a thing, but they haven't done anything yet. Regards, Martijn From johnny at debris.demon.nl Thu May 5 10:38:49 2005 From: johnny at debris.demon.nl (Johnny deBris) Date: Thu, 05 May 2005 10:38:49 +0200 Subject: [Web-SIG] JavaScript libraries In-Reply-To: <4278C40F.8090104@infrae.com> References: <42767070.7040500@colorstudy.com> <200505022035.52098.paul@boddie.org.uk> <5978.66.192.34.8.1115060330.squirrel@66.192.34.8> <42774699.40708@infrae.com> <6255E639-EDFA-4C12-96B0-6100D00BD60A@ulaluma.com> <4278C40F.8090104@infrae.com> Message-ID: <4279DB99.9020702@debris.demon.nl> Martijn Faassen wrote: >I asked Infrae's resident Javascript guru (Guido Wesdorp), and he said >he didn't know of such a advanced javascript forum. He had some >discussions with other javascript hackers to set up such a thing, but >they haven't done anything yet. > > > Let me explain a bit: The last two years (or so) I've been hacking quite a lot of JavaScript. I wrote a large part of the Kupu application, as well as a number of libraries, of which some still need to be released (a SAX and DOM lib, although still pretty crude, can be downloaded from my website already, some other libs, such as a WebDAV library and a full DAV client, will follow later). Looking for patterns and base libraries, I have skimmed through quite a few websites, but didn't find any 'real' open-source communities out there, not even libraries or applications that have a larger set of developers: most of what I found was either written by a company or were one-person efforts. Also I didn't find a website where extensive documentation can be found, or a place to meet other serious JS hackers (apart from script-kiddies) or find proper open-source libs. I think, to be honest, that a discussion board would not be enough to really be helpful. What I would like to see would be something like SF meets Python.org, but then for JS only, a place for developers to meet, team up, find base libs, start a project and maintain it, but also for users to find proper libs, search a repository, find docs about advanced JS topics and such. I've been discussing such an initiative with a couple of other JS hackers, and they all seem interested, although obviously this will be a lot of work to set up and maintain. Since we're all very busy people (remember there's a lot to do for JS ;) we didn't actually get anything going yet, but perhaps we should asap. Of course, a helping hand would be greatly appreciated... Cheers, Guido From wilk-ml at flibuste.net Thu May 5 13:12:42 2005 From: wilk-ml at flibuste.net (Wilk) Date: Thu, 05 May 2005 13:12:42 +0200 Subject: [Web-SIG] long form and IE... wich server to choose ? Message-ID: <87fyx2diz9.fsf@blakie.riol> Hi, I have a problem with local server and IE with long form (with lot of ), sometimes IE post two times, sometimes IE answer "cannot show the page" (impossible d'afficher la page, en fran?ais). With firefox it works everytime... I tried with cherrpy but it has the same problem. I post here because i think this kind of problem should be resolved more easily if i do my application wsgi compliant and can try quickly somes wsgi servers. But it's curently not easy to find a wsgi server without a framework. I could do a short example with BaseHTTPServer (work with nb smaller): from BaseHTTPServer import HTTPServer from SimpleHTTPServer import SimpleHTTPRequestHandler import cgi import select class HTTPHandler (SimpleHTTPRequestHandler): server_version = "MonServeurHTTP/0.1" def do_GET(self): if self.path.find('?') != -1: self.path, self.requete = self.path.split('?', 1) else: self.requete = '' self.reponse() def do_POST(self): self.wfile.flush() self.requete = self.rfile.read(int(self.headers['Content-Length'])) while select.select([self.rfile], [], [], 0)[0]: if not self.rfile.read(1): break self.reponse() def reponse(self): self.page = self.path[1:-3] self.args = dict(cgi.parse_qsl(self.requete)) self.send_response(200, 'OK') self.send_header('Content-type', 'text/html') self.end_headers() nb = 500 self.wfile.write("""
%s
""" % (nb, "\n
".join(["" % d for d in range(nb)]))) httpd = HTTPServer(('', 8080), HTTPHandler) httpd.serve_forever() -- William - http://flibuste.net From jjinux at gmail.com Thu May 5 21:43:25 2005 From: jjinux at gmail.com (Shannon -jj Behrens) Date: Thu, 5 May 2005 12:43:25 -0700 Subject: [Web-SIG] JavaScript libraries In-Reply-To: <4279DB99.9020702@debris.demon.nl> References: <42774699.40708@infrae.com> <6255E639-EDFA-4C12-96B0-6100D00BD60A@ulaluma.com> <4278C40F.8090104@infrae.com> <4279DB99.9020702@debris.demon.nl> Message-ID: Well, guys, I like SF.net. I understand that many of you don't. I'm okay with that. I'm willing to bite the bullet and set things up, if we can all come to concensus about what should be done. Should I just setup a Plone instance somewhere? Best Regards, -jj On 5/5/05, Johnny deBris wrote: > Martijn Faassen wrote: > > >I asked Infrae's resident Javascript guru (Guido Wesdorp), and he said > >he didn't know of such a advanced javascript forum. He had some > >discussions with other javascript hackers to set up such a thing, but > >they haven't done anything yet. > > > > > > > Let me explain a bit: > > The last two years (or so) I've been hacking quite a lot of JavaScript. > I wrote a large part of the Kupu application, as well as a number of > libraries, of which some still need to be released (a SAX and DOM lib, > although still pretty crude, can be downloaded from my website already, > some other libs, such as a WebDAV library and a full DAV client, will > follow later). > > Looking for patterns and base libraries, I have skimmed through quite a > few websites, but didn't find any 'real' open-source communities out > there, not even libraries or applications that have a larger set of > developers: most of what I found was either written by a company or were > one-person efforts. Also I didn't find a website where extensive > documentation can be found, or a place to meet other serious JS hackers > (apart from script-kiddies) or find proper open-source libs. > > I think, to be honest, that a discussion board would not be enough to > really be helpful. What I would like to see would be something like SF > meets Python.org, but then for JS only, a place for developers to meet, > team up, find base libs, start a project and maintain it, but also for > users to find proper libs, search a repository, find docs about advanced > JS topics and such. > > I've been discussing such an initiative with a couple of other JS > hackers, and they all seem interested, although obviously this will be a > lot of work to set up and maintain. Since we're all very busy people > (remember there's a lot to do for JS ;) we didn't actually get anything > going yet, but perhaps we should asap. Of course, a helping hand would > be greatly appreciated... > > Cheers, > > Guido > _______________________________________________ > Web-SIG mailing list > Web-SIG at python.org > Web SIG: http://www.python.org/sigs/web-sig > Unsubscribe: http://mail.python.org/mailman/options/web-sig/jjinux%40gmail.com > -- I have decided to switch to Gmail, but messages to my Yahoo account will still get through. From dp at ulaluma.com Thu May 5 22:22:43 2005 From: dp at ulaluma.com (Donovan Preston) Date: Thu, 5 May 2005 13:22:43 -0700 Subject: [Web-SIG] JavaScript libraries In-Reply-To: References: <42774699.40708@infrae.com> <6255E639-EDFA-4C12-96B0-6100D00BD60A@ulaluma.com> <4278C40F.8090104@infrae.com> <4279DB99.9020702@debris.demon.nl> Message-ID: On May 5, 2005, at 12:43 PM, Shannon -jj Behrens wrote: > Well, guys, I like SF.net. I understand that many of you don't. I'm > okay with that. I'm willing to bite the bullet and set things up, if > we can all come to concensus about what should be done. Should I just > setup a Plone instance somewhere? I'd still rather wait and look around for another community to latch on to. If we don't, then we have to go to the difficult trouble of inviting and successfully attracting developers from other, non- Python communities. I like Plone; is there some product which plugs into Plone and integrates mailman or some other mailing list manager? Donovan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/web-sig/attachments/20050505/90336bb2/attachment.htm From carribeiro at gmail.com Fri May 6 02:09:51 2005 From: carribeiro at gmail.com (Carlos Ribeiro) Date: Thu, 5 May 2005 21:09:51 -0300 Subject: [Web-SIG] JavaScript libraries In-Reply-To: References: <42774699.40708@infrae.com> <6255E639-EDFA-4C12-96B0-6100D00BD60A@ulaluma.com> <4278C40F.8090104@infrae.com> <4279DB99.9020702@debris.demon.nl> Message-ID: <864d37090505051709b581702@mail.gmail.com> Hi guys, Javascript seems to be everyone's little dirty secret. Everyone uses, most people don't like it. Some (like me) dislike it for no other reason than being another language that I have to use. Some others dislike it for being named Javasomething (which is indeed something very strange). Yet others dislike it because it's a hell of a language to work with, mainly because it breaks the usual development cycle... it's hard to debug, trace, or otherwise analyze because it runs inside the browser. Most of the times, Javascript can't stand on its own legs; it requires other 'real' languages, such as Python or Java (or even PHP!) for something to be done. To top it all, there's the DOM, incompatibilities, you name it. Once you understand that - Javascript may be tolerated, but (almost) never loved - it's easy to understand why there are so little movement in the OS camp involving Javascript libraries. I mean, the amount of quality & well documented JS libraries is ridiculous if compared to the relative importance of the language for the industry. The lack of real communities of developers is also telling. For all the reasons above, I can't see it changing anytime soon. Perhaps if we had better support in some browser -- and Firefox is the perfect candidate here -- to improve the development experience. So far, it's been a long trip into a U2-class sub with the lights turned off. -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: carribeiro at gmail.com mail: carribeiro at yahoo.com From mso at oz.net Fri May 6 06:53:40 2005 From: mso at oz.net (Mike Orr) Date: Thu, 05 May 2005 21:53:40 -0700 Subject: [Web-SIG] JavaScript libraries In-Reply-To: <864d37090505051709b581702@mail.gmail.com> References: <42774699.40708@infrae.com> <6255E639-EDFA-4C12-96B0-6100D00BD60A@ulaluma.com> <4278C40F.8090104@infrae.com> <4279DB99.9020702@debris.demon.nl> <864d37090505051709b581702@mail.gmail.com> Message-ID: <427AF854.8070508@oz.net> Carlos Ribeiro wrote: >Hi guys, > > >Javascript seems to be everyone's little dirty secret. Everyone uses, >most people don't like it. Some (like me) dislike it for no other >reason than being another language that I have to use. Some others >dislike it for being named Javasomething (which is indeed something >very strange). > It appeared during Java's intial wave of hype. Netscape named it that to ensure rapid acceptance of the language. In other words, by latching onto Java's coattails it avoided the need to prove itself on its own. Wikipedia talks a bit about its original name. http://en.wikipedia.org/wiki/Javascript From davidf at sjsoft.com Fri May 6 12:04:08 2005 From: davidf at sjsoft.com (David Fraser) Date: Fri, 06 May 2005 12:04:08 +0200 Subject: [Web-SIG] JavaScript libraries In-Reply-To: <6654eac405050217474cb95c1f@mail.gmail.com> References: <6654eac405050217474cb95c1f@mail.gmail.com> Message-ID: <427B4118.60300@sjsoft.com> Peter Hunt wrote: > 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? I think your original Python to Javascript compiler is way cool. The server-side RPC can be done in lots of ways, as has been discussed... I'm not sure why that's linked to the javascript to python converter though, although you could always incorporate server-side processing for methods you can't convert to javascript. I'm very keen to write scripts that actually need to be written in Python syntax rather than javascript, just because its nicer :-) David From whit537 at gmail.com Fri May 6 13:01:51 2005 From: whit537 at gmail.com (Chad Whitacre) Date: Fri, 6 May 2005 07:01:51 -0400 Subject: [Web-SIG] JavaScript libraries In-Reply-To: <864d37090505051709b581702@mail.gmail.com> References: <6255E639-EDFA-4C12-96B0-6100D00BD60A@ulaluma.com> <4278C40F.8090104@infrae.com> <4279DB99.9020702@debris.demon.nl> <864d37090505051709b581702@mail.gmail.com> Message-ID: > Perhaps if we had better support in some browser -- and Firefox is the > perfect candidate here -- to improve the development experience. Have you used Venkman? Venkman is Mozilla's javascript debugger. It runs OTB with the Mozilla suite but you need to do some gymnastics to get it to work with Firefox. http://www.mozilla.org/projects/venkman/ chad From steve at holdenweb.com Fri May 6 13:08:20 2005 From: steve at holdenweb.com (Steve Holden) Date: Fri, 06 May 2005 07:08:20 -0400 Subject: [Web-SIG] JavaScript libraries In-Reply-To: <427AF854.8070508@oz.net> References: <42774699.40708@infrae.com> <6255E639-EDFA-4C12-96B0-6100D00BD60A@ulaluma.com> <4278C40F.8090104@infrae.com> <4279DB99.9020702@debris.demon.nl> <864d37090505051709b581702@mail.gmail.com> <427AF854.8070508@oz.net> Message-ID: <427B5024.4090306@holdenweb.com> Mike Orr wrote: > Carlos Ribeiro wrote: > > >>Hi guys, >> >> >>Javascript seems to be everyone's little dirty secret. Everyone uses, >>most people don't like it. Some (like me) dislike it for no other >>reason than being another language that I have to use. Some others >>dislike it for being named Javasomething (which is indeed something >>very strange). >> > > > It appeared during Java's intial wave of hype. Netscape named it that > to ensure rapid acceptance of the language. In other words, by latching > onto Java's coattails it avoided the need to prove itself on its own. > Except that it didn't, of course. My own belief is that Javascript, like Perl, has suffered from the web-s 1990's "programming with a trowel" metaphor, because a bunch of clueless dweebs dsicovered they could often get 85% of a web job done by lifting chunks of code from the Internet and dropping them into web pages. The fact that they then often had no clue how to provide the other 15% of the required fuctionality led to many oddities and much "trial-and-error" programming that was inevitably a nightmare to maintain. There used to be a terrific Javascript debugging environment in Mozilla, but since I moved to Firefox I don't see the same thing (as I haven't recently been doing much JS). It didn't help with the cross-browser issues, though, and those could be a nightmare. When two DOMs colide the victim is surely the lowly Java script programmer. The language itself is remarkably clean when you look at it in the abstract. done-my-own-ton-of-javascript-ly y'rs - steve -- Steve Holden +1 703 861 4237 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ Python Web Programming http://pydish.holdenweb.com/ From whit537 at gmail.com Fri May 6 13:35:15 2005 From: whit537 at gmail.com (Chad Whitacre) Date: Fri, 6 May 2005 07:35:15 -0400 Subject: [Web-SIG] JavaScript libraries In-Reply-To: <427B51AD.3090804@holdenweb.com> References: <6255E639-EDFA-4C12-96B0-6100D00BD60A@ulaluma.com> <4278C40F.8090104@infrae.com> <4279DB99.9020702@debris.demon.nl> <864d37090505051709b581702@mail.gmail.com> <427B51AD.3090804@holdenweb.com> Message-ID: >> Have you used Venkman? Venkman is Mozilla's javascript debugger. It >> runs OTB with the Mozilla suite but you need to do some gymnastics to >> get it to work with Firefox. >> >> http://www.mozilla.org/projects/venkman/ >> > Sorry, no time for gymnastics :-) Actually, I said the same thing until just now. It turns out it's pretty easy. The issue is that the Venkman extension doesn't install anywhere in the Firefox UI, so you have to launch it explicitly. Here's the steps I took to get it to work: 1. Install the extension: http://extensionroom.mozdev.org/more-info/venkman 2. Shutdown Firefox. 3. From the command line, launch Firefox with the -venkman option. I don't think this is too onerous. I now have a shortcut that launches Venkman and it just feels like a stand-alone app instead of a FF extension. Now we just need an icon for it. :^) HTH chad From faassen at infrae.com Fri May 6 14:22:07 2005 From: faassen at infrae.com (Martijn Faassen) Date: Fri, 06 May 2005 14:22:07 +0200 Subject: [Web-SIG] JavaScript libraries In-Reply-To: References: <42774699.40708@infrae.com> <6255E639-EDFA-4C12-96B0-6100D00BD60A@ulaluma.com> <4278C40F.8090104@infrae.com> <4279DB99.9020702@debris.demon.nl> Message-ID: <427B616F.5080602@infrae.com> Donovan Preston wrote: > > On May 5, 2005, at 12:43 PM, Shannon -jj Behrens wrote: > >> Well, guys, I like SF.net. I understand that many of you don't. I'm >> okay with that. I'm willing to bite the bullet and set things up, if >> we can all come to concensus about what should be done. Should I just >> setup a Plone instance somewhere? [snip] > I like Plone; is there some product which plugs into Plone and > integrates mailman or some other mailing list manager? Why Plone? What's the point of using Plone if we simply want a mailing list? Regards, Martijn From carribeiro at gmail.com Fri May 6 15:21:22 2005 From: carribeiro at gmail.com (Carlos Ribeiro) Date: Fri, 6 May 2005 10:21:22 -0300 Subject: [Web-SIG] JavaScript libraries In-Reply-To: <427B616F.5080602@infrae.com> References: <6255E639-EDFA-4C12-96B0-6100D00BD60A@ulaluma.com> <4278C40F.8090104@infrae.com> <4279DB99.9020702@debris.demon.nl> <427B616F.5080602@infrae.com> Message-ID: <864d370905050606212d9ebd16@mail.gmail.com> On 5/6/05, Martijn Faassen wrote: > Donovan Preston wrote: > > > > On May 5, 2005, at 12:43 PM, Shannon -jj Behrens wrote: > > > >> Well, guys, I like SF.net. I understand that many of you don't. I'm > >> okay with that. I'm willing to bite the bullet and set things up, if > >> we can all come to concensus about what should be done. Should I just > >> setup a Plone instance somewhere? > > [snip] > > > I like Plone; is there some product which plugs into Plone and > > integrates mailman or some other mailing list manager? > > Why Plone? What's the point of using Plone if we simply want a mailing list? > When all that you have is a hammer, everything looks like a nail :-) On a more serious tone, the idea itself has some merit. However, Plone carries a lot of overhead. I would rather prefer a lightweight framework for such 'plug ins'. I wondered a long time about doing some work with CherryPy along these lines, but I never had the time to make it. I just hope to be able to make it now that I found some free time for my hacking. Things should be simpler IMHO... -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: carribeiro at gmail.com mail: carribeiro at yahoo.com From todd at slack.net Fri May 6 16:49:52 2005 From: todd at slack.net (Todd Grimason) Date: Fri, 6 May 2005 10:49:52 -0400 Subject: [Web-SIG] JavaScript libraries In-Reply-To: <427B5024.4090306@holdenweb.com> References: <6255E639-EDFA-4C12-96B0-6100D00BD60A@ulaluma.com> <4278C40F.8090104@infrae.com> <4279DB99.9020702@debris.demon.nl> <864d37090505051709b581702@mail.gmail.com> <427AF854.8070508@oz.net> <427B5024.4090306@holdenweb.com> Message-ID: <20050506144952.GA15832@detroit.slack.net> * Steve Holden [2005-05-06 07:08]: > Except that it didn't, of course. My own belief is that Javascript, like > Perl, has suffered from the web-s 1990's "programming with a trowel" > metaphor, because a bunch of clueless dweebs dsicovered they could often > get 85% of a web job done by lifting chunks of code from the Internet > and dropping them into web pages. > > The fact that they then often had no clue how to provide the other 15% > of the required fuctionality led to many oddities and much > "trial-and-error" programming that was inevitably a nightmare to maintain. > Well yeah, but most people didn't want to hire a developer for $95K to write their javascript rollovers. Though I'm sure many did. And so much javascript at the time was endless if/else statements handling the horrid mess that was[is] browser support and bugs. It's improved, or at least to the extent that many people get to ignore older, buggier browsers. I don't think most 'real' developers were overly eager to spend all their time writing javascript at the time either... and we could also touch on all the horrific interfaces and design by developers who are clueless dweebs when it comes to that ;-) -- ______________________________ toddgrimason*todd-AT-slack.net From jjinux at gmail.com Fri May 6 18:14:15 2005 From: jjinux at gmail.com (Shannon -jj Behrens) Date: Fri, 6 May 2005 09:14:15 -0700 Subject: [Web-SIG] JavaScript libraries In-Reply-To: <427B616F.5080602@infrae.com> References: <6255E639-EDFA-4C12-96B0-6100D00BD60A@ulaluma.com> <4278C40F.8090104@infrae.com> <4279DB99.9020702@debris.demon.nl> <427B616F.5080602@infrae.com> Message-ID: > Why Plone? What's the point of using Plone if we simply want a mailing list? I was thinking a lot more would be involved than just a mailing list. If all we want is a mailing list, those are easy to get. I was thinking we'd have a Web site with FAQ's, documentation, etc., and maybe even some code. As much as I can easily develop this in Aquarium, Aquarium isn't meant to be an out of the box content management system, whereas Plone is. Best Regards, -jj -- I have decided to switch to Gmail, but messages to my Yahoo account will still get through. From jjinux at gmail.com Fri May 6 18:18:27 2005 From: jjinux at gmail.com (Shannon -jj Behrens) Date: Fri, 6 May 2005 09:18:27 -0700 Subject: [Web-SIG] JavaScript libraries In-Reply-To: <864d370905050606212d9ebd16@mail.gmail.com> References: <6255E639-EDFA-4C12-96B0-6100D00BD60A@ulaluma.com> <4278C40F.8090104@infrae.com> <4279DB99.9020702@debris.demon.nl> <427B616F.5080602@infrae.com> <864d370905050606212d9ebd16@mail.gmail.com> Message-ID: > On a more serious tone, the idea itself has some merit. However, Plone > carries a lot of overhead. I would rather prefer a lightweight > framework for such 'plug ins'. I wondered a long time about doing some > work with CherryPy along these lines, but I never had the time to make > it. I just hope to be able to make it now that I found some free time > for my hacking. Things should be simpler IMHO... (humor) Python Web application framework developers can't agree on a common set of code. Hence, they move on to trying to talk about sharing JavaScript techniques. However, they can't agree on how to do that either, because they can't figure out what to write the Web site in! Perhaps we should pass on reinventing that wheel, even if we're all capable of doing it ;) Best Regards, -jj -- I have decided to switch to Gmail, but messages to my Yahoo account will still get through. From mso at oz.net Fri May 6 20:54:20 2005 From: mso at oz.net (Mike Orr) Date: Fri, 06 May 2005 11:54:20 -0700 Subject: [Web-SIG] JavaScript libraries In-Reply-To: References: <6255E639-EDFA-4C12-96B0-6100D00BD60A@ulaluma.com> <4278C40F.8090104@infrae.com> <4279DB99.9020702@debris.demon.nl> <427B616F.5080602@infrae.com> <864d370905050606212d9ebd16@mail.gmail.com> Message-ID: <427BBD5C.3090304@oz.net> Shannon -jj Behrens wrote: >>On a more serious tone, the idea itself has some merit. However, Plone >>carries a lot of overhead. I would rather prefer a lightweight >>framework for such 'plug ins'. I wondered a long time about doing some >>work with CherryPy along these lines, but I never had the time to make >>it. I just hope to be able to make it now that I found some free time >>for my hacking. Things should be simpler IMHO... >> >> > >(humor) >Python Web application framework developers can't agree on a common >set of code. Hence, they move on to trying to talk about sharing >JavaScript techniques. However, they can't agree on how to do that >either, because they can't figure out what to write the Web site in! > > ... but somehow python.org is functioning in spite of this. :) From ianb at colorstudy.com Sat May 7 00:18:46 2005 From: ianb at colorstudy.com (Ian Bicking) Date: Fri, 06 May 2005 17:18:46 -0500 Subject: [Web-SIG] JavaScript libraries In-Reply-To: <427BBD5C.3090304@oz.net> References: <6255E639-EDFA-4C12-96B0-6100D00BD60A@ulaluma.com> <4278C40F.8090104@infrae.com> <4279DB99.9020702@debris.demon.nl> <427B616F.5080602@infrae.com> <864d370905050606212d9ebd16@mail.gmail.com> <427BBD5C.3090304@oz.net> Message-ID: <427BED46.1000106@colorstudy.com> On the topic of Javascript, I just thought I'd note the existance of WHAT-WG (http://whatwg.org/) the Web Application Spec (http://whatwg.org/specs/web-apps/current-work/), and the Web Form spec (http://whatwg.org/specs/web-forms/current-work/), which both deal with Javascript. The Web App spec is meant to be implemented in Javascript for backward compatibility (with native browser support coming later), but also specifies a lot of Javascript methods that should be available for rich interfaces. So in a lot of ways it's similar to what we've been talking about. Well, I'm a little unclear about the specifics -- the demos use server-side scripts for legacy support, which isn't very feasible IMHO, those server-side components are written as filters and thus are web-programming-environment neutral. But I don't think that's what they intend ultimately...? Hmm... too bad they don't have a web-forms-implementors mailing list or something. -- Ian Bicking / ianb at colorstudy.com / http://blog.ianbicking.org From faassen at infrae.com Mon May 9 14:27:11 2005 From: faassen at infrae.com (Martijn Faassen) Date: Mon, 09 May 2005 14:27:11 +0200 Subject: [Web-SIG] JavaScript libraries In-Reply-To: References: <6255E639-EDFA-4C12-96B0-6100D00BD60A@ulaluma.com> <4278C40F.8090104@infrae.com> <4279DB99.9020702@debris.demon.nl> <427B616F.5080602@infrae.com> Message-ID: <427F571F.90105@infrae.com> Shannon -jj Behrens wrote: >>Why Plone? What's the point of using Plone if we simply want a mailing list? > > I was thinking a lot more would be involved than just a mailing list. > If all we want is a mailing list, those are easy to get. I was > thinking we'd have a Web site with FAQ's, documentation, etc., and > maybe even some code. As much as I can easily develop this in > Aquarium, Aquarium isn't meant to be an out of the box content > management system, whereas Plone is. I just thought a few simple HTML pages would be enough to start with. I mean, Infrae makes Silva, a CMS, and also does Plone and CPS work, so I'm not against CMSes Installing a CMS can distract massively; we already saw questions on how to integrate Plone with a mailing list the minute Plone was proposed. Regards, Martijn From cmlenz at gmx.de Tue May 10 11:21:20 2005 From: cmlenz at gmx.de (Christopher Lenz) Date: Tue, 10 May 2005 11:21:20 +0200 Subject: [Web-SIG] JavaScript libraries In-Reply-To: <4276DDDC.2080901@colorstudy.com> References: <42767070.7040500@colorstudy.com> <200505022035.52098.paul@boddie.org.uk> <5978.66.192.34.8.1115060330.squirrel@66.192.34.8> <4276DDDC.2080901@colorstudy.com> Message-ID: <9BCA2C4B-D777-42DA-B733-D8BD73B4CB8D@gmx.de> Am 03.05.2005 um 04:11 schrieb Ian Bicking: > The Javascript development community is young in other ways. Public > repositories and basic open source project management practices are > uncommon. We're still getting over a stage where everything is > presented as recipes instead of working code; I think that's widely > recognized, but it doesn't mean that there are a lot of good patterns > for how to do that. And the prototype stuff makes it hard for OO > programmers to get their bearings. Personally, I think that the recipe/cookbook style still works best for JavaScript. Unlike other so-called "scripting" languages like Python or Ruby, which have long grown to be powerful general purpose languages, JavaScript really is a language for scripting objects provided by the environment (in the case of web-development, the browser). Putting together a whole library or application is actually discouraged by the properties and restrictions of the language: no importing of external modules, no proper namespacing, etc. You really have to go out of your way to create a reusable, modular library, and it's still going to be a mess. And because JavaScript code runs in the browser, relying on a library means that the user will have to wait until that library has downloaded, even though your application is likely only using a fraction of the functionality provided by it. As a simple example, assume you want to reuse a library so that you can get all elements from the DOM that have a certain tag/class combination. You decide to just use Simon Willison's `getElementBySelector` function . Note though that that code is at least three times as large as it'd need to be for your use case, because it also supports CSS2 and CSS3 attribute selectors and what not. For local applications, code size is not much of a problem these days, but for web applications, it's a very serious constraint. > Little things have left me feeling unsure. Just to give one example, > how should I "activate" a library? Should it run onload automatically > and search the page for activating elements? I guess that's kind > of the > "unobtrusive" technique, but it often seems rather wasteful. > Should it > be activated by a function call? How are options passed in (and later > managed)? Should it involve a prototype for storing options, then > methods for attaching the object to elements on the page? Hell, I > still > don't understand prototypes in Javascript at all. It's this stuff > where > I get confused, and so I'm actually looking for more than a Javascript > library to smooth out a few rough edges -- I want a model for good > Javascript development that I can learn from. Well, one exceptionally well-done JavaScript library that I haven't seen mention of on this thread is "prototype" (yeah, RoR again). I think it should go a far way towards "smoothing out the rough edgews": http://prototype.conio.net/ http://dev.rubyonrails.com/file/trunk/railties/html/javascripts/ prototype.js Cheers, Chris -- Christopher Lenz cmlenz at gmx.de http://www.cmlenz.net/ From carribeiro at gmail.com Tue May 10 12:59:28 2005 From: carribeiro at gmail.com (Carlos Ribeiro) Date: Tue, 10 May 2005 07:59:28 -0300 Subject: [Web-SIG] JavaScript libraries In-Reply-To: <9BCA2C4B-D777-42DA-B733-D8BD73B4CB8D@gmx.de> References: <42767070.7040500@colorstudy.com> <200505022035.52098.paul@boddie.org.uk> <5978.66.192.34.8.1115060330.squirrel@66.192.34.8> <4276DDDC.2080901@colorstudy.com> <9BCA2C4B-D777-42DA-B733-D8BD73B4CB8D@gmx.de> Message-ID: <864d370905051003593489fd11@mail.gmail.com> On 5/10/05, Christopher Lenz wrote: > Personally, I think that the recipe/cookbook style still works best > for JavaScript. Unlike other so-called "scripting" languages like > Python or Ruby, which have long grown to be powerful general purpose > languages, JavaScript really is a language for scripting objects > provided by the environment (in the case of web-development, the > browser). Putting together a whole library or application is actually > discouraged by the properties and restrictions of the language: no > importing of external modules, no proper namespacing, etc. You really > have to go out of your way to create a reusable, modular library, and > it's still going to be a mess. My own approach to it is slightly different. Instead of a big 'standard library', I use a home-baked templating system to generate custom Javascript code. My library is very small and contains only often-used routines (mostly, JSON & IFrame-based RPC code). The Python code generates custom Javascript event handlers, which tend to be small too. The main disadvantage is that it can't rely on caching the library on the client, but that's not a big deal most of the times IMHO. -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: carribeiro at gmail.com mail: carribeiro at yahoo.com From ianb at colorstudy.com Tue May 10 18:14:44 2005 From: ianb at colorstudy.com (Ian Bicking) Date: Tue, 10 May 2005 11:14:44 -0500 Subject: [Web-SIG] JavaScript libraries In-Reply-To: <9BCA2C4B-D777-42DA-B733-D8BD73B4CB8D@gmx.de> References: <42767070.7040500@colorstudy.com> <200505022035.52098.paul@boddie.org.uk> <5978.66.192.34.8.1115060330.squirrel@66.192.34.8> <4276DDDC.2080901@colorstudy.com> <9BCA2C4B-D777-42DA-B733-D8BD73B4CB8D@gmx.de> Message-ID: <4280DDF4.7060902@colorstudy.com> Christopher Lenz wrote: > Am 03.05.2005 um 04:11 schrieb Ian Bicking: > >> The Javascript development community is young in other ways. Public >> repositories and basic open source project management practices are >> uncommon. We're still getting over a stage where everything is >> presented as recipes instead of working code; I think that's widely >> recognized, but it doesn't mean that there are a lot of good patterns >> for how to do that. And the prototype stuff makes it hard for OO >> programmers to get their bearings. > > > Personally, I think that the recipe/cookbook style still works best for > JavaScript. Unlike other so-called "scripting" languages like Python or > Ruby, which have long grown to be powerful general purpose languages, > JavaScript really is a language for scripting objects provided by the > environment (in the case of web-development, the browser). Putting > together a whole library or application is actually discouraged by the > properties and restrictions of the language: no importing of external > modules, no proper namespacing, etc. You really have to go out of your > way to create a reusable, modular library, and it's still going to be a > mess. Maybe people are reading more into this than what I personally want. For instance, I've found this code very useful for table display: http://www.kryogenix.org/code/browser/sorttable/ Way easier to implement than server-side table sorting, and a better UI to boot. But it has some problems; it's not as extensible as I'd like, and I'd like to include support for zebra tables (http://www.alistapart.com/articles/zebratables/) since they go together well. And I'd like them to use something like this to avoid memory leaks: http://novemberborn.net/javascript/event-cache It's not a big project, nor necessarily a big library. There are some key pieces that many systems share (like perhaps event cache, a couple backward-compatibility fixes like adding Array.push, some functions for manipulating CSS classes), and then there's optional stuff built on that. There are several issues these libraries have to deal with, many of which I don't know much about, and might be widely missed in simple recipe-based Javascript. Like the memory leak issue. Performance issues come in there too, one of those refinements that requires some intuition and will never happen until a bit of code reaches some maturity. I'm not talking frameworks for rich client-side development, just incremental bits of code that are robust, documented, and use a consistent set of reliable patterns. > And because JavaScript code runs in the browser, relying on a library > means that the user will have to wait until that library has > downloaded, even though your application is likely only using a > fraction of the functionality provided by it. Personally this doesn't matter much to me. I'd rather put more effort into identifying a minimal core and including just the needed libraries, and in applying things like gzip or even source compression to the code (with a link back to the original code, of course -- at least that would be required by the LGPL, which makes me inclined in that direction for Javascript licensing). Javascript is cacheable and reusable; it's no bigger than a large logo. > As a simple example, assume you want to reuse a library so that you can > get all elements from the DOM that have a certain tag/class > combination. You decide to just use Simon Willison's > `getElementBySelector` function getElementsBySelector.js>. Note though that that code is at least three > times as large as it'd need to be for your use case, because it also > supports CSS2 and CSS3 attribute selectors and what not. >>> import urllib >>> c = urllib.urlopen('http://simon.incutio.com/js/getElementsBySelector.js').read() >>> len(c) 6292 >>> len(c.encode('zlib')) 1794 1.8K isn't so bad. I put it through http://www.creativyst.com/Prod/3/ and get 4560 bytes, 1275 bytes compressed. > Well, one exceptionally well-done JavaScript library that I haven't > seen mention of on this thread is "prototype" (yeah, RoR again). I > think it should go a far way towards "smoothing out the rough edgews": > > http://prototype.conio.net/ > http://dev.rubyonrails.com/file/trunk/railties/html/javascripts/ > prototype.js Last time I looked at it, it didn't have its own site, and the docs were all very Rails-specific. Now that I look at the code it's pretty comprehensable on its own, and they seem to be moving it towards being its own package, so that does make it more interesting. There's some clever code (in a good way) in there too, like: var Try = { these: function() { var returnValue; for (var i = 0; i < arguments.length; i++) { var lambda = arguments[i]; try { returnValue = lambda(); break; } catch (e) {} } return returnValue; } } var Ajax = { getTransport: function() { return Try.these( function() {return new ActiveXObject('Msxml2.XMLHTTP')}, function() {return new ActiveXObject('Microsoft.XMLHTTP')}, function() {return new XMLHttpRequest()} ) || false; }, emptyFunction: function() {} } That's a kind of pattern I see over and over again in Javascript, doing funny little things to test the functionality of the client, and it's nice to see a robust pattern to handle that common case. -- Ian Bicking / ianb at colorstudy.com / http://blog.ianbicking.org From johnny at debris.demon.nl Tue May 10 20:47:13 2005 From: johnny at debris.demon.nl (Johnny deBris) Date: Tue, 10 May 2005 20:47:13 +0200 Subject: [Web-SIG] JavaScript libraries In-Reply-To: <864d370905051003593489fd11@mail.gmail.com> References: <42767070.7040500@colorstudy.com> <200505022035.52098.paul@boddie.org.uk> <5978.66.192.34.8.1115060330.squirrel@66.192.34.8> <4276DDDC.2080901@colorstudy.com> <9BCA2C4B-D777-42DA-B733-D8BD73B4CB8D@gmx.de> <864d370905051003593489fd11@mail.gmail.com> Message-ID: <428101B1.8070005@debris.demon.nl> Carlos Ribeiro wrote: >On 5/10/05, Christopher Lenz wrote: > > >>Putting together a whole library or application is actually >>discouraged by the properties and restrictions of the language: no >>importing of external modules, no proper namespacing, etc. You really >>have to go out of your way to create a reusable, modular library, and >>it's still going to be a mess. >> >> > > > You're right about the first part, I hope to prove you wrong on the latter. See http://debris.demon.nl:7080/projects (or http://debris.demon.nl:7080/cgi-bin/viewcvs.cgi) for some JS libs (there's also some Python in there) which I'm working on, including XML SAX and DOM libraries (the latter because IE's DOM support sucks), a WebDAV library, a reusable tree implementation (which can be used in async situations too), and some more. Those will all (at some point, I don't have much time) be released with open source licenses at some point (some BSD-style, some GPL), and, if it turns out people are interested, I will set up mailinglists and allow people to join me developing them further. >I use a home-baked templating system to generate >custom Javascript code. > I wonder why everyone seems to insist on generating JS server-side (or at least generating it). It's a perfectly usable language (although I really miss some of Python's more advanced features, and JS can be pretty inconsistent at times) and code generation frameworks (in my experience) usually don't allow you to be as flexible as when you'd just write the code... Are people really that revolted by the language, or is it just that Python is so much nicer? (Obviously Python *is* way nicer, but otoh, having hacked quite a lot of JS over the last 1.5 years (way over 10000 lines) I think it's not all that bad...) Cheers, Guido > My library is very small and contains only >often-used routines (mostly, JSON & IFrame-based RPC code). The Python >code generates custom Javascript event handlers, which tend to be >small too. The main disadvantage is that it can't rely on caching the >library on the client, but that's not a big deal most of the times >IMHO. > > > From sanxiyn at gmail.com Mon May 16 12:55:02 2005 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Mon, 16 May 2005 19:55:02 +0900 Subject: [Web-SIG] Beyond JS Message-ID: <5b0248170505160355706edc08@mail.gmail.com> Have anyone mentioned Beoynd JS already? http://w3future.com/html/beyondJS/ Seo Sanghyeon From ianb at colorstudy.com Wed May 18 04:42:57 2005 From: ianb at colorstudy.com (Ian Bicking) Date: Tue, 17 May 2005 21:42:57 -0500 Subject: [Web-SIG] Static WSGI file application Message-ID: <428AABB1.5070308@colorstudy.com> Has anyone written a WSGI application for serving static files, that does stuff like If-Modified-Since, ETags, etc? I was planning to write one, but maybe someone else has already done it. I also want support for things like caching gzip versions of the file, caching the etag, and enough hooks to use it as a backend to a caching middleware, but I wonder if anyone's started on anything in that direction. -- Ian Bicking / ianb at colorstudy.com / http://blog.ianbicking.org From pje at telecommunity.com Wed May 18 18:01:08 2005 From: pje at telecommunity.com (Phillip J. Eby) Date: Wed, 18 May 2005 12:01:08 -0400 Subject: [Web-SIG] WSGI reason phrase optionality In-Reply-To: <428B5E3E.7040706@colorstudy.com> References: <2AC9B6B2-8A12-45C6-9FB5-20E329079776@saddi.com> <2AC9B6B2-8A12-45C6-9FB5-20E329079776@saddi.com> Message-ID: <5.1.1.6.0.20050518115451.01ee95d0@mail.telecommunity.com> These references should clear up the confusion; the space is explicitly required by both PEP 333 and by the HTTP specification: http://www.python.org/peps/pep-0333.html#the-start-response-callable http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html#sec6.1 With respect to vagueness in the PEP, I didn't say that the reason phrase could be empty, although I did cite the above RFC, which shows that Reason-Phrase is zero or more text characters. However the PEP is absolutely unambiguous that the space must be present. At 10:24 AM 5/18/2005 -0500, Ian Bicking wrote: >Copying PJE... >Allan Saddi wrote: >>Hi Ian, >>I just saw your comment on the CherryPy ticket I opened about the >>optionality of the reason phrase in the first argument to >>start_response(). PEP 333 is a bit vague on the matter, but after >>looking at Phillip Eby's wsgiref, I do believe you're right. However, >>there's a slight twist. Philip's reference start_response() makes the >>following checks: >> assert type(status) is StringType,"Status must be a string" >> assert len(status)>=4,"Status must be at least 4 characters" >> assert int(status[:3]),"Status message must begin w/3-digit code" >> assert status[3]==" ", "Status message must have a space after >> code" >>In other words, the reason phrase may be empty, but there must always >>be a space after the status code. This interpretation is a tiny bit >>stricter than what Paste's lint currently allows. (I don't remember >>now, but I think I did run lint in between CherryPy and one of my >>servers. Since my servers also do the above checks, I got a lot of >>assertion failures because CherryPy often only passed a 3-digit string.) >>Anyhow, should lint be changed to match? Is this even the correct >>interpretation? I currently have no idea. :) > >I've never written any code that expects anything after the status code, >and I think it would be odd to do so. I always write >int(status.split(None, 1)[0]), which is a little annoying but a reasonable >pattern. I think it would also be valid to test that it was three >characters. Otherwise I think Phillip's code is more restrictive than >necessary, though maybe lint could have multiple levels and emit a warning >in this case. From fumanchu at amor.org Wed May 18 18:40:23 2005 From: fumanchu at amor.org (Robert Brewer) Date: Wed, 18 May 2005 09:40:23 -0700 Subject: [Web-SIG] WSGI mod_python wrapper Message-ID: <3A81C87DC164034AA4E2DDFE11D258E37720EB@exchange.hqamor.amorhq.net> After much poring through many specs, I've got a WSGI wrapper for mod_python that I'm fairly comfortable with. I'm sure PJE will find 16 holes in it right away ;) but it fixes some of the problems in the rough draft I posted here last October. http://www.amorhq.net/blogs/index.php/fumanchu/2005/05/17/wsgi_wrapper_f or_mod_python ASP is next. :) Robert Brewer System Architect Amor Ministries fumanchu at amor.org From pje at telecommunity.com Wed May 18 19:02:44 2005 From: pje at telecommunity.com (Phillip J. Eby) Date: Wed, 18 May 2005 13:02:44 -0400 Subject: [Web-SIG] WSGI mod_python wrapper In-Reply-To: <3A81C87DC164034AA4E2DDFE11D258E37720EB@exchange.hqamor.amo rhq.net> Message-ID: <5.1.1.6.0.20050518125710.01eeb1e0@mail.telecommunity.com> At 09:40 AM 5/18/2005 -0700, Robert Brewer wrote: >After much poring through many specs, I've got a WSGI wrapper for >mod_python that I'm fairly comfortable with. I'm sure PJE will find 16 >holes in it right away ;) Nope; not a one that I can see. Although I'm curious about your choice in send_headers() to include the content type and length headers in the headers_out. I had noticed that other variants of this implementation just called the set_content_X() methods and skipped adding the header. But I don't know enough about mod_python to have a clue which way is correct, or if it even matters. I'd be happy to include this in wsgiref, assuming you're willing to license it as "PSF or ZPL" as is done for the rest of wsgiref. I'd prefer to call the module 'wsgiref.modpython_gateway', though. From fumanchu at amor.org Wed May 18 19:43:36 2005 From: fumanchu at amor.org (Robert Brewer) Date: Wed, 18 May 2005 10:43:36 -0700 Subject: [Web-SIG] WSGI mod_python wrapper Message-ID: <3A81C87DC164034AA4E2DDFE11D258E37720F6@exchange.hqamor.amorhq.net> Phillip J. Eby wrote: > At 09:40 AM 5/18/2005 -0700, Robert Brewer wrote: > > After much poring through many specs, I've got a WSGI wrapper for > > mod_python that I'm fairly comfortable with. I'm sure PJE > > will find 16 holes in it right away ;) > > Nope; not a one that I can see. Although I'm curious about > your choice in send_headers() to include the content type > and length headers in the headers_out. I had noticed that > other variants of this implementation just called the > set_content_X() methods and skipped adding the header. > But I don't know enough about mod_python to have a clue > which way is correct, or if it even matters. I wasn't sure either. The mod_python docs say set_content_length() sets the header for you. I figured the overkill was worth the extra cycles. Apache's ap_set_content_type() function has this in a comment: "This function must be called to set r->content_type in order for the AddOutputFilterByType directive to work correctly." -- so it at least has a separate purpose. I don't think I'll change it unless someone shows the duplication is harmful. > I'd be happy to include this in wsgiref, assuming you're > willing to license it as "PSF or ZPL" as is done for the > rest of wsgiref. PSF is fine, but I don't see any license terms in my CVS copy of wsgiref. How shall I declare or include that? > I'd prefer to call the module 'wsgiref.modpython_gateway', though. Fine by me. Robert Brewer System Architect Amor Ministries fumanchu at amor.org From grisha at modpython.org Thu May 19 06:17:02 2005 From: grisha at modpython.org (Gregory (Grisha) Trubetskoy) Date: Thu, 19 May 2005 00:17:02 -0400 (EDT) Subject: [Web-SIG] WSGI mod_python wrapper In-Reply-To: <3A81C87DC164034AA4E2DDFE11D258E37720F6@exchange.hqamor.amorhq.net> References: <3A81C87DC164034AA4E2DDFE11D258E37720F6@exchange.hqamor.amorhq.net> Message-ID: <20050519001451.L30490@grisha.dyndns.org> On Wed, 18 May 2005, Robert Brewer wrote: > I wasn't sure either. The mod_python docs say set_content_length() sets > the header for you. I just happened to be reading this passingly - I don't know what the code in question looks like, but IIRC, by setting content-length you disable chunked encoding, which does not use content-length. Grisha From fumanchu at amor.org Thu May 19 06:37:13 2005 From: fumanchu at amor.org (Robert Brewer) Date: Wed, 18 May 2005 21:37:13 -0700 Subject: [Web-SIG] WSGI mod_python wrapper Message-ID: <3A81C87DC164034AA4E2DDFE11D258E377213E@exchange.hqamor.amorhq.net> Gregory (Grisha) Trubetskoy wrote: > On Wed, 18 May 2005, Robert Brewer wrote: > > > I wasn't sure either. The mod_python docs say > > set_content_length() sets the header for you. > > I just happened to be reading this passingly - I don't know > what the code in question looks like, but IIRC, by setting > content-length you disable chunked encoding, which does not > use content-length. Right. Fortunately the code doesn't try to call set_content_length unless that header is already set by the application. So we're safe *from ourselves* on that count at least. ;) Robert Brewer System Architect Amor Ministries fumanchu at amor.org From ianb at colorstudy.com Thu May 26 05:04:34 2005 From: ianb at colorstudy.com (Ian Bicking) Date: Wed, 25 May 2005 22:04:34 -0500 Subject: [Web-SIG] WSGI key conventions Message-ID: <42953CC2.2050509@colorstudy.com> There's a couple conventions I'd like to suggest, related to URLs. The first is because some adapters (like mod_scgi) do not set PATH_INFO. I presume this is because, while you typically set the handler for a specific Location, it only knows that it handles the complete URL. So when you have: SetHandler scgi-handler The SCGI handler doesn't know that it's only in /app, and that it should set SCRIPT_NAME to /app. Though, I believe mod_webkit *does* do this, so maybe it's possible to fix this in mod_scgi. (However, mod_webkit gets really funky when you use it in , which maybe is related.) FastCGI gets this right too, I think. But HTTP proxies don't. But you can't add variables to HTTP proxies, though you can add headers, but that would be something like HTTP_SCRIPT_NAME...? Anyway, while this can be configured on the Python side, it would be best to keep this together in the Apache configuration (or at least there should be the option). A simple way is to set an environmental variable, like: SetEnv WSGI_SCRIPT_NAME "/app" SetHandler scgi-handler (I haven't checked the Apache reference, so excuse any misspellings here) It would be nice if this was a convention, so that if no explicit configuration of SCRIPT_NAME is done on the Python side that WSGI applications should pick this up (particularly when they are connecting to something that is known to not resolve SCRIPT_NAME and PATH_INFO properly, and PATH_INFO is missing from the environmental dictionary.) One other convention that I'd like is for extra variables that are parsed out of the request. For instance, lets say you have domain names like username.application.com (using a wildcard *.application.com DNS entry). The WSGI application that parses this might look like: def parse_username_middleware(app): def replacement(environ, start_response): host = environ['HTTP_HOST'] environ.setdefault('url.vars', {})['username'] = host.split('.')[0] return app(environ, start_response) return replacement The idea of making 'url.vars' a convention is that different frameworks could give access to this specific set of variables (which could be derived from the path, hostname, or other data in the environment). Some might simply put it in a big pool of variables (GET, POST, Cookie), while others might give access to it separately. But anyway, I've come upon this several times with URL-parsing middleware, and I keep just stuffing it in random locations, so a convention would be nice. -- Ian Bicking / ianb at colorstudy.com / http://blog.ianbicking.org