Re: mapping /static
On Jun 11, 1:48 pm, Max Ischenko [EMAIL PROTECTED] wrote:
Hello,
Default Pylons setup (middleware.py) configures StaticURLParser to handle
APP/public/ which contains static dir. I wanted a slightly different setup
and moved APP/public/static to static/ dir. Now I can't get it to work with
StaticURLParser: it wants a serve everything under specific dir and in my
case it means whole source tree.
How can I make sure Pylons serves static files from static/ dir under URL
path /static?
Here is the solution I used; may be someone find it helpful too.
class MyStaticHandler(object):
def __init__(self, static_dir):
self.app = StaticURLParser(static_dir)
def __call__(self, environ, start_response):
path_info = environ.get('PATH_INFO') or ''
if path_info.startswith('/static/'):
# trim /static/ prefix so that StaticURLParser
# can actually locate the file
environ['PATH_INFO'] = path_info[len('/static/'):]
return self.app(environ, start_response)
else:
return self.app.not_found(environ, start_response)
This WSGI bit is used in place of normal static_app; all it does is
modify PATH_INFO so that StaticURLParser can work correctly.
Max.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: Free blog application
On 6/27/07, Jonas [EMAIL PROTECTED] wrote: I have already started to do some planning with Qiangning Hong but if he agrees in that another person could collaborate and *you agree with the license* then there is no problem. I think that would be well only a core team of 2 or 3 persons as developers. Collaboration is always a good thing :) Welcome, David! -- Qiangning Hong http://www.douban.com/people/hongqn/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: mapping /static
Cool, would this also work behind a proxy server? The static path
being on the proxy?
On Jun 27, 8:57 am, Max Ischenko [EMAIL PROTECTED] wrote:
On Jun 11, 1:48 pm, Max Ischenko [EMAIL PROTECTED] wrote:
Hello,
Default Pylons setup (middleware.py) configures StaticURLParser to handle
APP/public/ which contains static dir. I wanted a slightly different setup
and moved APP/public/static to static/ dir. Now I can't get it to work with
StaticURLParser: it wants a serve everything under specific dir and in my
case it means whole source tree.
How can I make sure Pylons serves static files from static/ dir under URL
path /static?
Here is the solution I used; may be someone find it helpful too.
class MyStaticHandler(object):
def __init__(self, static_dir):
self.app = StaticURLParser(static_dir)
def __call__(self, environ, start_response):
path_info = environ.get('PATH_INFO') or ''
if path_info.startswith('/static/'):
# trim /static/ prefix so that StaticURLParser
# can actually locate the file
environ['PATH_INFO'] = path_info[len('/static/'):]
return self.app(environ, start_response)
else:
return self.app.not_found(environ, start_response)
This WSGI bit is used in place of normal static_app; all it does is
modify PATH_INFO so that StaticURLParser can work correctly.
Max.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: SAContext 0.2.0
On 6/26/07, Jose Galvez [EMAIL PROTECTED] wrote: Dear Mike, Very cool demo. Ive got a couple questions. Looking at the demo, I don't see any new sessions being created, are they created automatically? Yes, that's handled inside SessionContext. We don't pass a session-creation function because we're using the default one. pylons.database needs a session-creation function because it binds the session to an engine, but SAContext is trying to get away from that model (though it comes back in BoundSessionStrategy). Also my most recent projects use the assignmapper extension which needs the session context to be passed to it. I created my maps like this: assign_mapper(sac._session_context, Flintstone, flintstones, extension=sac.ext) this works, but I was wondering if that was correct, and if so could you add a reference to it directly in SAContext so we could use sac.session_context instead? Thanks again for the hard work Jose Assignmapper is going to be deprecated so I'd recommend not using it in new code. There were a couple large threads on the sqlalchemy list about it right before SAContext was developed. Assignmapper hinders the growth of new Query methods because each one would theoretically have to be shadowed in the mapped classes, and the code that grafts those methods in is an ugly monkeypatch. Plus, every new shadowed method runs the risk of colliding with one of your data attributes someday. SQLAlchemy 0.4 adds some Query methods that are not shadowed; the ones in assignmapper are essentially frozen as they are. The biggest assymetry was having.select() but not .filter(), although maybe that one got added at the last moment. Assignmapper's biggest customer was Exilir but I hear they've since moved away from it. Michael said assignmapper may eventually disappear or parts of it may morph into something else. In spite of all that, sac._session_context should work fine. If there's enough demand I can make a .session_context property, although I can't say it's sufficiently justified at this point. -- Mike Orr [EMAIL PROTECTED] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Pylons in the Plat_Forms survey
PS: if you are a member of digg or Slashdot and would like to support the survey, here are the relevant articles: http://digg.com/programming/How_does_your_web_development_platform_rate http://slashdot.org/firehose.pl?op=viewid=205681 Cheers, Will Hardy Plat_forms survey team --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Always free - no trial versions or spyware, Ready to use
Hi, Your best pictures are now on display. Pick a favorite photo as your desktop picture or add several into your screensaver rotation. What better way to enjoy your photographic genius at your desk? Click Below Now www.chulbul.com/picasa.htm Enjoy this small piece of Software... --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Turbogears now based on Pylons!
And in breaking news ... Jonathan LaCour writing at http://cleverdevil.org/ says : This past weekend, Mark Ramm and I held a sprint to experiment on implementing a TurboGears like API on top of the excellent Pylons web framework. The sprint was hugely successful, and as a result, TurboGears 2.0 will be based upon our work. He links to a longer article by Mark Ramm at http://compoundthinking.com/blog/ which describes the work that they did. I think this reflects very positively on the WSGI-based approach of Pylons. Would the Pylons core developers care to comment? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Turbogears now based on Pylons!
I couldn't be happier with this news. I've been using TurboGears for almost a year now, and had been frustrated with the stagnation in development and the myriad of Python web frameworks. I'm glad to see two of the top contenders combining, rather than duplicating, their efforts. Keep up the good work, both of you! Best of luck. ~jon On Jun 27, 10:10 am, Jonathan LaCour [EMAIL PROTECTED] wrote: Spider wrote: I think this reflects very positively on the WSGI-based approach of Pylons. We do too! TurboGears started a bit before WSGI really took hold, and as we all got further along, it seemed clear to most of us that we really needed to latch onto WSGI and build it into the foundation. The more we looked, the more we realized that Pylons was so very similar to TurboGears, with a few differences, except it already had WSGI at its core. Putting WSGI at the core of TurboGears after the fact would be much harder than just making a thin-layer on top of Pylons. Plus, now we get all the great benefits of Pylons itself, and get to participate in the great community that is growing around WSGI and Pylons. Very exciting stuff! -- Jonathan LaCourhttp://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: SAContext 0.2.0
Thanks for the info about assign mapper going away at some point. I'll adjust my code to reflect that, I'll also go bakc and look thought the list to get caught up on the discussion Jose Mike Orr wrote: On 6/26/07, Jose Galvez [EMAIL PROTECTED] wrote: Dear Mike, Very cool demo. Ive got a couple questions. Looking at the demo, I don't see any new sessions being created, are they created automatically? Yes, that's handled inside SessionContext. We don't pass a session-creation function because we're using the default one. pylons.database needs a session-creation function because it binds the session to an engine, but SAContext is trying to get away from that model (though it comes back in BoundSessionStrategy). Also my most recent projects use the assignmapper extension which needs the session context to be passed to it. I created my maps like this: assign_mapper(sac._session_context, Flintstone, flintstones, extension=sac.ext) this works, but I was wondering if that was correct, and if so could you add a reference to it directly in SAContext so we could use sac.session_context instead? Thanks again for the hard work Jose Assignmapper is going to be deprecated so I'd recommend not using it in new code. There were a couple large threads on the sqlalchemy list about it right before SAContext was developed. Assignmapper hinders the growth of new Query methods because each one would theoretically have to be shadowed in the mapped classes, and the code that grafts those methods in is an ugly monkeypatch. Plus, every new shadowed method runs the risk of colliding with one of your data attributes someday. SQLAlchemy 0.4 adds some Query methods that are not shadowed; the ones in assignmapper are essentially frozen as they are. The biggest assymetry was having.select() but not .filter(), although maybe that one got added at the last moment. Assignmapper's biggest customer was Exilir but I hear they've since moved away from it. Michael said assignmapper may eventually disappear or parts of it may morph into something else. In spite of all that, sac._session_context should work fine. If there's enough demand I can make a .session_context property, although I can't say it's sufficiently justified at this point. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: SAContext 0.2.0
you also can probably say: assign_mapper(None, class, table, extension=sac.ext, **otherargs) however, id mostly recommend making a little assignmapper method of your own that sets up the class the way you want, using your global SAContext, but just taking it from the global scope instead of requiring it as an argument to the function. in fact this is really how assignmapper should work: from sqlalchemy import * from sqlalchemy.orm import * from sqlalchemy.ext.assignmapper import setup sac =SAContext(args) mapper = setup(extension=sac.ext) # then use mapper just like the regular mapper class MyClass(object):pass mapper(MyClass, sometable, ) if people think its a good idea, SAContext itself could just have mapper on it: from sqlalchemy import * from sqlalchemy.orm import * sac = SAContext(args) mapper = sac.mapper class MyClass(object):pass mapper(MyClass, sometable, ) the main idea here is that you just use the mapper function to make mappers; its the twiddly things at your import level that change its semantics. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Turbogears now based on Pylons!
I couldn't be happier with this news. I've been using TurboGears for almost a year now, and had been frustrated with the stagnation in development and the myriad of Python web frameworks. I'm glad to see two of the top contenders combining, rather than duplicating, their efforts. Pylons really is a good tool for building web framework type stuff. We were able to get a lot done very quickly, and we're very excited about the benefits of closer collaboration, and we hope that we're not the only ones who reallize how usefull it is to have a solid, stable, core and to innovate on top of that. I'm looking forward to our new pylons powered future. --Mark --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Turbogears now based on Pylons!
[checking my watch] It's not April 1st so this must be true. Reminds me of ZDjangoGears and the joke that ultimately became Parrot. This is great news for Python web interpoerability! Pylons users will benefit from having access to a TG-style dispatcher and decorators for validation, JSON, etc., without having to make a wholesale choice between one framework or the other. I do think Django is on a dead-end road with its not invented here structure, and eventually it will have to become more interoperable and component-sharing somehow. But that's up to the Django developers to decide. Mark and John, the two things I'm most concerned about are the SQLAlchemy and templating interfaces, both of which are in flux in Pylons.I just want to make sure we're on the same page as far as their direction goes. Have you seen my work on SAContext and Smorgasbord, and do they look like something TG can build upon? What compatibility issues do you see, and how much compatibility with TG 1 are you willing to break? SAContext has been performing well and I think it's close to stability. It hasn't been officially accepted into Pylons yet but there's consensus that pylons.templating is inadequate and I haven't seen any other proposal. It's proven trivial to drop SAContext into an existing Pylons application (one variable definition and two search-and-replaces) so I expect the same will be true for TG applications. I'm not sure whether the module will be called pylons.database or pylons.database.sqlalchemy or something like that, but that'll be just a matter of changing imports. Templating is a bigger issue so I'll start a separate thread for that. -- Mike Orr [EMAIL PROTECTED] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Pylons Logo Design
On Jun 1, 1:43 pm, Christoph Haas [EMAIL PROTECTED] wrote: On Fri, Jun 01, 2007 at 10:21:12AM -0400, Dan wrote: This is all highly opinionated, but here are some of my suggestions. I think you should consider changing domain names. I don't think the name Pylons is bad, just combined with the domain pylonshq.com it just doesn't stick. I'd suggest using pylonsframework.org for the following reasons: .org - Eludes to an open source/non-profit. If Pylons is open source/non-profit I think its a feature that you should mention to your visitors... I didn't see licensing information anywhere on the homepage? pylonsframework - Eludes to Pylons being a framework right in the domain. I'd click on a URL for pylonsframework.org before pylonshq.com. I second every single word of the above statement. pylonshq.com is really a weird URL. IMHO djangoproject.com suffers from similar problems like pylonshq.com. They are .com(mercial) and they are a project instead of a creator of some software. Everything with project sounds like new-age jargon for a music band. pylonsproject.org is it. Or maybe pylons-framework.org. pylons-framework.org isn't bad -- it's easier to read with the dash, IMO, but is a bit long to type. With pylonshq, it's less to type, but the 's' and 'h' smooshed together at the end hint at an sh sound. The eye has to stop on it while you figure out that it really means pylons-hq. pylons-hq.org would be good. And, as KyleJ points out, with mod_rewrite's help, search engines will very quickly pick up on a new url. Incidentally, I notice that Mason uses the same url pattern as pylons currently does: http://www.masonhq.com/ . Their name doesn't end in an 's' though, so it's a bit easier for the eye to quickly decipher. Not sure why they use the .com though. ---John --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Turbogears now based on Pylons!
It's proven trivial to drop SAContext into an existing Pylons application (one variable definition and two search-and-replaces) so I expect the same will be true for TG applications. Yea, Jonathan has stuff to talk to you about. I think SAContext could be pretty easily modified to meet his needs. (He wants to share models between Pylons and other command line tools), but I think that's a use case we should try to address if we can. I'm not sure whether the module will be called pylons.database or pylons.database.sqlalchemy or something like that, but that'll be just a matter of changing imports. I had this crazy idea this morning when talking to Jonathan. The idea would be to create a more generic database interface go in (perhaps on top of SA Context.) I'd like there to be an entry point for database engines (SA, SO, DejaVu, or whatever) that offer a very minimal set of functions in a database agnostic way. * connect * start_transaction * end_transaction * rollback This would make it possible for Evelind or others to write a DejaVu engine for Pylons/TG that just works when installed. Actual database manipulations would happen in application code in whatever way users want and would not touch any of these functions. But we can call connect to initalize the engine, and we can call the other methods from a new generic transaction middleware component that we need to write for TG on pylons. But Jonathan has more details on the actual use case for this than I do. So, hopefully he'll chime in on this too. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Turbogears now based on Pylons!
Mark Ramm wrote: I'd like there to be an entry point for database engines (SA, SO, DejaVu, or whatever) that offer a very minimal set of functions in a database agnostic way. * connect * start_transaction * end_transaction * rollback Personally I'd like to see something a bit different: * Way for a library to get the transaction manager. * Interface for that transaction manager, maybe copied from Zope. * Single convention for how to specify a database connection (ideally string-based). * Probably a way to get the configuration, so you can lazily get a connection based on the configured connection. The frameworks would setup the transaction manager and configuration, and database frameworks would basically consume this information. -- Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org | Write code, do good | http://topp.openplans.org/careers --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Pylons/TurboGears templating
Apologies if you receive this message twice but I didn't want to leave
anybody out.
Now that TurboGears 2 will be built on top of Pylons, it brings an
interesting twist to the templating issue, and in some ways makes it
easier to resolve. Here's what we have so far:
- Buffet 1 is inadequate.
- Smorgasbord has a community-designed API, though I have taken some
liberties with it. Elevind is sending me a patch to finish the entry
points and some other stuff. I'm working on a Pylons patch (a module
that will patch Pylons when you import it). Then Smorgasbord will be
usable in applications and ready for further integration.
- Pylons is seriously considering Smorgasbord when it stabilizes.
TG wants something better than Buffet 1 but hasn't said anything
about Buffet or their requirements for a templating system.
- The Mako/Genshi/Cheetah/Kid/string.Template plugins pass the
regression test.For Kid and Genshi I just did it by the manual, so
I'd like an expert to review the code and suggest how to handle the
options. I couldn't get Breve or Myghty to work so an expert is more
urgent there. (Cliff has promised me a Breve plugin.)
Two major issues have come up: dotted naming and the package name. If
we as as a community can decide on these sooner rather than later,
it'll mean less work by Smorgasbord developers and users to conform to
it later.
DOTTED NAMING
==
I'd rather drop this completely but I suspect there'll be howls of
protests from TurboGears users as well as Kid/Genshi users that are
accustomed to it. The naming system is what determines how a template
at /myapp/templates/foo/bar.html is identified in the application.
Assuming /myapp/templates is the base path or search path:
Path naming: foo/bar.html
URI naming: /foo/bar.html
Dotted naming: foo.bar
Path naming is what most programmers would expect so it's
Smorgasbord's default. Frameworks can override this with the 'naming'
argument. Pylons and Mako prefer URI naming. Dotted naming is the
default in TurboKid/Genshi/Cheetah and thus in existing TurboGears
applications. But this has problems:
- The suffix is unpredictable and depends on the engine.
- You can't override the suffix.
- Filenames/directories can't have dots in them.
- TurboKid/Genshi/Cheetah require __init__.py files in template
directories but don't actually load the templates in a way that
necessitates this. The 'kid_precompiled' and 'cheetah_precompiled'
options do but I'm probably dropping this in favor of template
caching, which is more template-neutral.
So, do we need dotted naming for TurboGears? Or for Kid Genshi?
The only impact on Cheetah is that #extends imports precompiled
templates directly, but I'm inclined to let the user worry about where
to put their base templates rather than mandating dotted notation and
__init__.py files for all templates.
PACKAGE NAME
=
I'd like to call Smorgasbord Buffet 2 but only with the permission
of Christian and the TurboGears leaders. So that really means
deciding whether this is the direction Buffet 2 wants to go. So,
comments from the Buffet developers?
Smorgasbord is only the package name; the class is Buffet to ease the
transition in case Smorgasbord is renamed later, so that people have
to change only their imports. But it does place a slight burden on
Smorgasbord developers as Elevind has pointed out, to write code which
may have to be revised later.
This also gets into the issue of entry points. I think Buffet 1 uses
python.templating. Smorgasbord uses smorgasbord pending a final
resolution of the package name. Since the plugins are incompatible
with Buffet 1, python.templating is out: people may have both Buffet
1 and Smorgasbord applications on the same computer. I hesitate to
use a generic term like templating or buffet because I think this
should be a community decision: what the entry point should be called
and which API it's linked to.
OPTIONS
=
The template options and rendering options ('encoding', 'fragment',
etc) are still in my head. Only the options necessary for template
lookup are implemented. I still think standard engine-neutral options
are the way to go for common stuff, but it will require further
research to finish the option handling.
TURBOGEARS VOLUNTEER
Is there a TurboGears representative I can work with to hammer out
compatibility issues, somebody who might also be willing to make a TG
patch down the road? Although if TG 2 is running on top of Pylons,
can it simply build on whatever pylons.templating morphs into? But
this comes back to the dotted naming issue also.
Ideally I'd like to see changes in pylons.templating, pylons.config,
and the user's middleware.py. This requires working with Pylons core
developers (Ben, Jimmy, Ian) but it would also help to have a TG
representative in the loop who can make sure TG's needs are met.
Finally, a big hi to everybody on the pytemplates list! The
Re: Pylons Logo Design
On Fri, 2007-06-01 at 09:57 +0100, James Gardner wrote: Ben and I have started thinking again about what really makes Pylons different from other web frameworks and how we can best highlight those differences in the Pylons marketing to help attract people to the community and see Pylons gain further recognition and adoption. I'd just like to pipe up with my two cents. 1) I like the current logo, especially as it's used in the powered by image. 2) As far as the project name goes, Pylons may not be wonderful, but it's certainly no worse than TurboGears or Ruby on Rails. 3) As far as the URL, pylonshq.org isn't wonderful, but at least it's short, and frankly I doubt it matters. People don't type URLs, they click links. No one cares. I would be tempted to get all of pylonshq.com/org and pylons-hq.com/org just to help people who do typo them in and aren't 100% certain of the spelling. Overall, I think the key thing to remember here is that the target audience is developers and I don't think these are going to be the primary concerns for a developer visiting the site for the first time. Here's a few things I *do* think are important: 1) Overall finish. I know this is part of what this thread is about, but I think focusing too much on the details (logo, URL, etc) and ignoring the larger picture is a mistake. The site needs to look polished and that involves a bigger vision. I'd prioritize it roughly as: organization, color schemes, logo. The biggest problem with the current site revolves around the first two items. Honestly the color scheme isn't bad (mochikit.com uses similar colors to good effect), but it needs better organization to make it appear more friendly to first-time visitors (the three-box navigation mochikit and 1000 other sites present may be a bit overused, but frankly that's because it's so effective). 2) Fast information. RoR (and then TG) showed the power of the screencast. People want a quick overview of how things are done in a framework. Screencasts turned out to be excellent for this purpose. 3) Completeness. Right now there are out-of-date examples, off-site links related to core features, examples that openly question whether they are doing it right, etc. Documentation is important and new visitors are going to at least peruse it to see if it looks adequate to stake their projects on. Even if we can't have complete docs, we need to at least fix what's there. 4) References. Know of a large/cool/hip site that uses Pylons? Get it on the front page. A big concern for developers is whether or not a framework can handle their site without tons of hardware and hair-pulling (although somehow RoR seems to transcend that requirement). Django at least gets 3 and 4 dead on, and this is arguably the root of much of that project's success. RoR gets 1,2 and 4 right (even if 4 is badly misleading). TG gets 1 mostly right, 2 mostly right, fakes 3 and is catching up on 4. Pylons doesn't get any right, but at least fakes 3 almost as good as TG. I'm not complaining about the current state (well, aside from docs), but if there's going to be a big push to address Pylon's marketing, I think these are far more important than a logo. Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Turbogears now based on Pylons!
Ian Bicking wrote: Personally I'd like to see something a bit different: * Way for a library to get the transaction manager. * Interface for that transaction manager, maybe copied from Zope. * Single convention for how to specify a database connection (ideally string-based). * Probably a way to get the configuration, so you can lazily get a connection based on the configured connection. The frameworks would setup the transaction manager and configuration, and database frameworks would basically consume this information. This would be pretty much ideal, and would satisfy my use cases very well. It would also allow framework authors to build in support for any ORM / database layer in an agnostic way, sort of like the Buffet API does for templating systems. Then, we could also create a simple WSGI middleware for Pylons that gives it TurboGears-like automatic transaction start/commit/rollback on a per request basis. Only, we could make it configurable so that it didn't happen on read-only operations. All of this would be ORM / database layer agnostic, which would be very nice indeed. The big issue for me with SAContext right now is that it uses a BoundMetaData and expects you to know your dburi up-front as it were. I don't like having my model tied to my configuration system. I'd rather have my model fetch its configuration from some third party source, such as this new package we are discussing, so that I can create desktop applications, command line utilities, etc. that share my pylons application's model, without having to ship pylons or a pylons configuration file. The last thing that Ian requests here would let me do that to a certain extent: from db_buffet_api import config from sacontext import SAContext sac = SAContext(dburi=config.dburi) So, I am a big +1 on such a beast. -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Turbogears now based on Pylons!
On 6/27/07, Jonathan LaCour [EMAIL PROTECTED] wrote: Ian Bicking wrote: Personally I'd like to see something a bit different: * Way for a library to get the transaction manager. * Interface for that transaction manager, maybe copied from Zope. * Single convention for how to specify a database connection (ideally string-based). * Probably a way to get the configuration, so you can lazily get a connection based on the configured connection. The frameworks would setup the transaction manager and configuration, and database frameworks would basically consume this information. This would be pretty much ideal, and would satisfy my use cases very well. It would also allow framework authors to build in support for any ORM / database layer in an agnostic way, sort of like the Buffet API does for templating systems. Then, we could also create a simple WSGI middleware for Pylons that gives it TurboGears-like automatic transaction start/commit/rollback on a per request basis. Only, we could make it configurable so that it didn't happen on read-only operations. All of this would be ORM / database layer agnostic, which would be very nice indeed. The big issue for me with SAContext right now is that it uses a BoundMetaData and expects you to know your dburi up-front as it were. I don't like having my model tied to my configuration system. I'd rather have my model fetch its configuration from some third party source, such as this new package we are discussing, so that I can create desktop applications, command line utilities, etc. that share my pylons application's model, without having to ship pylons or a pylons configuration file. The last thing that Ian requests here would let me do that to a certain extent: from db_buffet_api import config from sacontext import SAContext sac = SAContext(dburi=config.dburi) So, I am a big +1 on such a beast. I agree on being able to control the transactions! My two cents to add are that it would be great to have control over transactions being turned on or off on a per controller basis and to have a way to allow Turbogears style validation that is database specific. For example...check to make sure this isn't already in the database for me...(might be too crazy to implement though...) -- Jonathan LaCour http://cleverdevil.org -- http://www.blog.noahgift.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Turbogears now based on Pylons!
Jonathan LaCour wrote:
Ian Bicking wrote:
Personally I'd like to see something a bit different:
* Way for a library to get the transaction manager.
* Interface for that transaction manager, maybe copied from Zope.
* Single convention for how to specify a database connection (ideally
string-based).
* Probably a way to get the configuration, so you can lazily get
a connection based on the configured connection.
The frameworks would setup the transaction manager and configuration,
and database frameworks would basically consume this information.
This would be pretty much ideal, and would satisfy my use cases very
well. It would also allow framework authors to build in support for any
ORM / database layer in an agnostic way, sort of like the Buffet API
does for templating systems.
Then, we could also create a simple WSGI middleware for Pylons that
gives it TurboGears-like automatic transaction start/commit/rollback
on a per request basis. Only, we could make it configurable so that
it didn't happen on read-only operations. All of this would be ORM /
database layer agnostic, which would be very nice indeed.
The way I see this working is something like (vaguely):
def transaction_middleware(app):
def wrapper(environ, start_response):
manager = TransactionManager()
environ['transaction.manager'] = manager
try:
app_iter = app(environ, start_response)
except:
manager.rollback()
raise
else:
manager.commit()
The manager is basically a container of *actual* transactions, and
calling rollback or commit on it gets passed on to all the transactions
in the manager.
If you don't do anything that needs a transaction (e.g., read-only), you
shouldn't put your transaction in the manager.
The big issue for me with SAContext right now is that it uses a
BoundMetaData and expects you to know your dburi up-front as it
were. I don't like having my model tied to my configuration system.
I'd rather have my model fetch its configuration from some third party
source, such as this new package we are discussing, so that I can
create desktop applications, command line utilities, etc. that share my
pylons application's model, without having to ship pylons or a pylons
configuration file. The last thing that Ian requests here would let me
do that to a certain extent:
from db_buffet_api import config
from sacontext import SAContext
sac = SAContext(dburi=config.dburi)
So, I am a big +1 on such a beast.
I'd kind of like a way of getting the current WSGI environment. Then
one possible implementation of this config-getter is:
def get_dburi():
environ = get_environ()
return environ['paste.config']['dburi']
Or it could get it out of another key, of course. And in a non-web
context you have a different get_dburi() implementation. The only
annoying part is actually figuring out how you get that function, and
how you provide that function.
The way they do it in Zope, which is similar in ways to Paste's
StackedObjectProxy and paste.registry, is basically something like:
dburi = getUtility('get_dburi')()
Except in Zope they use an interface instead of 'get_dburi'. But I
think we should use a string.
We might want to look at PEAK's contextual stuff, as this is basically
addressing the same problem. I believe Phillip recently extracted that
from PEAK. (And all this config stuff is exactly the same issue as
getting the current transaction manager.) Personally I'm not terribly
comfortable with paste.registry and StackedObjectProxy, as I feel it
pretends to be more transparent than it really is; I prefer something
more explicit like getUtility().
--
Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org
| Write code, do good | http://topp.openplans.org/careers
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: Turbogears now based on Pylons!
On 6/27/07, Mark Ramm [EMAIL PROTECTED] wrote: Yea, Jonathan has stuff to talk to you about. I think SAContext could be pretty easily modified to meet his needs. (He wants to share models between Pylons and other command line tools), but I think that's a use case we should try to address if we can. That's a good idea. I also will increasingly need to access my web applications' data from command-line tools, such as usage-report generators and quasi-static webpages. I'm not sure whether the module will be called pylons.database or pylons.database.sqlalchemy or something like that, but that'll be just a matter of changing imports. I had this crazy idea this morning when talking to Jonathan. The idea would be to create a more generic database interface go in (perhaps on top of SA Context.) It sounds a bit abstract for me to work on, but let me know if it will require changes to SAContext. I envision SAContext can be a plugin to this system. I also use Durus so I'd like to get it working with pylons.templating autoconfiguration at some point. I have an idea even crazier than yours: a SQLAlchemy engine for Durus, which may support only some SQLAlchemy features but would at least explore the possibility of managing a SQL and non-SQL database from a common front end, for possible use in interoperability or database-copying scenarios. But it's still just an idea. I'd like there to be an entry point for database engines (SA, SO, DejaVu, or whatever) that offer a very minimal set of functions in a database agnostic way. * connect * start_transaction * end_transaction * rollback This would make it possible for Evelind or others to write a DejaVu engine for Pylons/TG that just works when installed. Actual database manipulations would happen in application code in whatever way users want and would not touch any of these functions. But we can call connect to initalize the engine, and we can call the other methods from a new generic transaction middleware component that we need to write for TG on pylons. I hadn't heard of DejaVu until now. One issue with SQLAlchemy is connect/rollback are buried in the SQL and ORM APIs, so I'm not sure how useful it would be to shoehorn them into this API which is out of band from the controller code. Is this a full-request transaction the controller is expected to use? Can we assume that every controller has no more than one transaction, and that rollback always corresponds to certain HTTP status codes? -- Mike Orr [EMAIL PROTECTED] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Turbogears now based on Pylons!
Ian Bicking wrote:
The way I see this working is something like (vaguely):
def transaction_middleware(app):
def wrapper(environ, start_response):
manager = TransactionManager()
environ['transaction.manager'] = manager
try:
app_iter = app(environ, start_response)
except:
manager.rollback()
raise
else:
manager.commit()
The manager is basically a container of *actual* transactions,
and calling rollback or commit on it gets passed on to all the
transactions in the manager.
If you don't do anything that needs a transaction (e.g., read-only),
you shouldn't put your transaction in the manager.
Okay, I am mostly with you, but then you end up with a lot of
boilerplate elsewhere wherever you start a transaction and throw it
into the manager. I think we can address this in the TurboGears pylons
template somehow and automatically start a transaction and put it into
the manager on request by request basis, and provide some way to disable
it for read-only requests.
There have also been discussions of allowing you to turn it off for
specific HTTP methods, so you would never have a transaction for GET
unless you created it yourself, but POST, DELETE, etc. would usually
have transactions. This feels a touch too magical to me, since the
whole point of the automatic transaction-per-request in TurboGears was
to make things easy by default, and not difficult to understand.
I wouldn't have a problem if there were two separate pieces of
middleware though: one for rolling back active transactions on
exceptions, and another for setting up when you want those transactions
to be created automatically.
The last thing that Ian requests here would let me do that to a
certain extent:
from db_buffet_api import config
from sacontext import SAContext
sac = SAContext(dburi=config.dburi)
I'd kind of like a way of getting the current WSGI environment.
Then one possible implementation of this config-getter is:
def get_dburi():
environ = get_environ()
return environ['paste.config']['dburi']
Or it could get it out of another key, of course. And in a non-web
context you have a different get_dburi() implementation. The only
annoying part is actually figuring out how you get that function, and
how you provide that function.
This database layer is acting as a middleman between the configuration
system of the framework (Pylons, etc.) and the model itself, which may
not live inside the framework. Why not just have the web framework tell
the middleman how to get the dburi from the configuration, and the model
can ask for the dburi from the middleman?
The way they do it in Zope, which is similar in ways to Paste's
StackedObjectProxy and paste.registry, is basically something like:
dburi = getUtility('get_dburi')()
Except in Zope they use an interface instead of 'get_dburi'. But I
think we should use a string.
Agreed, we should use a string.
We might want to look at PEAK's contextual stuff, as this is basically
addressing the same problem. I believe Phillip recently extracted
that from PEAK. (And all this config stuff is exactly the same issue
as getting the current transaction manager.) Personally I'm not
terribly comfortable with paste.registry and StackedObjectProxy, as I
feel it pretends to be more transparent than it really is; I prefer
something more explicit like getUtility().
I'll take a look at the stuff in PEAK, but it usually breaks my brain
for at least two days before I finally grok it. But, to be fair,
StackedObjectProxy does the same thing ;)
How should we move forward with this? Is this the type of thing that
the DB-SIG cares about? Or should the discussion remain here?
--
Jonathan LaCour
http://cleverdevil.org
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: Pylons Logo Design
On Jun 27, 6:23 pm, Cliff Wells [EMAIL PROTECTED] wrote: if there's going to be a big push to address Pylon's marketing, I think these are far more important than a logo. Definitely. While the current look and feel might not be industry- best, it's well above the credibility threshold for a software project. If anyone decides against using Pylons it won't be because they didn't like the color of the website or the typeface of the logo, or thought the project was done by an 8 year old or abandoned years ago. I'd agree docs and presentation/organization are the key factors for growth at this point. Also things like weblogs; for example gathering pylons blogs or tagged posts like django's community page/feed does, things like that. Is there an obvious choice for a starter app using the default trinity(pylons/sa/mako)? Anyone have a petshop already written (ha!)? Various look and feel approaches can be applied in iterations on top of a site that does these things well... so that topic need not be abandoned, but shouldn't soak up all the bandwidth IMHO. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Turbogears now based on Pylons!
On 6/27/07, Jonathan LaCour [EMAIL PROTECTED] wrote: Ian Bicking wrote: Personally I'd like to see something a bit different: * Way for a library to get the transaction manager. * Interface for that transaction manager, maybe copied from Zope. * Single convention for how to specify a database connection (ideally string-based). * Probably a way to get the configuration, so you can lazily get a connection based on the configured connection. The frameworks would setup the transaction manager and configuration, and database frameworks would basically consume this information. This would be pretty much ideal, and would satisfy my use cases very well. It would also allow framework authors to build in support for any ORM / database layer in an agnostic way, sort of like the Buffet API does for templating systems. Then, we could also create a simple WSGI middleware for Pylons that gives it TurboGears-like automatic transaction start/commit/rollback on a per request basis. Only, we could make it configurable so that it didn't happen on read-only operations. All of this would be ORM / database layer agnostic, which would be very nice indeed. All this is to avoid a try-commit block in the controller method or model function? Is it really that important? Is this what Noah means by controlling transactions? The normal Pylons strategy is to clear the SQLAlchemy session in the base controller before calling the action method. This is effectively a rollback, but since all the changes are in memory and haven't been compiled to SQL yet, no rollback is necessary. Users do sac.session.flush() to write their changes to the database, which is essentially a commit. I'm more comfortable with that happening explicitly in the controller method rather than vaguely in some middleware (especially since the application is not supposed to know or care whether a certain middleware is active). As for direct SQL statements in SQLAlchemy, I just assume they're autocommit. Maybe someday I'll have to get more sophistocated about them. The big issue for me with SAContext right now is that it uses a BoundMetaData and expects you to know your dburi up-front as it were. I don't like having my model tied to my configuration system. I'd rather have my model fetch its configuration from some third party source, such as this new package we are discussing, so that I can create desktop applications, command line utilities, etc. that share my pylons application's model, without having to ship pylons or a pylons configuration file. The last thing that Ian requests here would let me do that to a certain extent: from db_buffet_api import config from sacontext import SAContext sac = SAContext(dburi=config.dburi) If that's all you want, it already does this. SAContext requires an explicit URI and options as arguments, and doesn't know about anybody's configuration system. My hope is that it will be included in SQLAlchemy at some point, for many diverse applications. PylonsSAContext addresses the needs Pylons users have right now: a standard way to configure an engine/metadata/session that's better than pylons.database. The overriding concerns are: - Correctness per SQLAlchemy's recommendation (which favors BoundMetaData, even though the SQLAlchemy manual hasn't gone that far yet). - Easy for users to put into their model (just a couple short lines of code). - Automatically reads all engine options from the config file that can be specified in a scalar format. - Accepts other engine options from the developer which can't be expressed in a scalar format. If your concept requires something different than PylonsSAContext, perhaps a different subclass, there's no reason the two can't live side by side. The model is tied to the configuration such that you can't import it standalone, at least if you follow the SAC_Demo example. Instead you have to use the module under paster shell, paster setup-app, or manually prepare the environment for the import (which is not well documented but websetup.py gives some hints). This is *no worse* than existing Pylons usage, which also has the same limitation. We have thought long about how to improve this but have not come up with a better way. Some people put all their tables in an init function in the model so that it can be called sometime after the actual import, and with arguments. This is a little better in some ways but still not a robust solution. Do you set global variables for the tables or pass them back as the return value? Either way is messy. Of course the engine must be initialized before any tables can be defined or any work done. SAContext initializes the default engine in the constructor. Is there a need to push that back to some later stage? Which stage? Or can Ian's ideal wrapper simply delay creating the 'sac' until it has to? -- Mike Orr [EMAIL PROTECTED]
Re: Turbogears now based on Pylons!
On 6/27/07, Jonathan LaCour [EMAIL PROTECTED] wrote: Okay, I am mostly with you, but then you end up with a lot of boilerplate elsewhere wherever you start a transaction and throw it into the manager. I think we can address this in the TurboGears pylons template somehow and automatically start a transaction and put it into the manager on request by request basis, and provide some way to disable it for read-only requests. There have also been discussions of allowing you to turn it off for specific HTTP methods, so you would never have a transaction for GET unless you created it yourself, but POST, DELETE, etc. would usually have transactions. This feels a touch too magical to me, since the whole point of the automatic transaction-per-request in TurboGears was to make things easy by default, and not difficult to understand. I wouldn't have a problem if there were two separate pieces of middleware though: one for rolling back active transactions on exceptions, and another for setting up when you want those transactions to be created automatically. It sounds like Pylons and TurboGears have very different paradigms about how transactions are handled. Could somebody explain them side by side, showing how the controller method interacts with the middleware under various read-only, write-commit, write-rollback scenarios? Especially taking into account the various reasons one might want to roll back. As a starting point, i tried to explain the typical Pylons usage in my previous email. Then we can see whether SAContext or something else can meet all the needs. -- Mike Orr [EMAIL PROTECTED] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Turbogears now based on Pylons!
It sounds like Pylons and TurboGears have very different paradigms about how transactions are handled. I can't do a side-by-side comparison, because I am not 100% clear on an example of the right way to handle transactions in Pylons. But I can describe what TurboGears 1.0 does. TG currently has an automatic transaction per request feature, which is very widely used. If a request fails for any reason, at any point the exception is propigated out, and causes a transaction rollback. We want to set up the transaction as early as possible. So that if you have validators which hit the DB (which many do) and you want that wrapped in a transaction that is done for you. And this is important because you can't do that in the controller method itself since validation happens in the decorator -- before you enter the controller method itself. And we want the transaction closed as late as possible so that if your internationalization fails or some other post controller action fails, you can rollback the transaction. Of course the problem with the current implementation of this feature is that all kinds of pages which don't actually change anything get transaction overhead that they don't need. So we are looking for the best way to control transactions on a per controller basis. --Mark Ramm --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
fyi
http://www.oreillynet.com/onlamp/blog/2007/06/python_web_application_framewo.html -- http://www.blog.noahgift.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Turbogears now based on Pylons!
On Wednesday 27 June 2007, Mark Ramm wrote: It sounds like Pylons and TurboGears have very different paradigms about how transactions are handled. I can't do a side-by-side comparison, because I am not 100% clear on an example of the right way to handle transactions in Pylons. But I can describe what TurboGears 1.0 does. TG currently has an automatic transaction per request feature, which is very widely used. If a request fails for any reason, at any point the exception is propigated out, and causes a transaction rollback. We want to set up the transaction as early as possible. So that if you have validators which hit the DB (which many do) and you want that wrapped in a transaction that is done for you. And this is important because you can't do that in the controller method itself since validation happens in the decorator -- before you enter the controller method itself. And we want the transaction closed as late as possible so that if your internationalization fails or some other post controller action fails, you can rollback the transaction. Of course the problem with the current implementation of this feature is that all kinds of pages which don't actually change anything get transaction overhead that they don't need. So we are looking for the best way to control transactions on a per controller basis. And on that note: if you're using SA with TG, SA issues a rollback on every transaction that is not an insert or update. So if you're having a stored procedure (which you trigger with select * from stored_proc() and that stored procedure actually does updates or inserts, you're going to lose changes - simply because SA issues a rollback on Select statements. Quick fix for this is to modify SA to just issue a commit on every statement, so the TG transaction can roll back or commit without being affected. IMHO issuing a commit on a select shouldn't be more overhead than issuing a rollback - because the db should know what to do (in this case nothing) Maybe something to think about too, because I can't be the only one making heavy use of stored procedures (which are far more efficient than controller/model side code) Uwe -- Open Source Solutions 4U, LLC 1618 Kelly St Phone: +1 707 568 3056 Santa Rosa, CA 95401 Cell: +1 650 302 2405 United States Fax:+1 707 568 6416 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Turbogears now based on Pylons!
I hadn't heard of DejaVu until now. One issue with SQLAlchemy is connect/rollback are buried in the SQL and ORM APIs, so I'm not sure how useful it would be to shoehorn them into this API which is out of band from the controller code. just to clarify, not really. the entire point of the explicit connection API, which 99% of the time people either arent aware of, or find it to be too verbose when they see it, is that the transaction going on can be completely extracted to be external to everything SQLAlchemy. if we are looking for an ORM-agnostic API that just wraps all internal operations in a transaction, the SAContext need not even be involved, youd use SessionTransaction against its current session. Also SAContext has no dependence on bound metadata as it supports alternative strategies which define the usage of engines, and that it takes the database URI in its constructor is just a small implementation detail thats easily changed. Bound metadata in its old sense no longer exists in SQLAlchemy, as all metadata objects can have a new Engine assigned to them at any time (or not at all). Is this a full-request transaction the controller is expected to use? Can we assume that every controller has no more than one transaction, and that rollback always corresponds to certain HTTP status codes? it seems we are talking about just the case where, the entire request is inside of a transaction, and it seems like this is mainly for the purposes of WSGI middleware...having any fine-grained access to the ORM in an agnostic way (i.e. anything beyond define connection parameters and transaction boundaries) would be unworkable. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Firefox XUL and pylons
I never actually put an egg together for the demo hack as it was just a simple proof of concept and doesn't have any db stuff either. If you want to have a look at it anyway you can download the source here:- http://www.microshare.net/downloads/xuldemo.tar.gz If you'd like to work on something more robust I'm open to the idea. Uwe. Jose Galvez wrote: Any chance you would share the actual code for the demo? maybe share the actual egg? I'd love to see it Jose --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Turbogears now based on Pylons!
On Jun 27, 8:24 pm, Uwe C. Schroeder [EMAIL PROTECTED] wrote: And on that note: if you're using SA with TG, SA issues a rollback on every transaction that is not an insert or update. So if you're having a stored procedure (which you trigger with select * from stored_proc() and that stored procedure actually does updates or inserts, you're going to lose changes - simply because SA issues a rollback on Select statements. this issue can be worked around by using explicit transactions. i also have a notion of SQL functions being marked as transactional to help this issue. but this thread so far seems to be about the notion of an entire request being marked as transactional, which as it turns out is a central concept of J2EE and others, which would also eliminate the issue youre having. Quick fix for this is to modify SA to just issue a commit on every statement, so the TG transaction can roll back or commit without being affected. IMHO issuing a commit on a select shouldn't be more overhead than issuing a rollback - because the db should know what to do (in this case nothing) this would be something that would need to be benchmarked. i do think it would add some overhead. but beyond that, i dont like the idea of unnecessary COMMITs for every SELECT statement at all. Maybe something to think about too, because I can't be the only one making heavy use of stored procedures (which are far more efficient than controller/model side code) that a stored-procedure-oriented application is far more efficient is *extremely* debatable and database-dependent as well. if you really want COMMIT for every SELECT, i'd favor it being enabled via an option passed to create_engine(). Beyond that I think the model implemented as stored procedure style of development is much in the minority these days, particularly within the lightweight/open-source development community. just that the stored procedure changes the semantics of SELECT to be a write operation reminds me of the RESTful sin of using GET to post data. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Turbogears now based on Pylons!
On Jun 27, 6:42 pm, Ian Bicking [EMAIL PROTECTED] wrote: The way I see this working is something like (vaguely): def transaction_middleware(app): def wrapper(environ, start_response): manager = TransactionManager() environ['transaction.manager'] = manager try: app_iter = app(environ, start_response) except: manager.rollback() raise else: manager.commit() The manager is basically a container of *actual* transactions, and calling rollback or commit on it gets passed on to all the transactions in the manager. this is fine. we're *really* starting to imitate J2EE in some ways. but its not a bad thing. If you don't do anything that needs a transaction (e.g., read-only), you shouldn't put your transaction in the manager. just to clarify, however this works, it should be *really easy* for individual controller methods to be marked as transactional or not. I have written decorators like these already, in the style of: class MyController(...): def index_page(self): . @transactional def post_message(self): . def display_message(self): . so id want that kind of thing to be readily available, i suppose it would communicate with the WSGI middleware on a per-request basis. but another thing i like, is that of the response to the request being delivered *after* the transaction commits. i have raised this issue on the pylons list before but i dont think i impressed anyone. if you render your response template, then your transaction fails, you have the potential for that response template to still be delivered with the success! message. anyway, might be nice for the middleware to address this if possible. also i think this is all outside of the scope of SAContext. SAContext should remain as a facade to SA-specific elements; it can accept strategy objects which control its internal workings, so if need be particular strategies can be delivered in order to function with the transaction manager, without changing the external view of SAContext. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Turbogears now based on Pylons!
On Jun 27, 7:44 pm, Mike Orr [EMAIL PROTECTED] wrote: The normal Pylons strategy is to clear the SQLAlchemy session in the base controller before calling the action method. This is effectively a rollback, but since all the changes are in memory and haven't been compiled to SQL yet, no rollback is necessary. theres a rollback() going on ; SQLAlchemy's connection pool issues a rollback() on all connections before theyre returned to the pool. this is to release any locks that might be present on the connection (and its definitely quite necessary...unless we went with the COMMIT on every statement/connection returned idea someone has mentioned). Of course the engine must be initialized before any tables can be defined or any work done. since ive seen people get the wrong idea about this, let me reiterate: *you can define all your tables and mappers with no database connection defined whatsoever*, and you can even start creating mapped objects. SQLAlchemy does not care a whiff about your database connection until the moment you tell it to execute a SQL statement...and when the statement is done, it goes back to not caring at all about your database connection; you can tear it down or modify it to be something else all you like. SAContext initializes the default engine in the constructor. Is there a need to push that back to some later stage? Which stage? Or can Ian's ideal wrapper simply delay creating the 'sac' until it has to? easy enough to make uri optional in SAContext (the way it is for everything else in SA) and just allow binding it later via add_engine() or whatever. SAContext is designed the way it is right now because Pylons defines the default engine in the .ini file; theres no need for a delayed connection in the usual case. im not exactly sure why Jonathan thinks that the url forces one to define my connection up front. if youre saying, i want to distribute the application without an .ini file thats fine...but when the thing is actually *used*, there will be an .ini file or other configuration defined when things run. if you want to define your model independently of connection, just use an empty MetaData. Set up the SAContext to bind the engine or individual connections to the session instead...or give it your MetaData for it to bind when youre ready. theres really nothing to it. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Turbogears now based on Pylons!
On Wednesday 27 June 2007, Michael Bayer wrote: On Jun 27, 8:24 pm, Uwe C. Schroeder [EMAIL PROTECTED] wrote: And on that note: if you're using SA with TG, SA issues a rollback on every transaction that is not an insert or update. So if you're having a stored procedure (which you trigger with select * from stored_proc() and that stored procedure actually does updates or inserts, you're going to lose changes - simply because SA issues a rollback on Select statements. this issue can be worked around by using explicit transactions. actually no, it can't. Maybe I don't get it right, but the only way for me to get a commit was actually to modify Connection._autocommit in sqlalchemy.engine.base. Obviously SA thinks there is no transaction in TG, so it just wraps one around it. After I got tired of searching for the problem I just added SELECT to the above method and now get my commit. I'm sure either I do something wrong or there's a bug in the db implementation of TG. All I could find is that the transaction (since 1.0.2 available in tg.sa_transaction) is just a subtransaction from the autocommit code - thus when the outer transaction issues a rollback the inner transaction that was committed will be rolled back too. i also have a notion of SQL functions being marked as transactional to help this issue. but this thread so far seems to be about the notion of an entire request being marked as transactional, which as it turns out is a central concept of J2EE and others, which would also eliminate the issue youre having. Yes - see below on the every select statement. Quick fix for this is to modify SA to just issue a commit on every statement, so the TG transaction can roll back or commit without being affected. IMHO issuing a commit on a select shouldn't be more overhead than issuing a rollback - because the db should know what to do (in this case nothing) this would be something that would need to be benchmarked. i do think it would add some overhead. but beyond that, i dont like the idea of unnecessary COMMITs for every SELECT statement at all. I agree, and that is certainly DB dependent. Personally I can't imagine that an automatically issued rollback for every select transaction is in any way more overhead than issuing a commit. Not wrapping a select in a transaction will definitely be the least overhead. Maybe something to think about too, because I can't be the only one making heavy use of stored procedures (which are far more efficient than controller/model side code) that a stored-procedure-oriented application is far more efficient is *extremely* debatable and database-dependent as well. I doubt it's *extremely* debatable. Just issue 100 inserts from inside a stored procedure (or 100 updates) and do the same discretely with any kind of db interface. In case of the interface every statement has to be parsed by the db, whereas in a stored procedure the statement is already compiled of sorts (at least Oracle and PostgreSQL do that). I had cases where moving the application code (standard DBAPI calls, no ORM) to a stored procedure reduced the execution time from 27 seconds to 2 seconds without changing the database structure (ok, extreme case, but handling 1500 inserts discretely in the application is just a lot of remote overhead, particularly when the requests come over the network where you get an extra delay for network operations) if you really want COMMIT for every SELECT, i'd favor it being enabled via an option passed to create_engine(). Not every select, every transaction that didn't roll back. I just think the default of rollback on every transaction is wrong - a rollback should occur when there is a problem, not when the transaction was fine. But that may just be me. Beyond that I think the model implemented as stored procedure style of development is much in the minority these days, particularly within the lightweight/open-source development community. just that the stored procedure changes the semantics of SELECT to be a write operation reminds me of the RESTful sin of using GET to post data. Probably because a lot of people can't figure out how to use stored procedures and triggers, since the lightweight/open-source programming is often done on a database that has very limited support for both :-) Personally I'm not a big fan of handling database integrity outside the database. Take a simple portal as example, where every new user who signs up gets a couple of mailboxes by default (inbox, outbox,drafts,trash). I could handle that in the db structure itself, but that would make the db model overly complicated for such a simple thing. The proper way is to handle that in a trigger, or I can handle it in a stored procedure that just makes sure the mailboxes are created. In my case I chose a stored procedure because it's actually a select on the user's profile, but the stored procedure also
