[Web-SIG] Morepath 0.5.1 released
Hi there, I thought I'd also send an announcement about Morepath to the Python web sig. Morepath is a Python web framework geared for creating modern rich-client web applications. It uses routing to model which allows for easy link generation and greater code reuse. It also has features for inheriting and composing applications. Morepath is a micro-framework in that it's not a lot of lines of code, but it packs a lot of power in a small package. http://blog.startifact.com/posts/morepath-051-and-friends-released.html Morepath is extensively documented, here: http://morepath.readthedocs.org Regards, Martijn ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: https://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
[Web-SIG] hurry.resource
Hi there,
I thought this might be a nice place to bring hurry.resource to the
attention of more people.
hurry.resource is a way to package Javascript (and CSS) libraries as
Python libraries. It can be compared with client-side javascript-based
resource handling libraries such as the YUI loader. hurry.resource is
server-based however. hurry.resource is designed to be web-framework
agnostic. I've recently released version 0.9 which includes a simple
WSGI middleware that can help to integrate this into your application or
framework.
What can you do with hurry.resource? We've wrapped a whole selection of
Javascript libraries using hurry.resource, such as YUI (hurry.yui),
jquery (hurry.jquery), jquery-ui (hurry.jquery-ui), ExtJS (hurry.extjs),
TinyMC (hurry.tinymce) and more. There are all available on PyPI.
To use jquery for instance you could add ``hurry.jquery`` to your
project's setup.py. When installing your project hurry.jquery will then
be installed. This contains both the jquery library resources as well as
a description of them.
In your application you can then do:
from hurry.jquery import jquery
and then, when you generate a page that needs jquery support on it, you
say this somewhere in the Python code that gets executed during (or
before) page rendering:
jquery.need()
What this will do is automatically include a script tag in your web
page that loads jquery.
A more interesting example is jqueryui:
from hurry.jqueryui import jqueryui
... jqueryui.need() ...
will now automatically include not only jqueryui but also jquery itself
(as this is a dependency). jquery and jqueryui are relatively simple
examples, but for YUI, hurry.yui is aware of YUI's complex internal
dependencies.
hurry.resource allows you to write code that only includes javascript
resources in pages when they're actually needed. Imagine a form widget
for instance that needs TinyMCE: only when that form widget is displayed
do you want to include TinyMCE on the page. Your code might not know
when the form widget is displayed at all, and therefore the right place
to express that you want TinyMCE is in the form widget itself.
hurry.resource lets you do that.
During deployment it's nice to be able to show only minified javascript,
and it's easy to express this using hurry.resource:
hurry.resource.mode('minified')
hurry.resource also offers support for rolling up multiple resources
into a single larger library, and rendering javascript at the bottom of
a page instead of in the head section for performance reasons.
To support hurry.resource for your application or framework you'd need
to do the following:
* have a way to publish the resources included with a
hurry.resource-based package to the web. Finding out what in a
package to publish is probably the most ungeneric feature of
hurry.resource now as it's in a configure.zcml file; I think it needs
to go into an setup.py entry point instead.
* instruct hurry.resource how to render the correct URLs to resources.
* instruct hurry.resource how to find the object that maintains the
needed resources (could be in the WSGI environ or be a thread-local).
* integrate the supplied middleware.
The steps where hurry.resource is instructed both use zope.component,
but I'm willing to change things so that this can be done using a simple
registration API instead.
I hope I've interested someone to look into this. Suggestions for
improvements are welcome.
Much more information can be found here:
http://pypi.python.org/pypi/hurry.resource/
Regards,
Martijn
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Announcing bobo
Hey, On Thu, Jun 18, 2009 at 3:55 AM, Sergey Schetininmal...@gmail.com wrote: [snip] In particular you should be able to assign a component to any URL in the same sense that you can give an object any name. You should also be able to build relocatable URL trees which can be mounted anywhere in the calling application suite. Do I catch your meaning correctly? Spot on. This is what object traversal (as in Zope) tends to allow. While each individual URL tree (i.e. object structure) might have various expectations concerning relative URLs, they can be combined together by putting the right types of objects together. This allows the composition of larger web apps out of smaller components without there having to be a global map of how URLs map at all. Regards, Martijn ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Announcing bobo
Hey, On Tue, Jun 16, 2009 at 6:15 PM, Etienne Robillardrobillard.etie...@gmail.com wrote: I don't care about '97, pretty much. Those who do not learn from history are destined to repeat it. :) I think that if this Jim guy has lots of experience then at least he could not pretend that other people works are made by/for geniuses, which is probably untrue anyway. There's other ways to advertise a open source project I think you misread him. He said it the goal is for it to be simple, he didn't say other people's works are complicated. Besides; I think Jim would be the first to admit that some of his other works are actually a bit harder to understand for other people. Zope 2 and Zope 3, which Jim both designed, are considered by many to be more than a little bit intimidating. One method is to discriminate other projects, thus making it's own work appears better in some ways or another. Of courses this has nothing to do in being a genius.. You don't have to be a genius to copy-and-paste things. You're reading things that Jim didn't write anywhere as far as I know. He doesn't compare Bobo with anything else. He just states what the goal is. What he does say is that he built Bobo on other people's work, giving it credit. Regards, Martijn ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Announcing bobo
Hey, On Tue, Jun 16, 2009 at 6:27 PM, Aaron Wattersarw1...@yahoo.com wrote: [snip] If python had a framework that had a simple and straightforward organization 5 to 10 years ago I don't think either PHP or Ruby/Rails would have ever evolved. 5 years ago would've been far too late for PHP. Even 10 years ago; PHP has been around since '95 and I think was fairly popular quite soon. Even Rails goes back to '04 - not sure when it got really popular. (anyway, I know you were around back then and before me, I just like history) In general, I don't think there's anything that could stop people from creating their own new web frameworks. :) At best we can aim to reuse bits and pieces and work towards making that easier. Regards, Martijn ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Alternative to threading.local, based on the stack
Hi there, 2008/7/4 Iwan Vosloo [EMAIL PROTECTED]: [snip] A lot of the frameworks use a thread local context to solve this problem. I'm assuming these are based on threading.local. (See, for example: http://www.sqlalchemy.org/docs/05/session.html#unitofwork_contextual ) scoped_session is actually, I think, a bad example, as SQLAlchemy uses the thread id to scope things per session, not threading.local. As long as there's a way to uniquely identify context, scoped_session could also be scoped differently, as long as it has a way identify the context that doesn't need any non-global parameters. Zope 3 may be a better example, as it does use thread locals to scope things per thread (I believe this requirement by Zope was actually one of the reasons this feature was moved into Python). There may also be other parts of SQLAlchemy that indeed use thread local variables. Regards, Martijn ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Alternative to threading.local, based on the stack
Hey, On Fri, Jul 4, 2008 at 1:37 PM, Iwan Vosloo [EMAIL PROTECTED] wrote: On Fri, 2008-07-04 at 13:31 +0200, Martijn Faassen wrote: scoped_session is actually, I think, a bad example, as SQLAlchemy uses the thread id to scope things per session, not threading.local. As long as there's a way to uniquely identify context, scoped_session could also be scoped differently, as long as it has a way identify the context that doesn't need any non-global parameters. Zope 3 may be a better example, as it does use thread locals to scope things per thread (I believe this requirement by Zope was actually one of the reasons this feature was moved into Python). There may also be other parts of SQLAlchemy that indeed use thread local variables. Point taken, I'm not familiar with the implementation of scoped_session. But still, it is the same idea as that implemented in threading.local, isn't it? Yes, I think so, except that scoped_session is more flexible than that and could actually be convinced to use your technique for identification of scope as well. Regards, Martijn ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Are you going to convert Pylons code into Python 3000?
Hey, On Wed, Mar 5, 2008 at 3:25 AM, Guido van Rossum [EMAIL PROTECTED] wrote: On Tue, Mar 4, 2008 at 6:13 PM, Martijn Faassen [EMAIL PROTECTED] wrote: Hey, On Wed, Mar 5, 2008 at 1:48 AM, Graham Dumpleton [EMAIL PROTECTED] wrote: [snip] In the case of code which directly talks to the interface defined by WSGI specification I very much doubt the py2to3 script will help. This is because for WSGI to work with Python 3.0 there needs to be a change from use of string type objects to byte string type objects. I would suspect that py2to3 is only get help in any sort of automated way with the fact that a string object becomes unicode aware, not where with WSGI the code would have to change to use and deal with a different type of object completely. The implications of this change to a byte string type object are going to be much more complicated. I have no idea what the capabilities of this script are. I would *imagine* it would convert classic strings into the bytes types, and unicode strings into the new string type. It does nothing of the kind. It leaves 'xxx' literals alone and translates u'xxx' to 'xxx'. That's because (in many apps) both are used primarily for text. BTW I suggest that you play with it at least a little bit (run it on its own example.py file) before diving into this discussion... I accurately described my lack of knowledge of the script, then. :) Sure, I need to play with the script. I guess the best route would be to introduce bytes in your code in Python 2.x and have the script leave that alone. If WSGI 2.0 then makes it into Python 2.x as well, then there's no problem with API breakage. Playing with the script will happen sometime, but I think it's quite clear the script will be of no help if important library APIs also break down because people take their chances during transition (and the script doesn't take care of it, which it can't for third party APIs). WSGI is probably not the best example given the string issue and its inclusion in the Python core, though: as Graham expressed, it's probably going to have problems no matter what. I also think any new version could be developed on Python 2.6 first, as this will support the bytes type as far as I understand. And yes, I need to try the Python 2.6 alpha interpreter first too. :) Regards, Martijn ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] JavaScript libraries
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 ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] JavaScript libraries
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 ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] JavaScript libraries
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 ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] JavaScript libraries
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 ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Re: Just lost another one to Rails
A.M. Kuchling wrote: On Mon, Apr 18, 2005 at 05:01:41PM +1000, Anthony Baxter wrote: If you spell it wrong, you either get a broken web application with no useful traceback, or else a monstously hideous traceback that's almost entirely useless. This is also part of why I've never been able to get anywhere with Twisted, and why I'm suspicious of systems that depend critically on interfaces, adaptors, and other such extensions to the object model. When they go wrong, diagnosing the problem is messy, and simple typos can get turned into huge debugging expeditions. I think this fairly accurately describes the risk of strongly decoupled systems like Zope 3 and Twisted. In the beginning of OO, people had this complaint about inheritance hierarchies too. And they were partially right, but not entirely. I believe adaptation is a useful tool, but like inheritance, one shouldn't overdo it and use with it with care. I can certainly say Zope 3 in some areas goes overboard with this. How would you deal with the flexibility requirements that these systems have, though? Regards, Martijn ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Re: Just lost another one to Rails
Greg Wilson wrote: Paul Boddie wrote: ...I firmly believe in unbundling templating languages from frameworks. But doesn't that just make more work for the poor sods who are trying to build things? After all, they have to rebundle them, don't they? I think there's a difference between maintaining and developing something separately and not physically distributing something together. I agree that the Zope project, for instance, should be maintaining and distributing the ZODB separately from Zope, as they have been doing for some time now. But I certainly don't mind Zope shipping with right version of the ZODB included and having to only install Zope. If you really want to solve this, you'd end up with package management systems with dependency resolution. Most linux distributions have this. Let's not worry too much about physical distribution in this debate, more about how web frameworks should be organized and how they should relate to each other. Regards, Martijn ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Re: Just lost another one to Rails
Hey, Not much debate from me here on this front, just a lot of agreement. Ian Bicking wrote: Martijn Faassen wrote: [...] One issue seems to be that Python programmers are automatically allergic to domain specific glue languages like ZCML, especially when they look like XML. I think this attitude is not really reasonable, but it's extremely widespread. Jim Fulton looked into a Zope 3 based bobo a while back; something I haven't studied, but might be a way to avoid ZCML for some projects. In my gut -- and I don't think I'm alone -- ZCML doesn't feel right to me. It's quite literally a gut feeling, or maybe you could call it a code smell, it just doesn't smell right to me. Experience might or might not change that feeling, but it's there nonetheless. Do you think domain specific component configuration/glue languages are not right in general, or is it something specific about ZCML in particular? [...] This: http://svn.zope.org/Zope3/trunk/src/zope/app/demo/hellopackage/ is a documented hello world package in Zope 3 by the way. It creates a persistent hello world object that can be added through the Zope 3 UI, with a page template and the like. It's too verbose as a minimal case; dumping the UI requirement and some stylistic issues could cut it down a bit more. If you were to add 'hello world' as a template to an existing object, it'd be a lot simpler still (cutting away all Python code and just leaving a ZCML snippet to hook up the template, and the template itself). Looking just very briefly, I think the issue is one of approachability and incremental learning. Agreed completely, very good point. I harped about this on the Zope 3 list for a while last year. There's some big concepts there, and it's unclear where to start. Interfaces, adaptation, ZCML, ZPT... they are all somewhat foreign, at least to the typical Python programmer. I think Jeffrey Shell has been trying to create a more linear tutorial with a to-do list, which is probably a good idea. A good tutorial -- challenging to make, to be sure -- is one where each step seems clear, relevent to previous steps, and creates something usable. And where you don't have to say ooh, this stuff is something you can ignore for now, *and* where you don't have to explain a lot of irrelevant material as well. My favorite example of this is Hello world in Python versus Hello world in Java. In Java, to new programmers, you'll either have to say well, ignore this class thingy for now. Just look at the method. Ignore this too. And that, which gives a bad impression of programming. Or alternatively, you'll have to explain it all well, this is a class, and that's to do with object oriented programming, which is.. which will confuse and overwhelm new programmers entirely. Zope 3 suffers from the same problem. I think in part this can be solved by writing a good tutorial as you say, and in part we need to ruthlessly eliminate stuff that we otherwise cannot avoid in the tutorial. The Zope 3 tutorial as written by Jim Fulton is very complete, but is not a good tutorial for beginners in my mind. It introduces functional doctesting using tcpwatch before you write your first adapter, or something... I attempted to write something like a simple tutorial in the context of Five (Zope 3 in Zope 2). Here they are, in all their magicpoint glory: http://codespeak.net/svn/z3/Five/trunk/doc/five_interface_tutorial.mgp http://codespeak.net/svn/z3/Five/trunk/doc/five_views_tutorial.mgp Most of this can be safely translated to Zope 3, which in fact I did in part for a presentation once. It is still too overwhelming perhaps for the amount of stuff you end up doing, which isn't that much. I think this is really where my gut feeling about ZCML comes from -- it's intimately tied to other pieces of the code, and often is a prerequesite to making that code functional (at least functional with respect to its real intention, which is usable in a Zope context), and separate files that have to be subtley in sync always makes me uncomfortable. Of course, that kind of dependency happens all the time, and in an interconnected system you can't expect otherwise. But I won't try to make it an entirely rational argument, that's not actually where my uncomfortable feeling is coming from. I recognize the feeling. Python was liberating after having to mess about with header files in C and C++ for me, and they are slightly similar to ZCML. ZCML and interface files bring the header file feeling back to Python, which is not good. Even though I also agree that this kind of dependency really happens all the time, and you can't really expect otherwise in larger systems. I also think some concepts are being overused in Zope 3. Adaptation, specifically -- multi-argument Adapters break my understanding of what Adaptation is supposed to be, and I think they are being used for all sorts of clever, useful things, where clever is meant
Re: [Web-SIG] Pure Python HTML?
Bill Janssen wrote: I don't know about you, but generating HTML with pure Python code can be messy--ONE reason why we introduce templateing languages in the first place. Often (not always) the best way to end up with XHTML is to start with a valid or almost-valid XML document and then infuse the dynamic content. Indeed. And in Python I do it with string formatting: [snip] This works for small scale projects where only a few developers are expected to know the codebase. But in a larger scale project where you have to work with web designers which may not know a lot of Python, this doesn't really work. There are also other aspects, like i18ning your HTML, which would be hard to do with your example. It's the black box principle; I don't want to go through your Python code just to tweak a bit of HTML. The idea of ZCML is for programmers to be able to reconfigure or extend the behavior of other people's code without having to change, or hopefully even fully understand, that code itself. The idea is that this pays off once you are working in a larger scale project or cluster of projects, like in the Zope community. I don't think this discussion will go anywhere though, as your position seems to be too extreme in this respect to easily move out of. :) Regards, Martijn ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
