Re: pyjamas + pylons
Easy to work with is questionable when the first thing you encounter is an error during easy install of pyjamas. The menu widget displays incorrectly when you scroll the page (a basic widget and pretty much unusable) and there is no rich text editor. AFAIK no one is using pyjamas for a production site. There is almost no active development or community. The documentation is lacking (to say the least). So there is a lot of potential but this project still needs a lot of work to be usable for production, unless you want to deal with all the issues yourself. On Feb 6, 5:31 am, Jim Washington jwas...@vt.edu wrote: lkcl wrote: [ a lot of good stuff] FWIW, here's another few cents about pyjamas, gleaned from using it for a couple of weeks. I found Ian Bicking's JSON-RPC example a good starting point for doing the rpc stuff with pyjamas and repoze.bfg, so I imagine it will work similarly well in pylons.http://pythonpaste.org/webob/jsonrpc-example.html If you want to use all the batteries included with python, you need to use that code server side. Protect your rpc methods with authentication, authorization and XSS safeguards. For auth/auth, repoze.who/what are definitely usable. The html that pyjamas/GWT generates tends to use table-based layout, very ugly for those of us trying to get away from that. But it is liberally sprinkled with uniformly-named class attributes, so styling can still be done with css. If you think user interface rather than web page, this is really not too bad a way to go. In pyjamas, you can maybe use your favorite external javascript libraries. Sometimes it is as easy as import thatotherlibrary.js Then, if thatotherlibrary exposes a function fribble, you can use it in a python function or method def xfribble(obj1,obj2): JS(return fribble(obj1,obj2);) Several python syntactical constructs are not currently available in pyjamas. At compile time, pyjamas will tell you if you do something it cannot handle. Generally, if you keep your python code simple and readable, it will work fine. Compiling is pretty fast. pyjamas does not currently minimize or obfuscate its output javascript, so your javascript debugger will give you fairly useful hints about what might be going wrong. Fix your python code, recompile, try again. The widget set available in pyjamas is pretty basic. You can compose fancier widgets from the basic ui objects. You can also snoop in the various libraries folks have built for GWT, and rewrite the java code in python, if you do not want to reinvent the wheel too much. I have not seen anything easier to work with to generate a complex user interface for a web app. Any widget can request data from the server and handle the response. This is a very nice way to make things happen. - Jim Washington --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: storing formattable strings in the config file?
maybe foo \x25(bar)s On Feb 6, 11:11 am, Jonathan Vanasco jonat...@findmeon.com wrote: i want to store something in my config file like foo %(bar)s normally in python, i would do this foo %%(bar)s to escape the string interpolation. paste doesn't like that. anyone have a suggestion. --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: beaker_cache query_args when duplicate queries are in
yes, you're right it's totally weird that the key beaker_cache uses for caching controller actios, doesn't include the action in it by default. My solution was to write my own decorator. On Feb 6, 1:52 pm, eleith ele...@gmail.com wrote: i've got a controller that will accept multiple same name args in the query string ?id=10id=100id=50 it looks like beaker_cache does not interpret these as different query strings, so ?id=10id=100id=50 will return the same as ?id=10id=100id=20id=50 any recommended workarounds for this? on a tangential note, does beaker_cache support keying on a controllers 'action' as well as a 'query_arg' ? --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: appcelerator anyone?
while i havent looked closely at appcelerator, I am impressed with the vision and knowledge that the creators seem to have about building rich internet applications and the emphasis on client side code. Again, this doesn't mean I think this is a good framework, certainly it doesn't seem to be a very popular or well known one (the community is practically non existent). On Feb 4, 9:06 pm, Kumar McMillan kumar.mcmil...@gmail.com wrote: On Wed, Feb 4, 2009 at 3:28 PM, Iain Campbell i...@kandaba.com wrote: I'm building an intranet on Pylons and Appcelerator at the moment - very impressed. A bit pointless for a public facing site tho due to validation issues.. validation, as in, security of how it does the message passing? -- www.kandaba.com web | iptv | mobile development consultancy t: +44 (0) 203 051 7792 m: +44 (0) 7815 821 678 gtalk: i...@kandaba.com On 4 Feb 2009, at 20:06, Kumar McMillan kumar.mcmil...@gmail.com wrote: Has anyone played around with Appcelerator? http://doc.appcelerator.org/overview/index.html http://appcelerator.org/ Kind of mega but still a neat idea, especially how you can pass messages transparently from JavaScript to the server and back. Looks like the Python web backend is built on Pylons: http://doc.appcelerator.org/get_started/python/ directory_structure.html Kumar --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Pylons on CYGWIN
For people developing on Windows, Cygwin is a valuable tool, but beyond having access to unix shell utilities, you can also install some advanced software packages on Cygwin, like Python, Ruby, SQLite, etc. In fact it's possible to install Pylons and use that instead of using the regular windows Python installation. Does anyone have any experience with this kind of setup ? I assume the performance would be bad since most apps running on Cygwin are slow (possibly due to the overhead of linux-windows system call translation) --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Pylons vs Tomcat+GWT
AnonymousGuy wrote: ..You do seem pretty intent on using GWT, no matter what advice is offered in this thread... I listen to advice from many different sources, and the advice in this thread ranks pretty low in its usefulness compared to the whole range of opinions that exist. Javascript libraries suck because the developer still needs to use the retarded java-crypt language which would be excutiating to develop any real application logic with. Productivity, development tools, debugging, componentization, reusability, rich libraries, high level algorithms and data structures, type safety, compile time optimizations are all huge advantages of Java compared to java-scrap-it ;-) http://www.ryandoherty.net/2007/04/29/why-google-web-toolkit-rots-your-brain/ On Feb 2, 11:50 pm, Dalius Dobravolskas dalius.dobravols...@gmail.com wrote: On Tue, Feb 3, 2009 at 3:12 AM, Colin Flanagan quadvill...@yahoo.comwrote: Does anyone have that link? Looks like this one:http://ejohn.org/blog/javascript-language-abstractions/ I must note that it is worth to read almost everything what is written by John Resig. -- Daliushttp://blog.sandbox.lt --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Pylons vs Tomcat+GWT
sure but without client side code, it will have to reload a new page in response for each user interaction Rich Internet Applications rely on client side code to be as powerful as desktop app, and GWT facilitates that in a more comprehensive way than the simple javascript code snippets, or javascript libraries On Feb 1, 10:55 am, Michael Bayer mike...@zzzcomputing.com wrote: On Feb 1, 2009, at 12:19 AM, Tycon wrote: I'm not talking about facebook/youtube type sites, I'm talking about a real web application where users access information, enter information, search and analyze information, and visualize information. which one of those is not supplied by facebook ? --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Pylons vs Tomcat+GWT
The point of GWT is that you can use java for the client side code, with most of its core libraries, and you get better optimized javascript, and much better development environment and tools (IDE, debugger). This is superior compared to using any javascript framework, none of which offers the comprehensive high level libraries that java provides. On Jan 31, 2:20 pm, MilesTogoe miles.to...@gmail.com wrote: Tycon wrote: I'm planning on using GWT only for client side code and doing all server calls using JSON, and not using GWT's RPC mechanism. So I guess that would avoid the problem you are talking about ? Correct me if I'm wrong, but neither Perl/CGI not Pylons/Rails etc CANNOT be used to create a gmail-like application, unless you resort to hand writing the entire UI (which runs wholly on the client) in javascript (good luck with that !). you are way off here - it is quite doable to create a nice GUI with Rails (or Pylons or Werkzeug or ...) and use Prototype or add in some jQuery (or your js framework of choice) for fast client side actions. Just look at some of the 37 Signals apps - but if you want to use GWT that's fine, your choice. --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Pylons vs Tomcat+GWT
because it's not ready so it's just a toy at this point, just like pyjamas, while GWT is used by real production websites (ever heard of gmail) On Jan 31, 5:54 pm, Alberto Valverde albe...@toscat.net wrote: Tycon wrote: The point of GWT is that you can use java for the client side code, with most of its core libraries, and you get better optimized javascript, and much better development environment and tools (IDE, debugger). This is superior compared to using any javascript framework, none of which offers the comprehensive high level libraries that java provides. Why write Javascript in Java when you can do it in Ruby? Make sure you check out HotRuby:http://hotruby.yukoba.jp/ Alberto --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Pylons vs Tomcat+GWT
I'm not talking about facebook/youtube type sites, I'm talking about a real web application where users access information, enter information, search and analyze information, and visualize information. I'm not creating web sites for popularity contests, but using the web as a platform for real software applications that provide an actual (business) service. For that it's much better to use more client side (e.g. javascript) code to make it seem like a real desktop app. If you just want to create some flicker slideshow derivative, then yes you can use php or whatever other server side application code. On Jan 31, 8:25 pm, Michael Bayer mike...@zzzcomputing.com wrote: On Jan 31, 2009, at 4:28 PM, Tycon wrote: I'm planning on using GWT only for client side code and doing all server calls using JSON, and not using GWT's RPC mechanism. So I guess that would avoid the problem you are talking about ? or you could just use jquery...ive no idea how you'd use only the client side portion of GWT. from what I could tell it seemed like the entire server-to-client is spit out from a single monolithic compilation and there was certainly no easy way to just use the client. Correct me if I'm wrong, but neither Perl/CGI not Pylons/Rails etc CANNOT be used to create a gmail-like application, unless you resort to hand writing the entire UI (which runs wholly on the client) in javascript (good luck with that !). i think there are alternatives which would result in easier to read code. jquery can go a very long way. were written using GWT-like technology, and IMO google apps are the best example of smart efficient next generation web apps. theyre tremendously complex and reliant upon special build tools. facebook AFAIK is just php and is a more compelling client side experience than anything I've seen google do. --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Pylons vs Tomcat+GWT
Is there a Rails-like framework for Java ? On Jan 30, 9:54 am, Jonathan Vanasco jvana...@gmail.com wrote: Java can take 10-20x longer to develop and manage than php / perl / python / etc. When you factor in rapid/agile frameworks like Pylons, Rails, Django, Catyalyst, Cake, etc the differences are even larger. You /can/ do whatever you want in Java; fun projects, startups, small businesses typically don't use it, because its too damn human- resources intensive. --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Pylons vs Thundercats
How many request per seconds can the thundercats serve ? On Jan 30, 11:19 am, Mike Orr sluggos...@gmail.com wrote: On Fri, Jan 30, 2009 at 11:00 AM, kai kai.keliik...@gmail.com wrote: You can't really draw comparisons between pylons and thundercats. Pylons and He-Man is an entirely different matter. I think Mako could take Skeletor. Thundercats are one of those action figure/TV products? I thought it was a corruption of Tomcat. -- Mike Orr sluggos...@gmail.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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Pylons vs Thundercats
Cool cast ! Looks like Wolverine left the X-Men to join the ThunderCats ? On Jan 30, 11:37 am, Walter Cruz walter@gmail.com wrote: Pylons don't have a cool movie like that:http://www.youtube.com/watch?v=fb50GMmY5nk On Fri, Jan 30, 2009 at 5:29 PM, Tom Longson (nym) toml...@gmail.com wrote: On Fri, Jan 30, 2009 at 11:26 AM, Tycon adie...@gmail.com wrote: How many request per seconds can the thundercats serve ? Old thundercats or new thundercats? -- []' - Walter waltercruz.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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: best ways to deal with bool values in config ?
I was just responding to other people's posts, and I'm not the only person to ever criticize python (while still acknoledging its strengths). On Jan 23, 1:45 am, Alberto Valverde albe...@toscat.net wrote: Mike Orr wrote: On Thu, Jan 22, 2009 at 9:43 PM, Tycon adie...@gmail.com wrote: Python is so messed up, the only explanation is that the people making it up are blindly following misguided principles. Since it's so easy to make a web framework in Python, why don't you make your own and then you won't have to suffer the egregious mistakes of such braindead developers. You can also design your own programming language while you're at it. As his/her google groups profile [1] clearly shows (anonymous nickname, high trolling/signal ratio in a short posting history, bold claims with little or no backing, anonymous gmail account created for the only purpose of displaying behavior that his/her mother wouldn't be proud of...) we're in front of yet another mailing list troll. Unfortunately, it has just recently begun spreading to other Python webdev mailing lists... I believe it's better to stop feeding his/her trollish posts (I for one find it quite hard) and instead focus on the posts where he/she adds some value; or just plainly ignore them. To put casual lurkers on the right track when they reach the archives through a search engine, trollish posts can be answered with something like: This post remains unanswered not because the claims made are not disputable but because this individual is known to occasionally display trollish behaviour: link to his post history. Please refrain from feeding, it'll get stronger. Just an idea. Alberto [1]http://groups.google.com/groups/profile?enc_user=ldNXFBEvm8YnL9Uo... --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: best ways to deal with bool values in config ?
This is another example of the flawed, broken code known as Paste. Pylons should decouple itself from Paste On Jan 22, 12:11 pm, Mike Orr sluggos...@gmail.com wrote: On Wed, Jan 21, 2009 at 4:30 PM, Jonathan Vanasco jonat...@findmeon.com wrote: i store a lot of stuff in config, much of which is 'framework' related across modules. the current way i deal with bools is this ( by storing things in app_globals during init ) g.enable_feature_x= False if 'org.opensn.pylons.enable_feature_x' in config: g.opensn_pylons.enable_feature_x = bool(int(config ['org.opensn.pylons.enable_feature_x'])) is there a better way ? I have a custom function in load_environment that chnages the config var types and aborts if it can't, checks for required vars, and sets defaults for optional ones. However, it has since occurred to me that this would be a good job for a FormEncode schema, although you'd need some workaround for the dotted variable names, and meaningful error messages (variable X in the [app] section of /a/b/c/development.ini must be numeric). I do think this should all be done in load_environment rather than ad hoc whenever the value is used, because not only does that keep parsing all in one place, but it prevents the application from crashing in possibly obscure situations. -- Mike Orr sluggos...@gmail.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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: best ways to deal with bool values in config ?
I would gladly throw python away if only ruby matched its performance. On Jan 22, 3:48 pm, Wyatt Baldwin wyatt.lee.bald...@gmail.com wrote: On Jan 22, 1:14 pm, Tycon adie...@gmail.com wrote: This is another example of the flawed, broken code known as Paste. Pylons should decouple itself from Paste But Pylons, as you've pointed out, is flawed in numerous ways as well. Let's throw it *all* away! --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: python -3 switch
The easiest way to use any specific version of python (and any options you need) is to explicitly invoke the python executable from the shell (e.g. bash), for example: $ python2.6 -3 $(which paster) serve development.ini On Jan 22, 4:20 am, Gustavo Narea m...@gustavonarea.net wrote: On Thursday January 22, 2009 13:05:47 Jorge Vargas wrote: On Thu, Jan 22, 2009 at 5:59 AM, przemek.ch przemek...@gmail.com wrote: Hi, python 2.6 has a switch -3 which will show warnings about code that is not compatible with python 3 is ther a way to use tis switch with pylons? pylons don't use python directly and there's no such switch for paster many of pylons dependencies do not yet work on py3k therefore pylons itself still doesn't works there. that said we do run on 2.6. the simplest way I see of doing that is to change the shebang line of the paster command, which should be in $ENV/bin/paster, where ENV depends on your system and/or if you are using virtualenv. $ which paster will tell you. A work-around is to run your test suite with that switch (`python -3 setup.py test`). But of course, this won't be effective in projects that don't have a decent code coverage. Cheers. -- Gustavo Narea http://gustavonarea.net/. Get rid of unethical constraints! Get freedomware:http://www.getgnulinux.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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: best ways to deal with bool values in config ?
C is my expertise, but it can't match the productivity of python or Ruby Fortnately for C, it will always retain the performance crownm so it will always have its uses The same thing cannot be said for python. Once its performance is once its performance is matched by a better language such as Ruby, python will be history. Python is so messed up, the only explanation is that the people making it up are blindly following misguided principles. The biggest lie/joke is that there is only one way to do something in python On Jan 22, 9:21 pm, Wyatt Baldwin wyatt.lee.bald...@gmail.com wrote: On Jan 22, 8:21 pm, Tycon adie...@gmail.com wrote: I would gladly throw python away if only ruby matched its performance. There's another option you may be interested, in case you haven't heard of it: C. It's *very* fast. On Jan 22, 3:48 pm, Wyatt Baldwin wyatt.lee.bald...@gmail.com wrote: On Jan 22, 1:14 pm, Tycon adie...@gmail.com wrote: This is another example of the flawed, broken code known as Paste. Pylons should decouple itself from Paste But Pylons, as you've pointed out, is flawed in numerous ways as well. Let's throw it *all* away! --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: RegistryMiddleware is a major overhead
empirical data is that if you comment out the RegistryManager in config/middleware.py, you get much better req/sec (but you cant use any of the gloabals...). In fact, isn't the whole purpose of this registry facility to enable request-local objects (such as the request object) to be accessed as globals (e.g not having to pass them as arguments to the action) ? So to support a bad programming paradigm (using globals) the solution is to have another inefficient layer to make sure accessing those globals doesn't cause any scoping and synchronization issues ??? Why not just get rid of the bad paradigm ? In Pylons 2 all pertinent information about the request would be passed to the user's action method as explicit arguments. On Jan 20, 11:37 am, Ian Bicking i...@colorstudy.com wrote: On Tue, Jan 20, 2009 at 11:36 AM, Ben Bangert b...@groovie.org wrote: Similarly, other request handling operations such as creating the request object may also be redundant, because the user may not be interested in all the attributes of the request object. So wouldn't it be better to provide those things on-demand (that is using a call interface to get things such as params, etc) instead of creating all that stuff by default even when it may not be needed ? Sure, and its possible some other things in webob.Request might be more lazily done, though at the moment, most every attribute on it only actually does its work upon access. If you can see any specific locations in it that may be further optimized, that'd be great. If anyone does put together something to target webob performance specifically, that'd make the webob optimization happen a lot faster ;) Instantiation *shouldn't* be slow (I can't say for sure if that's true, but if it's not I'll want to fix that). And probably there's some features in Request that should actually be taken out (like environ_getter), that might be causing some overhead. But I'd rather work from empirical data, and I haven't gotten around to putting that together. -- Ian Bicking | http://blog.ianbicking.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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
RegistryMiddleware is a major overhead
Benchmarks indicate it is taking as much as 20% of request handling time (not including the user action). The question is why is it even necessary to use this registry facility ? Similarly, other request handling operations such as creating the request object may also be redundant, because the user may not be interested in all the attributes of the request object. So wouldn't it be better to provide those things on-demand (that is using a call interface to get things such as params, etc) instead of creating all that stuff by default even when it may not be needed ? --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: FormEncode and i18n
pylons has an ugly hack to make form encode translations work - by
using the PylonsFormEncodeState which has a translation method as
attribute, as the default state object. So in effect if you try to
use a different state object, then translations won't work.
On Jan 17, 10:25 am, mickolka mpaliye...@gmail.com wrote:
I got the problem here is a bug report to the formencode
trackerhttps://sourceforge.net/tracker/?func=detailatid=596416aid=2515640;...
The cause of such a strange behaviour was
from xml import xpath
after you do it - set_stdtranslation stop work and always return
English
On Jan 13, 7:21 pm, mickolka mpaliye...@gmail.com wrote:
Hi,
I have a different problem with pylons andformencodei18n
when I run the following code in console
importformencode
ne
=formencode.validators.NotEmpty()formencode.api.set_stdtranslation(language
s=[de])
try:
ne.to_python()
exceptformencode.api.Invalid, e:
print str(e)
I get printed
Bitte einen Wert eingeben
when I do in inside a controller I get printed
Please enter a value
What can be the problem with it?
my easy_install.pth file is
import sys; sys.__plen = len(sys.path)
./Mako-0.1.8-py2.5.egg
./nose-0.10.1-py2.5.egg
./decorator-2.2.0-py2.5.egg
./PasteScript-1.3.6-py2.5.egg
./PasteDeploy-1.3.1-py2.5.egg
./AuthKit-0.4.0-py2.5.egg
./elementtree-1.2.7_20070827_preview-py2.5.egg
./python_urljr-1.0.1-py2.5.egg
./python_yadis-1.1.0-py2.5.egg
./python_openid-1.2.0-py2.5.egg
./Babel-0.9.2-py2.5.egg
./paginate-0.3.2-py2.5.egg
./sqlalchemy_migrate-0.4.3-py2.5.egg
./Elixir-0.5.2-py2.5.egg
./Beaker-0.9.3-py2.5.egg
./Routes-1.8-py2.5.egg
./SQLAlchemy-0.4.5-py2.5.egg
./pytils-0.2.2-py2.5.egg
./logging-0.4.9.6-py2.5.egg
./xlrd-0.6.1-py2.5.egg
./dateutil-1.1-py2.5.egg
./pytz-2008b-py2.5.egg
./pygooglechart-0.2.0-py2.5.egg
./PyYAML-3.05-py2.5.egg
./setuptools-0.6c8-py2.5.egg
./Paste-1.7.1-py2.5.egg
./geopy-0.93-py2.5.egg
./WebOb-0.9.2-py2.5.egg
./flup-1.0.1-py2.5.egg
./bsddb3-4.7.2-py2.5-macosx-10.5-i386.egg
./simplejson-2.0.4-py2.5-macosx-10.5-i386.egg
./WebHelpers-0.6.4-py2.5.egg
./clonedigger-1.0.9_beta-py2.5.egg
./FormBuild-0.1.6b-py2.5.egg
./FormEncode-1.0.1-py2.5.egg
./Pylons-0.9.6.1-py2.5.egg
import sys; new=sys.path[sys.__plen:]; del sys.path[sys.__plen:];
p=getattr(sys,'__egginsert',0); sys.path[p:p]=new; sys.__egginsert = p
+len(new)
Also some time ago there were no problems with it, probably it is
somehow related to our switch to newer webhelpers
Thanks in advance for any help.
Mykola
On Nov 20 2008, 9:28 am, Dalius Dobravolskas
dalius.dobravols...@gmail.com wrote:
Hi,
I'm having some troubles withFormEncodeand internationalization.
What I'm trying to do is to make FE to display properly translated
messages for those form fields that are not valid. After a lot of
trials and errors I found that (using paster shell):
formencode.api.set_stdtranslation(domain='FormEncode',
languages=['it'])
formencode.api._stdtrans('Please enter a value')
works as expected and I get the translated message. However:
pylons.decorators.formencode_gettext('Please enter a value')
gives me the original message (i.e. in english). What I don't
understand here is that in pylons/decorators/__init__.py there is the
following import statament:
fromformencode.api import _stdtrans as formencode_gettext
so calling pylons.decorators.formencode_gettext() should give the same
result as callingformencode.api._stdtrans(). But it doesn't!
It's like the former set_stdtranslation() call has no effect when I
call _stdtrans() from within pylons. But I really don't understand
what's going on here. Any help?
While it looks the same it is not:formencode.api._stdtrans
bound method GNUTranslations.ugettext of gettext.GNUTranslations
instance at 0x00C63288 pylons.decorators.formencode_gettext
bound method NullTranslations.ugettext of gettext.NullTranslations
instance at 0x00D405D0
In my opinion you shouldn't use this function directly. decorators
module exports only jsonify and validate functions. Use them.
That's how I solved validate problem:
from pylons.i18n import set_lang
class PeklaStateFactory(object):
def __call__(self):
set_lang('it')
formencode.api.set_stdtranslation(domain=FormEncode,
languages=['it'])
return None
state_factory = PeklaStateFactory()
That's how you can use state_factory with tosca widgets validate:
@validate(form=banner_form, error_handler='edit',
state_factory=state_factory)
Pylons validate should use state (not state_factory) but I have not
tested that.
--
Daliushttp://blog.sandbox.lt
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to
Re: Recommended production deployment
I installed modwsgi 2.3 and apache worker MPM and performance improved by 30% but CherryPy is still significantly faster. On Jan 13, 10:58 pm, Jorge Vargas jorge.var...@gmail.com wrote: On Wed, Jan 14, 2009 at 12:54 AM, Jorge Vargas jorge.var...@gmail.com wrote: On Tue, Jan 13, 2009 at 11:51 PM, Tycon adie...@gmail.com wrote: Im using Ubunto 8.04 LTS and running the test using ab -n 1 -c 10 to localhost, in order to focus on the request handling code in the server stack and remove or reduce the weight of all other application logic such as db access and page rendering. This is not supposed to be a realistic timing of a real world request, but a highlight of the differences in efficiency of different request handling stacks including network layer, HTTP and routing code. All software package veriosns I'm using are the versions supplied in the OFFICIAL repositores for the distribution. Pylons and cherrypy were installed using (non)easy-install so their version is the latest rather than a version tied to any official repository. http://code.google.com/p/modwsgi/downloads/listdoesn't even lists 1.x anymore as a note official debian package is 2.x http://packages.debian.org/changelogs/pool/main/m/mod-wsgi/mod-wsgi_2... now it seems ubuntu doesn't has a 2.0 package http://packages.ubuntu.com/hardy/libapache2-mod-wsgi sorry I was looking at the wrong ubuntu version it does have a 2.3 package as shown herehttp://packages.ubuntu.com/intrepid/libapache2-mod-wsgi but you are still running 1.3 as you posted above, so everything else still stands so your definitive results are totally coerced by the fact that your operating system is running outdated code for modwsgi, in other words you are running the very last version of a software with something that is almost 2 years old. And you expect us to believe it's not bias? lets run firefox 1.0 vs ie 7 today and see who is better, ummm wait bad example. But we are talking about competent projects here. I'm running in a full VM (single core) so I'm pretty sure my results are correct: CherryPy (started using paster serve prodduction.ini) is twice as fast (1300 req/sec for hello world) as Apache+modwsgi (650 req/sec). The only difference you may have is using worker MPM instead of pre-fork MPM, and newer versions of apche and modwsgi. In addition, apache is also logging the requests which is an additional overhead that pylons doesn't do in my configuration. But even so I doubt if Apache could match standalone pylons using CherryPy. On Jan 13, 8:36 pm, Graham Dumpleton graham.dumple...@gmail.com wrote: On Jan 14, 3:10 pm, Tycon adie...@gmail.com wrote: Actually I have apache+modwsgi running flawlessly, and everything I said is based on meticulous performance benchmarking and theoretical profiling of deployment architectures. All benchmarks were performed on pylons full stack production mode, with debugging and logging turned off. The test was a simple hello world page with no template rendering, database access or other external links or references. Apache is prefork MPM v2.2.8 with modwsgi 1.3 using python 2.5.2. Old version of mod_wsgi. If using daemon mode of mod_wsgi then 2.X is somewhat faster. Using embedded mode, prefork especially can stuff up benchmarking because the burst in traffic will cause Apache to create lots of additional child worker processes to handle load. Every one of those then has to load application and that can kill machine performance while occurring, interfering with benchmark results. As such, for applications with high load cost, actually better to use daemon mode with fixed number of processes and with worker MPM for Apache. Stripping Apache of unused modules that take a lot of memory, especially PHP, is also advisable. The benchmarks CLEARLY show that using a stand-alone app server is MUCH faster then using apache+modwsgi to serve a page (returned from the aforementioned hello world controller action). When using CherryPy as the HTTP server for pylons, the req/sec is almost twice as fast as apache+modwsgi. PasteHTTP is 15% slower than CherryPy but still much faster then Apache+modwsgi. Generally contrary results on MacOSX, with both CherryPy and Paste server running quite badly in comparison. On Ubuntu CherryPy runs about the same and Paste server slower. What operating system are you using? Did your tests take into consideration that Apache/mod_wsgi lazy loads application object on first request where as the others preload. This in part plays into why benchmarking results can look bad with Apache/ mod_wsgi, people are actually counting startup costs when they shouldn't. Graham But of course using a stand-alone app-server as the web-server has a few drawbacks: 1. Static files are also served by pylons, which is slow. 2. Cannot use multiple processes
Re: Recommended production deployment
I think CherryPy is awesome, much better than Paster HTTP (which cant even do HTTPS). In general I prefer to separate the web server and app server (over the embedded approach) as it is more modular, flexible and scalable. But embedded deployment has a theoretical performance advantage because there is no overhead of communication between the web and app server. The best option for embedded deployment is apache+modwsgi (but apache +mod_python or nginx+mod_wsgi also exist). Apache+modwsgi (embedded) is faster than Apache as a reverse proxy, and also outperfoms standalone CherryPy or PasterHTTP, but it's not faster than nginx as reverse proxy with CherryPy (performance is about the same for dynamic content, and nginx serves static content faster). In addition the memory consumption with apache+modwsgi embedded mode is much higher. So despite the theoretical advantage of embedded mode (for small deployment), it does not materialize into actual advantage for apache +modwsgi. Last word on modwsgi and its daemon mode, which is similar to reverse proxy and fcgi in that it separates the web server and app server. As such, it has the same theoretical performance as reverse proxy and fcgi (which in fact provide the same performance), but it uses a proprietary communication protocol, and inlike proxy or fcgi, it requires the app and web server processes to be on the same machine (so it does not scale across a pool of machines). Also this modwsgi provides a rudimentary way for the web server (e.g. apache) to monitor the app server, but this is a poor substitute for actual server monitoring tools. So In summary modwsgi daemon mode is completely useless, while modwsgi embedded mode is the best choice when using apache as the webserver, if you only have a single node and enough memory on it. On Jan 13, 4:40 am, mk mrk...@gmail.com wrote: Lawrence Oluyede wrote: I honestly don't know anything about nginx, altough I know personally the author of its mod_wsgi. Never used. We use modwsgi for Apache That's the response on what you actually use in production, thanks. :-) Regards, mk --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Recommended production deployment
Actually one correction: standalone CherryPy smokes everything else (including apache+modwsgi embedded mode) for dynamic content (It's almost TWICE as fast). But CheeryPy (or any python HTTP server) is slower for serving static files. So if you don't have many static files, it might be better to use standalone CherryPy over apache +modwsgi embedded mode. On Jan 13, 6:52 am, Tycon adie...@gmail.com wrote: I think CherryPy is awesome, much better than Paster HTTP (which cant even do HTTPS). In general I prefer to separate the web server and app server (over the embedded approach) as it is more modular, flexible and scalable. But embedded deployment has a theoretical performance advantage because there is no overhead of communication between the web and app server. The best option for embedded deployment is apache+modwsgi (but apache +mod_python or nginx+mod_wsgi also exist). Apache+modwsgi (embedded) is faster than Apache as a reverse proxy, and also outperfoms standalone CherryPy or PasterHTTP, but it's not faster than nginx as reverse proxy with CherryPy (performance is about the same for dynamic content, and nginx serves static content faster). In addition the memory consumption with apache+modwsgi embedded mode is much higher. So despite the theoretical advantage of embedded mode (for small deployment), it does not materialize into actual advantage for apache +modwsgi. Last word on modwsgi and its daemon mode, which is similar to reverse proxy and fcgi in that it separates the web server and app server. As such, it has the same theoretical performance as reverse proxy and fcgi (which in fact provide the same performance), but it uses a proprietary communication protocol, and inlike proxy or fcgi, it requires the app and web server processes to be on the same machine (so it does not scale across a pool of machines). Also this modwsgi provides a rudimentary way for the web server (e.g. apache) to monitor the app server, but this is a poor substitute for actual server monitoring tools. So In summary modwsgi daemon mode is completely useless, while modwsgi embedded mode is the best choice when using apache as the webserver, if you only have a single node and enough memory on it. On Jan 13, 4:40 am, mk mrk...@gmail.com wrote: Lawrence Oluyede wrote: I honestly don't know anything about nginx, altough I know personally the author of its mod_wsgi. Never used. We use modwsgi for Apache That's the response on what you actually use in production, thanks. :-) Regards, mk --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Recommended production deployment
Actually I have apache+modwsgi running flawlessly, and everything I said is based on meticulous performance benchmarking and theoretical profiling of deployment architectures. All benchmarks were performed on pylons full stack production mode, with debugging and logging turned off. The test was a simple hello world page with no template rendering, database access or other external links or references. Apache is prefork MPM v2.2.8 with modwsgi 1.3 using python 2.5.2. The benchmarks CLEARLY show that using a stand-alone app server is MUCH faster then using apache+modwsgi to serve a page (returned from the aforementioned hello world controller action). When using CherryPy as the HTTP server for pylons, the req/sec is almost twice as fast as apache+modwsgi. PasteHTTP is 15% slower than CherryPy but still much faster then Apache+modwsgi. But of course using a stand-alone app-server as the web-server has a few drawbacks: 1. Static files are also served by pylons, which is slow. 2. Cannot use multiple processes, which is required to make optimal use of system resources and allow for scalability across multiple CPUs and multiple machines. So in most cases you will want to have a reverse proxy front-end that acts as a load balancer as well as serve the static files. As you mention, nginx is a good choice. In this configuration, I would assume it would be better to have nginx forward the requests directly to a pool of standalone pylons app-servers, rather than to a pool of apache +modwsgi processes. So, while using only standalone CherryPy to serve a pylons app has some drawbacks, those drawbacks are avoided if using reverse proxy that serves as a load balancer and to serve static files. So when is it best to use apache+modwsgi ? If we have a single node with mutiple cores and a lot of RAM, and we need to serve a lot of static files, then apache+modwsgi would be better than using a standalone app server. But even for this scenario, nginx as a reverse proxy gives about the same performance. On Jan 13, 5:53 pm, Graham Dumpleton graham.dumple...@gmail.com wrote: On Jan 14, 10:42 am, Mike Orr sluggos...@gmail.com wrote: On Tue, Jan 13, 2009 at 6:52 AM, Tycon adie...@gmail.com wrote: Last word on modwsgi and its daemon mode, which is similar to reverse proxy and fcgi in that it separates the web server and app server. As such, it has the same theoretical performance as reverse proxy and fcgi (which in fact provide the same performance), but it uses a proprietary communication protocol, and inlike proxy or fcgi, it requires the app and web server processes to be on the same machine Is *that* what you're talking about when you say daemon mode and proprietary protocol. I thought you meant daemon mode as in running PasteHTTPServer or CherryPy as a daemon, and proprietary protocol as in WSGI or SCGI. The main point of mod_wsgi's daemon mode is to isolate bugs/memory leaks between the web application and the server, and to track the application's individual resource usage in the 'ps' listing. It's not designed for multi-machine scalability. As for its proprietary protocol, I consider that an internal matter of mod_wsgi. What matters is whether it works, and I haven't heard any complaints in that regard. Ultimately it comes down to the sysadmin's time of setting up mod_wsgi now and possibly switching to something else later, vs setting up something multi-machine scalable now (which is more work up front). And that depends on how likely a traffic onslaught is, how quickly the load will accelerate, and the sysadmin's future availability. You don't need to switch to something else when you want to go to a multi machine configuration. This is just part of the FUD that they were pushing on the irc channels in the past to try and discredit Apache/mod_wsgi. It just seems that Tycon is parroting this same message. I wouldn't be surprised if he has never even used Apache/ mod_wsgi. Certainly the originator of a lot of this FUD on the irc channels in the past freely admitted he had installed neither mod_python or mod_wsgi with Apache. When you want to start looking at horizontal scaling you do exactly what you would do were you scaling up Apache for any other scenario. That is, you stick perbal, pound, nginx or some other proxying/load balancing solution in front and run an Apache instance of each of the machines in your cluster. Since running nginx in front of Apache/mod_wsgi to handle static files is a common scenario, that same nginx instance could be used for the job, given that it still likely going to handle the load of both static files and proxying fine because of being event driven rather than threaded. Hmmm, this sounds exactly like what is because suggested if using paste server or cherrypy wsgi server. Strange that. When you read this persons other posts I think it is quite clear that he doesn't really understand the difference
Re: Recommended production deployment
Im using Ubunto 8.04 LTS and running the test using ab -n 1 -c 10 to localhost, in order to focus on the request handling code in the server stack and remove or reduce the weight of all other application logic such as db access and page rendering. This is not supposed to be a realistic timing of a real world request, but a highlight of the differences in efficiency of different request handling stacks including network layer, HTTP and routing code. All software package veriosns I'm using are the versions supplied in the OFFICIAL repositores for the distribution. Pylons and cherrypy were installed using (non)easy-install so their version is the latest rather than a version tied to any official repository. I'm running in a full VM (single core) so I'm pretty sure my results are correct: CherryPy (started using paster serve prodduction.ini) is twice as fast (1300 req/sec for hello world) as Apache+modwsgi (650 req/sec). The only difference you may have is using worker MPM instead of pre-fork MPM, and newer versions of apche and modwsgi. In addition, apache is also logging the requests which is an additional overhead that pylons doesn't do in my configuration. But even so I doubt if Apache could match standalone pylons using CherryPy. On Jan 13, 8:36 pm, Graham Dumpleton graham.dumple...@gmail.com wrote: On Jan 14, 3:10 pm, Tycon adie...@gmail.com wrote: Actually I have apache+modwsgi running flawlessly, and everything I said is based on meticulous performance benchmarking and theoretical profiling of deployment architectures. All benchmarks were performed on pylons full stack production mode, with debugging and logging turned off. The test was a simple hello world page with no template rendering, database access or other external links or references. Apache is prefork MPM v2.2.8 with modwsgi 1.3 using python 2.5.2. Old version of mod_wsgi. If using daemon mode of mod_wsgi then 2.X is somewhat faster. Using embedded mode, prefork especially can stuff up benchmarking because the burst in traffic will cause Apache to create lots of additional child worker processes to handle load. Every one of those then has to load application and that can kill machine performance while occurring, interfering with benchmark results. As such, for applications with high load cost, actually better to use daemon mode with fixed number of processes and with worker MPM for Apache. Stripping Apache of unused modules that take a lot of memory, especially PHP, is also advisable. The benchmarks CLEARLY show that using a stand-alone app server is MUCH faster then using apache+modwsgi to serve a page (returned from the aforementioned hello world controller action). When using CherryPy as the HTTP server for pylons, the req/sec is almost twice as fast as apache+modwsgi. PasteHTTP is 15% slower than CherryPy but still much faster then Apache+modwsgi. Generally contrary results on MacOSX, with both CherryPy and Paste server running quite badly in comparison. On Ubuntu CherryPy runs about the same and Paste server slower. What operating system are you using? Did your tests take into consideration that Apache/mod_wsgi lazy loads application object on first request where as the others preload. This in part plays into why benchmarking results can look bad with Apache/ mod_wsgi, people are actually counting startup costs when they shouldn't. Graham But of course using a stand-alone app-server as the web-server has a few drawbacks: 1. Static files are also served by pylons, which is slow. 2. Cannot use multiple processes, which is required to make optimal use of system resources and allow for scalability across multiple CPUs and multiple machines. So in most cases you will want to have a reverse proxy front-end that acts as a load balancer as well as serve the static files. As you mention, nginx is a good choice. In this configuration, I would assume it would be better to have nginx forward the requests directly to a pool of standalone pylons app-servers, rather than to a pool of apache +modwsgi processes. So, while using only standalone CherryPy to serve a pylons app has some drawbacks, those drawbacks are avoided if using reverse proxy that serves as a load balancer and to serve static files. So when is it best to use apache+modwsgi ? If we have a single node with mutiple cores and a lot of RAM, and we need to serve a lot of static files, then apache+modwsgi would be better than using a standalone app server. But even for this scenario, nginx as a reverse proxy gives about the same performance. On Jan 13, 5:53 pm, Graham Dumpleton graham.dumple...@gmail.com wrote: On Jan 14, 10:42 am, Mike Orr sluggos...@gmail.com wrote: On Tue, Jan 13, 2009 at 6:52 AM, Tycon adie...@gmail.com wrote: Last word on modwsgi and its daemon mode, which is similar to reverse proxy and fcgi in that it separates the web server and app
Re: Recommended production deployment (was: Re: Is Pylons a meta-package ?)
No, mod_wsgi is a hack. Embedded mode is bad, no serious website is running app server embedded in web server. Daemon mode is even more stupid, an unstable (and non scalable) way of using web server to manage the app server, and invent a new communication protocol between them, when standard ones that support distributed architecture already exist. On Jan 12, 10:05 am, mk mrk...@gmail.com wrote: Lawrence Oluyede wrote: Paste and CP3 are not meant to be used in the deployment phase. I really don't care about who's fast during development mode (either Paste or CP3 or something else), I do care that mod_wsgi in Apache or nginx or lighttpd are solid. Would you recommend using ngxinx + mod_wsgi (as described in following link) as production configuration? http://wiki.codemongers.com/NginxNgxWSGIModule Regards, mk --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: which version of python y'all are using ?
But it's well known that 2.6 had some serious performance work done on it, so the consistent 5% improvement I'm obsering in real time performance which is made up of many other things that don't benefit from improvements in python optimization, is actually quite significant. I don't think it's because I compiled it locally, as the binary packages are also compiled with the same or better optimizer options (despite the fact that people that waste time with gentoo would like to think they get better optimized code, the fact is most of the time they don't) On Jan 10, 11:50 pm, Mike Sarahan msara...@gmail.com wrote: That small performance increase may have come about from processor optimization that you did in the process of compiling, rather than any difference between 2.5 and 2.6. Standard packages rarely use much CPU optimization to maintain compatibility. Just something to consider... -Mike On Sat, Jan 10, 2009 at 11:44 PM, Tycon adie...@gmail.com wrote: I haven't tried python 3, but I heard its performance is still lagging compared to 2.6, in addition to the compatibility issues. So I don't see any reason to try to upgrade to it at the moment. On Jan 10, 11:43 pm, Tycon adie...@gmail.com wrote: I performed some benchmarks on python 2.5 vs 2.6, using requests for simple pages as well as complex pages (with two-level db access) and I noticed python 2.6 gives about 4-5% better performance as shown in the request per second throughput. But python 2.6 is not yet available as a standard package in most linux distributions (e.g. debian), so I had to compile and install that from source, although I usually prefer to use the official debian packages. But I though that this consistent and noticeable small performance imporovment was worth 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Is Pylons a meta-package ?
Pylons has some useful things in it, however most of them are actually independent packages that pylons just depends on. The definition of a meta-package - in the context of Debian's APT, for instance - is a package that doesn't have any content of its own, but it's simply a list of dependencies on other package, so that users can get all those other packages by installing the meta-package. The question is what does pylons add of its own to make it more than a meta-package (which is just a list of dependencies). It has a bunch of useful decorators - https, beaker_cache, validate - but they are all so flawed (https throws away query params, beaker cant handle memcache, validate has flawed design and produces invalid html) that I had to write my own. I considered the basic strength to be the HTTP server which comes from Paste which I guess together with some other sub-modules provides all the HTTP request processing. But then I found out about CherryPy 3 and confirmed it gives much better performance and a dispatching architecture, so what exactly is left in pylons ? Maybe Routes, but if the only route you need is controller/action/ id (which I think CherryPy supports) dispatch is enough, then we don't even need routes fancy (and most likely wasteful and expensive) mapping. Mako, SQLAlchemy, and FormEncode are all great but can be used independently. Then I found out the real purpose of pylons in the thread below - basically to be a framework for easy integration of different projects. That's nice but it's not exactly what I need. My emphasis is on light-weight and high-performance, so I'm trying to find out what other parts of Pylons I need, or if I can just use cherrypy+mako +formencode + sqlalchemy+memcache http://groups.google.com/group/pylons-discuss/browse_frm/thread/c6c8c5bb596115c2/81b12ce891a9be04?lnk=gstq=cherrypy#81b12ce891a9be04 --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Is Pylons a meta-package ?
Thanks, that's the information I was looking for - an explanation of what the actual pylons code (that is not part of the thrid party libraries) is doing. I guess that means routes can be taken out if I remove the routes middleware and use my own url_for (which I was just about ready to do). So in your assessment a simple hello world on pylons using cherrypy instead of paster (that is my current config) is going to be as fast as just as an equivalent cherrypy (or pretty close, but not twice as slow) ? P.S. - mod_wsgi is a hack, it's an unstable and unscalable architecture to embed the app server in the web server. And using daemon mode makes even less sense as using apache+mod_wsgi as a process monitor for the app server (it's better to use a dedicated and specialiazed monitoring) as well as a proprietary communication protocol when we already have http and fcgi, is silly. On Jan 11, 12:45 pm, Mike Orr sluggos...@gmail.com wrote: On Sun, Jan 11, 2009 at 5:47 AM, Lawrence Oluyede l.oluy...@gmail.com wrote: On Sun, Jan 11, 2009 at 2:33 PM, Tycon adie...@gmail.com wrote: Pylons has some useful things in it, however most of them are actually independent packages that pylons just depends on. The definition of a meta-package - in the context of Debian's APT, for instance - is a package that doesn't have any content of its own, but it's simply a list of dependencies on other package, so that users can get all those other packages by installing the meta-package. That's where META PACKAGE definition does not apply to Pylons. Pylons has source code, glue code and utility code. Hence is hardly just a meta package. Yes, you are not constrained to use the default packages, but that's not being a meta package, that's being a pluggable architecture. Debian metapackages are just a list of dependencies to install and a label Pylons is everything that's in the Pylons package itself rather than in dependencies. The essential part is the PylonsApp class and the application template. The decorators are peripheral; they were just thrown in as convenience tools. Pylons' philosophy is to use third-party distributions as much as possible. But certain features were not available in any third-party distribution, so they had to be written from scratch. A Routes-based dispatcher, for instance. A fully WSGI request manager. I considered the basic strength to be the HTTP server which comes from Paste which I guess together with some other sub-modules provides all the HTTP request processing. But then I found out about CherryPy 3 and confirmed it gives much better performance and a dispatching architecture, so what exactly is left in pylons ? Paste and CP3 are not meant to be used in the deployment phase. I really don't care about who's fast during development mode (either Paste or CP3 or something else), I do care that mod_wsgi in Apache or nginx or lighttpd are solid. Maybe Routes, but if the only route you need is controller/action/ id (which I think CherryPy supports) dispatch is enough, then we don't even need routes fancy (and most likely wasteful and expensive) mapping. Mako, SQLAlchemy, and FormEncode are all great but can be used independently. You can use CherryPy with Pylons. It's just a small change in the [server] section of the ini file, which you can find in the list archive and maybe on the wiki. Pylons-on-CherryPy is reported to be better in high-traffic deployments than Pylons-on-PasteHTTPServer. (Although mod_wsgi may be faster still?) If you don't want Routes, plain CherryPy may be a good alternative to Pylons. You can certainly use Mako, SQLAlchemy, and FormEncode with it. The Pylons Execution Analysis may help explain what's going on and which module is responsible for what. (It was written for 0.9.6 so a few things like templating have changed, but most of it is still accurate.) http://docs.pythonweb.org/display/pylonscookbook/Pylons+Execution+Ana... Basically, although the Pylons application *template* is specific to Pylons, a created application is the user's code, and when it runs certain portions are not under Pylons' control. So, you run paster serve, and it reads the config file and instantiates the server. This is all Paste, not Pylons. The server may be multithreaded or multiprocess (or mod_wsgi, in which case most of this is skipped). The application advertises a Setuptools entry point for myapp.config.middleware:make_app(). Paste uses this to instantiate the Pylons app. make_app() -- the users' code -- instantiates a PylonsApp and adds some middleware around it. There's some trickery in that the configuration is put into a Pylons config object, and PylonsApp looks in the config object to find out where the application is. (This was done to keep boilerplate code in the users' modules to a minimum.) When a request comes in, Paste calls the PylonsApp as a WSGI application
Re: which version of python y'all are using ?
well I'm a performance person and I hate wasting time because of bad/ sloppy design and implementation. And even for low volume apps, a well tuned app will have a better response time, as well as higher load capacity and better sclalability. In pure request per second I made a bunch of tune-up that resulted in these improvements: 1. Use python2.6 == +5% 2. Use memcached to store sessions == +10% 3. Make sure session is loaded and saved only once instead of multiple time during a request == 5-10% 4. Use cherryPy instead of paste HTTP server == 5-10% 5. Use nginx as a proxy instead of apache = 25% (and save 15MB per worker) 6. Remove redunandant code from middleware (e.g. cache middleware) 7. Use mutiple processes instead of just increasing the number of threads in a single paster app server = 15-20% 8. Cache pages in memcached, and have nginx bypass app server by fetching directly from memcached (and use ssi to render dynamic fragments) == 150% With all these small fixes and optimizations I end up with something that's X-times faster and is noticeable even for low volume apps due to much better response time improving the user experience. Not to mention that I keep a scalable upgrade path by making sure each component can easily be move to a different machine (e.g. = dont use mod_wsgi or local caches). On Jan 11, 1:02 pm, Mike Orr sluggos...@gmail.com wrote: Does Tycon's application actually *need* to be ultra-conservative on overhead, or is this more of an aesthetic desire? I.e., would it actually not run, or require more servers, if all these steps weren't taken? Some applications are so high-load that they require all these steps, but many applications don't. -- Mike Orr sluggos...@gmail.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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Is Pylons a meta-package ?
Does WSGI support remote processes (e.g. on other machines) ? If not then it's a dead end for scalability. I don't see any reason to use proprietary protocol when more standard ones exist. I'm only talking about the spec for daemon mode, not the rest of WSGI call spec. On Jan 11, 2:09 pm, Mike Orr sluggos...@gmail.com wrote: On Sun, Jan 11, 2009 at 1:19 PM, Tycon adie...@gmail.com wrote: I guess that means routes can be taken out if I remove the routes middleware and use my own url_for (which I was just about ready to do). What Pylons needs is 'wsgiorg.routing_args', 'routes.route', and 'routes.url' in the WSGI environment. In other words, something has to emulate the RoutesMiddleware, but it does not have to use Routes. 'wsgiorg.routing_args' is used by the Pylons dispatcher. This was intentionally defined as a neutral standard so that Routes could be replaced with something else. The 'routes.url' object is put onto pylons.url. You'll probably have to provide a dummy object if you don't have a real one, and I imagine 'None' would be OK. url() is called only when the user calls it (although the user may call it indirectly via redirect_to()). I'm not sure if Pylons does anything with 'routes.route', but it may stick it in the config at least, in which case a dummy value would be needed. So in your assessment a simple hello world on pylons using cherrypy instead of paster (that is my current config) is going to be as fast as just as an equivalent cherrypy (or pretty close, but not twice as slow) ? You're still using paster. You're just replacing PasteHTTPServer with CherryPy's server component. The CherryPy *server* handles high traffic better than PasteHTTPServer, according to several user reports. The difference between a Pylons-CherryPy application vs a pure CherryPy application is a different question. I would guess the pure CherryPy application would be slightly more efficient. But a sizeable application is going to have significant different stats compared to Hello World. The overhead of the framework will be much less than the overhead of the application, so even if one framework is 10% more efficient, the net difference in application speed may be only 1%. P.S. - mod_wsgi is a hack, it's an unstable and unscalable architecture to embed the app server in the web server. And using daemon mode makes even less sense as using apache+mod_wsgi as a process monitor for the app server (it's better to use a dedicated and specialiazed monitoring) as well as a proprietary communication protocol when we already have http and fcgi, is silly. I use Supervisor to manage PasteHTTPServer daemons, and I like having a HTTP separate daemon for each application so that I can: - Start and stop them separately (supervisor restart myapp) - See their individual memory usage using 'top'. - Send localhost HTTP requests to them for troubleshooting. Efficiency is not on my radar because I have plenty of server capacity. And the efficiency I *do* worry about is large data structures in memory, which has nothing to do with the deployment method (except for the impact of multithreaded vs multiprocess). And if I *did* have to worry about Python overhead so strictly, I'd also evaluate even more radical choices like not using Python, using a cloud service, etc. Fcgi has a long reputation of being buggy. Perhaps it's better now, but that's why people like me don't use it. SCGI is a *language neutral* replacement that was written specifically to be simpler and more reliable. mod_proxy is of course standard. WSGI may be Python specific, but it does a reasonably good job of making Python frameworks interchangeable. -- Mike Orr sluggos...@gmail.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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Pylons on nginx, SSI, and memcached
The nginx/ssi/memcached config for pylons is shown here:
http://www.resheteretz.com/app/blog/index.php?option=com_contentview=articleid=46:pylons-nginx-ssi-and-memcachedcatid=31:generalItemid=46
On Jan 9, 12:51 pm, Joshua Bronson jabron...@gmail.com wrote:
On Fri, Jan 9, 2009 at 3:36 PM, Joshua Bronson jabron...@gmail.com wrote:
On Fri, Jan 9, 2009 at 3:24 PM, TJ Ninneman
t...@twopeasinabucket.comwrote:
On Jan 9, 2009, at 1:52 PM, Josh wrote:
I'm currently playing with Varnish as a caching layer, which has
support for Edge Side Includes. Have you considered a setup like this?
If so, I'd be interested to hear what made memcached + SSI more
appealing. If not, I'd be happy to provide some links I've come across
if you're interested in exploring this further.
We looked heavily into Varnish as we run everything on FreeBSD and it
looked just darn cool. I just never really had the time to get it
implemented as a reverse proxy.
One of our requirements was the ability for the backside application
to invalidate cached items. Is this possible?
Another requirement was the ability to redirect backend requests by
URL (ie. *.asp to one server and everything else to another). As I
recall, Varnish can do this, right?
TJ
Both of these should be possible. Have a look at
http://bart.motd.be/experimenting-with-varnishand
http://bart.motd.be/using-varnish-http-accelerator-experiences-so-far. See
if the configurations posted there contain enough clues...
Actually, I'm not sure if his configuration covers dispatching to different
backends by url. Something like this ought to work:
backend asp_server {
.host = 127.0.0.1;
.port = XYZ;
}
backend pylons_server {
.host = 127.0.0.1;
.port = ZYX;
}
sub vcl_recv {
if (req.url ~ \.asp$) {
set req.backend = asp_server;
} else {
set req.backend = pylons_server;
}
// ...
}
I also foundhttp://varnish.projects.linpro.no/wiki/VCLExampleLongerCachingto
be an informative read.
--~--~-~--~~~---~--~~
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
pylons-discuss+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
which version of python y'all are using ?
I performed some benchmarks on python 2.5 vs 2.6, using requests for simple pages as well as complex pages (with two-level db access) and I noticed python 2.6 gives about 4-5% better performance as shown in the request per second throughput. But python 2.6 is not yet available as a standard package in most linux distributions (e.g. debian), so I had to compile and install that from source, although I usually prefer to use the official debian packages. But I though that this consistent and noticeable small performance imporovment was worth 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Pylons on nginx, SSI, and memcached
Does anyone have such a configuration working ? Basically it means that on every request nginx will use the URL as the key to perform a lookup on memcached and serve the page from there if it exists. If it's not cached then it will forward the request to pylons which will produce the page and store it in mecached, so subsequent request for the same page will be served by nginx using mecached without forwarding the request to pylons. Also, the parts of the page that should not be cached (such as the current user name, shopping basket, breaking news, etc) are handled using SSI (server side include) which means that the page rendered by pylons include a special SSI tag for each dynamic part of the page (instead of the actual dynamic content). When nginx gets the page (either from pylons or memcached) it will look for those special SSI tags and for each one it will issue a request to pylons to render the dynamic part using the URL that is specified in the tag. So the bottom line is that for each page only the dynamic parts of the page will be rendered on each user request (dynamic parts are the ones that can be different even for request for the same URL). As I understand it from reading rails blogs, this is the holy grail of web app frameworks, as it can give tremendous performance even on low end hardware. At least it does on my development virtual machine. --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Pylons on nginx, SSI, and memcached
Of course for optimal performance and scalability, I'm talking about a reverse proxy configuration with load balancing between multiple paster app servers. Nginx rocks it serves static pages twice as fast as apache, and proxies requests 50% faster, all while using much less memory and CPU time. On Jan 9, 3:40 am, Tycon adie...@gmail.com wrote: Does anyone have such a configuration working ? Basically it means that on every request nginx will use the URL as the key to perform a lookup on memcached and serve the page from there if it exists. If it's not cached then it will forward the request to pylons which will produce the page and store it in mecached, so subsequent request for the same page will be served by nginx using mecached without forwarding the request to pylons. Also, the parts of the page that should not be cached (such as the current user name, shopping basket, breaking news, etc) are handled using SSI (server side include) which means that the page rendered by pylons include a special SSI tag for each dynamic part of the page (instead of the actual dynamic content). When nginx gets the page (either from pylons or memcached) it will look for those special SSI tags and for each one it will issue a request to pylons to render the dynamic part using the URL that is specified in the tag. So the bottom line is that for each page only the dynamic parts of the page will be rendered on each user request (dynamic parts are the ones that can be different even for request for the same URL). As I understand it from reading rails blogs, this is the holy grail of web app frameworks, as it can give tremendous performance even on low end hardware. At least it does on my development virtual machine. --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: session auto-save
Forgot to mention another bug in session cache: The _creation_time is updated to now every time the session is saved. On Jan 7, 11:03 pm, Tycon adie...@gmail.com wrote: Just to clarify, this fix is not really an auto-save like I initially suggested. The fix is basically a deferred-save, which means that any calls to session.save() are not executed immediately, and instead they are deferred to the end of the request. So if session.save() is called at least once, the session will be saved at the end of the request. This means that there is no harm in calling session.save() multiple times, so even existing applications that do that will now see an improvement in performance without having to change the application. This is on top of the other fixes that eliminate redundant loads (before every save) and saves (after first access). On Jan 7, 10:39 pm, Tycon adie...@gmail.com wrote: That's exactly what my fix does, it makes session.save() be deferred by setting a flag to perform the actual save at the end of the request in the session middleware. You still need to call session.save() at least once to make sure the session will be saved, so up upside of all this is that people don't need to modify their code to take advantage of this single deferred save design. And now you don't have to be afraid to add session.save() calls as they will not cause any unnecessary saves. On Jan 7, 10:25 pm, Mike Orr sluggos...@gmail.com wrote: On Wed, Jan 7, 2009 at 10:16 AM, Ben Bangert b...@groovie.org wrote: On Jan 7, 2009, at 4:59 AM, Paweł Stradomski wrote: Just note, that in case the dict is not modified directly, but an object inside is modified, you won't get notified of the change. Eg. suppose the restored session has: session['messages'] = [] Now i do: session['messages'].append(u'New flash message') You won't see that the session has changed. This is the exact reason we don't have a 'dirty' type flag like this set on setitem. However, I think it'd be useful to let a user set the 'dirty' flag themselves, in addition to letting sessions auto-save merely upon access (just to be sure), or something as Tycon suggests. Many people end up calling save() multiple times because they need to put stuff in the session in various places and ensures its saved, when really, they should be marking it 'to-be-saved' so its done just *once*. Ideally session.save() should really mean mark-to-save, and the actual saving done at the end of the request. The issue is that a generic function may modify the session (as is the case with Flash), and it does not know whether the caller will call .save or not. Likewise, the caller may not even know that the function is using the session. I do like the session.save() step because it acts like a transaction commit, explicity confirming that the session is to be modified persistently. On the other hand, it's not truly like a transaction because there is only one session, and any call to .save() will cause all changes to be saved, even if they were made in functions that did not themselves call .save(). But in practice, nobody modifies the session and leaves undesired changes in it counting on them being rolled back, so it's more of a theoretical problem than an actual problem. -- Mike Orr sluggos...@gmail.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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Cache middleware - what is it for exactly ?
What does it actually do that we need to have a middleware for it that executes in every request ? Does it do anything besides insert a reference to some Cache Manager into the environment ? If so, then why not have the Cache Manager as a regular global object ? In fact, when using memcache there is only a single giant cache, so then we don't even need a cache manager. --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Cache middleware - what is it for exactly ?
No having it as a global is much better then in a middleware, because setting up the global happens only once at process start-up time, but the middleware is called in every request. In the middleware you add it to the environment, which is again something that's newly created for every request, but the app-globals are only created once at process startup and remain for the duration of the process. You only want to put something in the per-request environment if it is something that's specific to that request, like the query string. A static global value like a reference to cache manager (the reference to that object doesn't change afte it's set up at startup) should not be in the middleware. This is a simple design concept, just like the concept of not referencing private attributes (e.g. obj._prop) outside the definition of obj's Class (where it would be self._prop which is ok). On Jan 8, 10:51 am, Ben Bangert b...@groovie.org wrote: On Jan 8, 2009, at 4:12 AM, Tycon wrote: What does it actually do that we need to have a middleware for it that executes in every request ? Exactly what you said next. Does it do anything besides insert a reference to some Cache Manager into the environment ? Nope, that's it. If so, then why not have the Cache Manager as a regular global object ? That'd work as well. Either way, the same amount of code is going to run to add it to the globals. In fact, when using memcache there is only a single giant cache, so then we don't even need a cache manager. Well, if you want the locking and duplicate creation prevention checking code, and such, then you'd want the cache manager, rather than just using memcached directly. That's really what the cache manager is doing, and why you'd want to use it. You're right that it doesn't need to be middleware, its quite likely I went middleware-crazy on that. Part of the reason for putting it there rather than inside the PylonsApp code that sets up the globals was so that it'd be easier to remove if you didn't want to use it, though a flag passed to PylonsApp could do that as well. Would a flag to turn it off be preferable to just removing that line from middleware.py? Cheers, Ben smime.p7s 3KViewDownload --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: session auto-save
Below is quick implementation of this proposal. First we need to patch
up Beaker's Session object to record it's dirty state(has been
modified), and to allow clients to check the accessed and dirty
properties:
beaker_patch.py
===
import beaker.session
def __setitem__(self, key, value):
self.__dict__['_dirty'] = True
self._session()[key] = value
def __delitem__(self, key):
self.__dict__['_dirty'] = True
self._session().__delitem__(key)
def save(self):
self._session().save()
self.__dict__['_dirty'] = False
def accessed():
return self.__dict__['_sess'] is not None
def dirty(self):
return self.__dict__.get('_dirty') is not None
beaker.session.SessionObject.__setitem__ = __setitem__
beaker.session.SessionObject.__delitem__ = __delitem__
beaker.session.SessionObject.save = save
beaker.session.SessionObject.accessed = accessed
beaker.session.SessionObject.dirty = dirty
Now we need to implement the autosave in a custom middleware, which
checks the config file for a beaker.session.autosave setting
(defaults to off).
autosave_opt_val = ('off', 'if_accessed', 'on')
class CustomMiddleware(object):
def __init__(self, application, config):
self.application = application
self.opt_val = 0
opt_name = 'beaker.session.autosave'
if opt_name in config:
for idx, name in enumerate(autosave_opt_val):
if config[opt_name] == name:
self.opt_val = idx
break;
else:
raise Exception('Invalid option %r for %r in config
file' %
(config[opt_name], opt_name))
def __call__(self, environ, start_response):
content = self.application(environ, start_response)
if (self.opt_val==2 and session.dirty()) or
(self.opt_val==1 and session.accessed()):
session.save()
return content
Now you can enable autosave in development.ini:
beaker.session.autosave = on
So you can now go ahead and remove all the session.save() calls in
your controllers and templates. The seesion will be save if and only
if it has been modified, that is if an attribute was assigned or
deleted.
On Jan 6, 8:35 pm, Tycon adie...@gmail.com wrote:
The session object is a very useful feature of pylons and is core to
any web application. In pylons the session objects acts like a
dictionary that you can access and modify, as well as save it to a
storage manager which can be memory, file, dbms, memcached, etc.
Normally you want to save whatever changes you made to the session
object, so you have to explictly call session.save(). The most logical
place to do that is at the end of processing a request, but it's
annoying to do that at the end of every request and other wrappers
can't easily tell if the session was modified and needs to be saved.
Since the session can be modified by different parts of your code
during a request, and you are not always sure if those changes will be
saved at the end, what ends up happening is that the session is saved
multiple times during one request, which is wasteful.
Therefore, I have a suggestion to have a session.autosave setting in
the config file that will have the following options:
off: don't autosave
on: save the session object at the end of the request, if it was
modified during the request
if_accessed: saves the session object at the end of the request, if
it was accessed during the request
compat: saves the session object when it's first accessed during the
request, updating the _accessed_time attribute.
The difference between if_accessed and on options is that for
if_accessed the session is saved at the end of the request if it was
accessed or modified, but for on options it's only saved if it was
modified. In either case this means you can remove all the explicit
session.save() statements from your code. Applications that don't
care about the _accessed_time attribute can use the on setting so
the session will be saved only if you actually modified it (this will
produce better performance).
The last option (compat) sounds kind of silly, but it's actually the
way the session object currently works: the first time you try to
access the session object, it is loaded using the storage manager, the
_accessed_time attribute is updated to now, and then the session is
immediately saved back. So any subsequent changes you make to the
session object need to be saved explicitly. The new option if
accessed gives you almost the exact same behavior by making sure the
session is saved if it was accessed, but since it saves at the end of
the request - the session is only saved once (and you don't need to do
it explicitly anymore).
A related note to all those automatic _something_time attributes -
there is a bug with creation_time that it gets set to now when you
do a session.save(). It will be better to have a _modified_time
Re: session auto-save
I agree that it's better to let users set the dirty flag if they want. It would also be great if you can change the Session.load() method to NOT save the session immediately after loading it (not at the end of the request), as is the case today. This auto-saving upon first access is quite useless because subsequent changes to the session during the same request need to be saved separately afterwards. The Session.load () method can set the dirty flag if the autosave options is if_accessed. Together these changes can help avoiding the multiple save() that is happening today every time the session is used. On Jan 7, 10:16 am, Ben Bangert b...@groovie.org wrote: On Jan 7, 2009, at 4:59 AM, Paweł Stradomski wrote: Just note, that in case the dict is not modified directly, but an object inside is modified, you won't get notified of the change. Eg. suppose the restored session has: session['messages'] = [] Now i do: session['messages'].append(u'New flash message') You won't see that the session has changed. This is the exact reason we don't have a 'dirty' type flag like this set on setitem. However, I think it'd be useful to let a user set the 'dirty' flag themselves, in addition to letting sessions auto-save merely upon access (just to be sure), or something as Tycon suggests. Many people end up calling save() multiple times because they need to put stuff in the session in various places and ensures its saved, when really, they should be marking it 'to-be-saved' so its done just *once*. Tycon, I'll have some time later today to merge a patch to that effect in. Cheers, Ben smime.p7s 3KViewDownload --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: session auto-save
I prepared a patch that fixes the following bugs in beaker sessions:
1.
Problem: The first time the session is accessed, the _access_time is
updated and it is immediately saved back.
Solution: Defer saving of the session to the end of the request.
2.
Problem: If the session is accessed but not modified, it still gets
saved to the storage manager.
Solution: If the session was not modified, don't save it.
Note: The solution is the new default behavior. To override it and
revert to the old behavior of saving the session even if it was only
accessed, you can use the setting: beaker.session.auto = True
3.
Problem: Anytime someone calls session.save() the session is first
loaded and then saved.
Solution: Do not perform a redundant load before the saving the
session object.
4.
Problem: If session.save() is called multiple times during a request,
then the session will be saved multiple times.
Solution: Only save the session once at the end of the request, if
necessary.
So with this fix the following hypothetical action only loads and
saves the session once instead of three times :
class HelloController(BaseController):
def index(self):
x = session.get('x')
session['item1']='val1'
session.save()
session['item2']='val2'
session.save()
return render('/hello.html')
On Jan 7, 2:16 pm, Ben Bangert b...@groovie.org wrote:
On Jan 7, 2009, at 11:14 AM, Tycon wrote:
I agree that it's better to let users set the dirty flag if they
want.
It would also be great if you can change the Session.load() method to
NOT save the session immediately after loading it (not at the end of
the request), as is the case today. This auto-saving upon first access
is quite useless because subsequent changes to the session during the
same request need to be saved separately afterwards. The Session.load
() method can set the dirty flag if the autosave options is
if_accessed.
Together these changes can help avoiding the multiple save() that is
happening today every time the session is used.
Definitely. I'd be happy to review a patch to the code if you'd like
to add these features, right now I'm heavily focused on Pylons 0.9.7
release so it'll be a few weeks before I can get back to the Beaker
code-base myself. Feel free to email me directly about any patches
(with unit tests) to this and I can apply them.
I'm sure your suggestion of not saving immediately upon load will also
help session performance, which has been one of our goals for awhile
too.
Cheers,
Ben
smime.p7s
3KViewDownload
--~--~-~--~~~---~--~~
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
pylons-discuss+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: session auto-save
That's exactly what my fix does, it makes session.save() be deferred by setting a flag to perform the actual save at the end of the request in the session middleware. You still need to call session.save() at least once to make sure the session will be saved, so up upside of all this is that people don't need to modify their code to take advantage of this single deferred save design. And now you don't have to be afraid to add session.save() calls as they will not cause any unnecessary saves. On Jan 7, 10:25 pm, Mike Orr sluggos...@gmail.com wrote: On Wed, Jan 7, 2009 at 10:16 AM, Ben Bangert b...@groovie.org wrote: On Jan 7, 2009, at 4:59 AM, Paweł Stradomski wrote: Just note, that in case the dict is not modified directly, but an object inside is modified, you won't get notified of the change. Eg. suppose the restored session has: session['messages'] = [] Now i do: session['messages'].append(u'New flash message') You won't see that the session has changed. This is the exact reason we don't have a 'dirty' type flag like this set on setitem. However, I think it'd be useful to let a user set the 'dirty' flag themselves, in addition to letting sessions auto-save merely upon access (just to be sure), or something as Tycon suggests. Many people end up calling save() multiple times because they need to put stuff in the session in various places and ensures its saved, when really, they should be marking it 'to-be-saved' so its done just *once*. Ideally session.save() should really mean mark-to-save, and the actual saving done at the end of the request. The issue is that a generic function may modify the session (as is the case with Flash), and it does not know whether the caller will call .save or not. Likewise, the caller may not even know that the function is using the session. I do like the session.save() step because it acts like a transaction commit, explicity confirming that the session is to be modified persistently. On the other hand, it's not truly like a transaction because there is only one session, and any call to .save() will cause all changes to be saved, even if they were made in functions that did not themselves call .save(). But in practice, nobody modifies the session and leaves undesired changes in it counting on them being rolled back, so it's more of a theoretical problem than an actual problem. -- Mike Orr sluggos...@gmail.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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: session auto-save
Just to clarify, this fix is not really an auto-save like I initially suggested. The fix is basically a deferred-save, which means that any calls to session.save() are not executed immediately, and instead they are deferred to the end of the request. So if session.save() is called at least once, the session will be saved at the end of the request. This means that there is no harm in calling session.save() multiple times, so even existing applications that do that will now see an improvement in performance without having to change the application. This is on top of the other fixes that eliminate redundant loads (before every save) and saves (after first access). On Jan 7, 10:39 pm, Tycon adie...@gmail.com wrote: That's exactly what my fix does, it makes session.save() be deferred by setting a flag to perform the actual save at the end of the request in the session middleware. You still need to call session.save() at least once to make sure the session will be saved, so up upside of all this is that people don't need to modify their code to take advantage of this single deferred save design. And now you don't have to be afraid to add session.save() calls as they will not cause any unnecessary saves. On Jan 7, 10:25 pm, Mike Orr sluggos...@gmail.com wrote: On Wed, Jan 7, 2009 at 10:16 AM, Ben Bangert b...@groovie.org wrote: On Jan 7, 2009, at 4:59 AM, Paweł Stradomski wrote: Just note, that in case the dict is not modified directly, but an object inside is modified, you won't get notified of the change. Eg. suppose the restored session has: session['messages'] = [] Now i do: session['messages'].append(u'New flash message') You won't see that the session has changed. This is the exact reason we don't have a 'dirty' type flag like this set on setitem. However, I think it'd be useful to let a user set the 'dirty' flag themselves, in addition to letting sessions auto-save merely upon access (just to be sure), or something as Tycon suggests. Many people end up calling save() multiple times because they need to put stuff in the session in various places and ensures its saved, when really, they should be marking it 'to-be-saved' so its done just *once*. Ideally session.save() should really mean mark-to-save, and the actual saving done at the end of the request. The issue is that a generic function may modify the session (as is the case with Flash), and it does not know whether the caller will call .save or not. Likewise, the caller may not even know that the function is using the session. I do like the session.save() step because it acts like a transaction commit, explicity confirming that the session is to be modified persistently. On the other hand, it's not truly like a transaction because there is only one session, and any call to .save() will cause all changes to be saved, even if they were made in functions that did not themselves call .save(). But in practice, nobody modifies the session and leaves undesired changes in it counting on them being rolled back, so it's more of a theoretical problem than an actual problem. -- Mike Orr sluggos...@gmail.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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
session auto-save
The session object is a very useful feature of pylons and is core to any web application. In pylons the session objects acts like a dictionary that you can access and modify, as well as save it to a storage manager which can be memory, file, dbms, memcached, etc. Normally you want to save whatever changes you made to the session object, so you have to explictly call session.save(). The most logical place to do that is at the end of processing a request, but it's annoying to do that at the end of every request and other wrappers can't easily tell if the session was modified and needs to be saved. Since the session can be modified by different parts of your code during a request, and you are not always sure if those changes will be saved at the end, what ends up happening is that the session is saved multiple times during one request, which is wasteful. Therefore, I have a suggestion to have a session.autosave setting in the config file that will have the following options: off: don't autosave on: save the session object at the end of the request, if it was modified during the request if_accessed: saves the session object at the end of the request, if it was accessed during the request compat: saves the session object when it's first accessed during the request, updating the _accessed_time attribute. The difference between if_accessed and on options is that for if_accessed the session is saved at the end of the request if it was accessed or modified, but for on options it's only saved if it was modified. In either case this means you can remove all the explicit session.save() statements from your code. Applications that don't care about the _accessed_time attribute can use the on setting so the session will be saved only if you actually modified it (this will produce better performance). The last option (compat) sounds kind of silly, but it's actually the way the session object currently works: the first time you try to access the session object, it is loaded using the storage manager, the _accessed_time attribute is updated to now, and then the session is immediately saved back. So any subsequent changes you make to the session object need to be saved explicitly. The new option if accessed gives you almost the exact same behavior by making sure the session is saved if it was accessed, but since it saves at the end of the request - the session is only saved once (and you don't need to do it explicitly anymore). A related note to all those automatic _something_time attributes - there is a bug with creation_time that it gets set to now when you do a session.save(). It will be better to have a _modified_time attribute that records when the session was changed, but leave the original _creation_time unchanged so it reflects the original creation time. --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: pylons.decorators.secure.https throws away the query string ?
PasteDeploy 1.3.2 Paste 1.7.2 According to (non)-easy-install these are the best match version, and it's already the active version in easy-install.pth, so hopefully that means I have the latest version in easy- install (=cryptic) speak. On Jan 5, 10:04 am, Ben Bangert b...@groovie.org wrote: On Jan 3, 2009, at 12:34 AM, Tycon wrote: but the PrefixMiddleWare also doesn't seem to be setting the WSGI environment url_scheme (nor request.scheme). The PrefixMiddleware code never looks up HTTP_X_FORWARDED_PROTO and doesn't set the url scheme in the wsgi environment. So that needs to be fixed, as well as made clear to users that they should include it (after it's fixed) if they use a reverse proxy even without a prefix. Hmm, I was under the impression that the latest PrefixMiddleware in Paste does take that into account. Which version of Paste are you using? Cheers, Ben smime.p7s 3KViewDownload --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: url_for / redirect_to RAW mode
I think we need to have three new arguments to url_for: params (dict) - used to create the query string (while deprecating the keyword args method, just like the comment about turbogears mentioned). raw (boolean) - if true then the url is presumed to raw so we don't try to do a routing map match. external (boolean) - if true then don't add the SCRIPT_NAME as prefix. With the above options, you don't need to create a new redirect call, so users can use the current redirect_to (which would pass these args to url_for) and specify options such as raw, external or a params hash. On Jan 5, 9:54 am, Ben Bangert b...@groovie.org wrote: On Jan 4, 2009, at 2:29 PM, Tycon wrote: from the url_for doc string : If no route by that name is found, the string is assumed to be a raw URL. Should the raw URL begin with ``/`` then appropriate SCRIPT_NAME data will be added if present, otherwise the string will be used as the url with keyword args becoming GET query args. But what if I don't want to SCRIPT_NAME to be prefixed to the URL because it's a link for a different application ? For example if pylons app has SCRIPT_NAME of /pylons but I want to create a URL for /blog/newposts which is served an a different blog application (so it should not be converted to /pylons/blog/newposts) ? Normally I wouldn't need to call url_for in this case, and just use the external URL directly, but if I need to do a redirect using pylons redirect_to it will internally call url_for and add the SCRIPT_NAME prefix. Right, this is why Pylons will have a redirect() function that does not pass the args through redirect_to. It's included in the latest Pylons 0.9.7 tip code (soon to be released as final), but isn't yet used as the default as we wanted the book to be accurate for at least one released version of Pylons. :) Cheers, Ben smime.p7s 3KViewDownload --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: pylons.decorators.secure.https throws away the query string ?
there is another bug in that prefix middleware in that it's trying to strip out the SCRIPT_NAME prefix, which is wrong because that should already be stripped out by the webserver before forwarding the request (at least apache mod_proxy does). In general anything under a Location or Alias directive means that it should never be aware of which location it is in, so the location can be easily changed by the web-server configuration. The reason for SCRIPT_NAME is to allow the application to create links to its own pages absolute URLs (e.g starting with /). not to mention that it's faster to do the prefix stripping in the web server. So right now that middleware will do a second stripping of the SCRIPT_NAME prefix in addition to the stripping by apache, which will cause problems for URLs like /app/app/action On Jan 5, 11:14 am, Ian Bicking i...@colorstudy.com wrote: Looking at news, this is only in trunk:http://svn.pythonpaste.org/Paste/Deploy/trunk/docs/news.txt Try: easy_install PasteDeploy==dev Tycon wrote: PasteDeploy 1.3.2 Paste 1.7.2 According to (non)-easy-install these are the best match version, and it's already the active version in easy-install.pth, so hopefully that means I have the latest version in easy- install (=cryptic) speak. On Jan 5, 10:04 am, Ben Bangert b...@groovie.org wrote: On Jan 3, 2009, at 12:34 AM, Tycon wrote: but the PrefixMiddleWare also doesn't seem to be setting the WSGI environment url_scheme (nor request.scheme). The PrefixMiddleware code never looks up HTTP_X_FORWARDED_PROTO and doesn't set the url scheme in the wsgi environment. So that needs to be fixed, as well as made clear to users that they should include it (after it's fixed) if they use a reverse proxy even without a prefix. Hmm, I was under the impression that the latest PrefixMiddleware in Paste does take that into account. Which version of Paste are you using? Cheers, Ben smime.p7s 3KViewDownload -- Ian Bicking : i...@colorstudy.com :http://blog.ianbicking.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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: url_for / redirect_to RAW mode
And I dont like the trailing underscore idea, because it would be a
mess to deal with in most common use cases like:
params = dict(request.params)
url = url_for('/page', **params)
With the params dict suggestion this will be written into
url = url_for('/page', params)
But with trailing underscore you would have to do some ugly (and
expensive) manipulation:
for key in params.keys():
new_key = key + '_'
params[new_key] = params[key]
del params[key]
url = url_for('/page', **params)
That is horrible
On Jan 5, 12:18 pm, Tycon adie...@gmail.com wrote:
and users can easily concatenate the query string to the url by
themselves, so not much point to allow that option. I like the params
dict suggestion.
On Jan 5, 12:11 pm, Wyatt Baldwin wyatt.lee.bald...@gmail.com wrote:
On Jan 5, 11:57 am, Mike Orr sluggos...@gmail.com wrote:
On Mon, Jan 5, 2009 at 11:13 AM, Wyatt Baldwin
[snip]
Actually, I think I like the idea of making the query params into a
single argument. It could be a string like a=1b=2 or a dict.
No! Encouraging the user to do their own interpolation and escaping
would be a step back into the Dark Ages.
Sorry if I'm being daft, but you're only vehemently (!) opposing
``params`` as a *string*, correct?
I see your point there, and I can't think of a case where I'd need or
want to use a str instead of a dict--except maybe where the query
string came from elsewhere, but that seems like a fairly unusual case.
--~--~-~--~~~---~--~~
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
pylons-discuss+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: url_for / redirect_to RAW mode
and users can easily concatenate the query string to the url by themselves, so not much point to allow that option. I like the params dict suggestion. On Jan 5, 12:11 pm, Wyatt Baldwin wyatt.lee.bald...@gmail.com wrote: On Jan 5, 11:57 am, Mike Orr sluggos...@gmail.com wrote: On Mon, Jan 5, 2009 at 11:13 AM, Wyatt Baldwin [snip] Actually, I think I like the idea of making the query params into a single argument. It could be a string like a=1b=2 or a dict. No! Encouraging the user to do their own interpolation and escaping would be a step back into the Dark Ages. Sorry if I'm being daft, but you're only vehemently (!) opposing ``params`` as a *string*, correct? I see your point there, and I can't think of a case where I'd need or want to use a str instead of a dict--except maybe where the query string came from elsewhere, but that seems like a fairly unusual case. --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: url_for / redirect_to RAW mode
right and don't forget about adding the new raw (to avoid mapper
lookup if true) and external (to avoid adding SCRIPT_NAME prefix if
true) arguments, in addition to the params dict, so you will have a
much better url_for
On Jan 5, 1:07 pm, Mike Orr sluggos...@gmail.com wrote:
On Mon, Jan 5, 2009 at 12:35 PM, Tycon adie...@gmail.com wrote:
And I dont like the trailing underscore idea, because it would be a
mess to deal with in most common use cases like:
params = dict(request.params)
url = url_for('/page', **params)
With the params dict suggestion this will be written into
url = url_for('/page', params)
But with trailing underscore you would have to do some ugly (and
expensive) manipulation:
Ah, that's a good point. (Although it has been this way for years and
nobody has complained about it till now, so I guess using 'host' as a
bona fide parameter is not very common.)
So what about having a 'params' argument but keeping the current
behavior if 'params' is not set. That would allow backward
compatibility.
Then if 'params' is set and another argument doesn't correspond to any
path variable, I guess you'd raise an error.
Wyatt wrote wrote:
Actually, I think I like the idea of making the query params into a
single argument. It could be a string like a=1b=2 or a dict.
Mike wrote:
No! Encouraging the user to do their own interpolation and escaping
would be a step back into the Dark Ages.
Wyatt wrote:
Sorry if I'm being daft, but you're only vehemently (!) opposing
``params`` as a *string*, correct?
Correct.
Wyatt wrote:
I see your point there, and I can't think of a case where I'd need or
want to use a str instead of a dict--except maybe where the query
string came from elsewhere, but that seems like a fairly unusual case.
Almost always they will come from request.params, which has already
parsed them into a dict. Perhaps reading a log file or something.
But in general, the parsing to a dict and back is a feature of any
good framework, even if it does add some overhead. But that kind of
overhead is why you're using a framework in the first place.
--
Mike Orr sluggos...@gmail.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
pylons-discuss+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: url_for / redirect_to RAW mode
Also lets not forget that keyword args can't represent a multi-dict which is allowed for the request parameters. That's why it was a bad idea from the start to use keyword args for the params. On Jan 5, 5:57 pm, Mark Ramm mark.mchristen...@gmail.com wrote: So what about having a 'params' argument but keeping the current behavior if 'params' is not set. That would allow backward compatibility. Then if 'params' is set and another argument doesn't correspond to any path variable, I guess you'd raise an error. Well, what we did in tg2 was merge the values from the params dict (if it's present) into the kwargs that was passed into url and redirect. This allows you to either passin thing as kwargs, or pass the params dict, or, if you're slightly crazy do both ;) --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Problems with pylons.decorators.validate
The validation state can be set using the validation_ctx method in the FormHandler class. Here's the new handler and decorator: from pylons.controllers.util import redirect_to from pylons.decorators import PylonsFormEncodeState import decorator import formencode class FormHandler(object): def check(self): return None def defaults(self): return request.GET def validation_ctx(self): return None def process(self, result): redirect_to(**dict(request.GET)) def validate(schema, handler, **htmlfill_kwargs): def wrapper(func, *args, **kwargs): errors = handler.check() if errors: return errors if request.method=='GET': defaults = handler.defaults() else: vctx = handler.validation_ctx() or PylonsFormEncodeState try: result = schema.to_python(request.params.mixed(), vctx) except formencode.Invalid, e: errors = e.unpack_errors() if not errors: return handler.process(result) defaults = request.POST #display form content = func(*args, **kwargs) return formencode.htmlfill.render(content, defaults=defaults, errors=errors, **htmlfill_kwargs) return decorator.decorator(wrapper) On Jan 4, 4:48 am, Mike Orr sluggos...@gmail.com wrote: On Sun, Jan 4, 2009 at 3:57 AM, Tycon adie...@gmail.com wrote: Using this decorator has greatly simplified my form handling code, so if there is interest I can publish the source code for this decorator/ handler architecture. Yes, please publish it and put a link in ticket #405http://pylonshq.com/project/pylonshq/ticket/405 There has been a proposal to split @validate into three parts that can be used independently in an action, while still keeping the decorator compatible. Then Mike Bayer proposed a second solution which uses Mako (and may be too much Mako code for a Pylons default?). But we are still looking for other approaches. I use @validate but am not that happy with it. I'm not sure that a validator is even the right solution to this problem, because you can't pass action-specific state through a decorator and that's often the most interesting state (the database record corresponding to the request). One problem with @validate currently is that it mixes code that's part of the basic pattern with code to make the decorator flexible, and that makes it cumbersome to inline the equivalent code in an action. -- Mike Orr sluggos...@gmail.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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Problems with pylons.decorators.validate
To solve the problem with the supplied validation decorator, I came up
with a new validator the abstracts the different part of form handling
in the controller action. You use the new decorator on top of a action
method, in a similar way to the old decorator, but you pass a form
handler class in addition to the form schema class:
@validate(MySchema(), MyHandler())
def register(self):
c.info_for_template = f(request.params)
return render('my_form.mako')
Note that in the action method itself you only need to display the
form's page, and not do any pre- or post-processing. The decorator
will take care (using the handler class) of performing any checks,
validate the form (on POST reuests),
perform post processing if validation succeeded, or call your action
method to render the form and populate it with initial values or
values from the last POST request.
The schema class that is passed as the first argument to the decorator
is the same as for the old validate decorator - it's a class derived
from formencode.Schema that you define for your form, for example:
class MySchema(formencode.Schema):
email = formencode.validators.Email(not_empty=True)
name = formencode.validators.MinLength(2)
The real magic comes from the form handler class which you define as
a derived class of the new FormHandler class, for example:
class MyHandler(FormHandler):
def check(self):
if session.has_key('user'):
redirect_to(action='error') # can't register if already
logged-in
return None # everything OK
def process(self, result):
user=model.User(name=result['name'], email=result['email'])
user.save_to_db()
session['flash']='Thank you for registering'
session.save()
redirect_to('homepage')
The most important method to override is process which is called
after the form has been validated successfully. In this method you
will normally perform the actions which the form is designed for, such
as creating a new record in the database. The form's values are passed
in the argument result.
You don't really need to define any of the other methods, but they are
useful in some situations.
The check method is called by the decorator in the beginning of
processing every request (the first GET request, and all subsequent
POST requests). Here you can check permissions and other pre-
conditions, and return None if everything is OK. If something is
wrong and you don't want the form to be displayed, then you can
redirect or return a different page (e.g. using mako_rander). Note
that this method is mostly for convenience, because you can achieve
the same thing by defining another method in your controller that
perfoms the same checks and then calls the method with the validate
decorator.
Another optional method is defaults which is called only once before
rendering the form on the first GET request, and is supposed to return
the initial values of the form's fields in a dict-like object. The
default defaults are taken from the request params.
The last method is validation_ctx and it's called by the validate
decorator just before performing form validation and is supposed to
return a state object that is passed to the form's (user-defined)
validators which were declared in the schema. Note that you can always
use the c global to pass information to the validators, but in any
case you can use this method to populate your chosen context.
Using this decorator has greatly simplified my form handling code, so
if there is interest I can publish the source code for this decorator/
handler architecture.
On Jan 3, 4:17 pm, Tycon adie...@gmail.com wrote:
I was trying to use this decorators like this:
@validate(schema=MySchema(), form='action')
def action(self):
if request.method=='GET':
return render('/form.mako')
else:
return _process_form(self.form_result)
But there are a few problems with this approach:
1. The first time the controller action is called, it renders the
template without removing the special error placement tags.
2. There is no way to set default values for the form other than
coding them into the template. It would be better to be able to set
default values that would be filled only the first time the form is
rendered.
3. There is no way to pass a dynamic state object to the decorator,
that would be passed to the form validators. This is because the
decorator is called at compile time, so the you can only pass to it
static objects as the state.
4. You actually have to specify the name of the action method that
renders the form as an argument to the decorator, and this method
can't be private (so even if it's not the original action method for
this request, it is callable as an action method directly by itself).
5. The action method will be run every time the form has to be
rendered, e.g. after every failed validation,
so you can't use it to perform initial one
Re: Problems with pylons.decorators.validate
This is the form template for the example code I gave previously. Note
that the form action is POST to the SAME URL as the original GET
request. This lets you define everything in a single controller action
method (together with the form-handler class and its process
method) :
${h.form(h.url_for())}
Email ${h.text('email')} form:error name=email
br
Email ${h.text('email')} form:error name=name
br
${h.submit('register', 'Register')}
${h.end_form()}
On Jan 4, 8:21 am, Tycon adie...@gmail.com wrote:
The validation state can be set using the validation_ctx method in
the FormHandler class. Here's the new handler and decorator:
from pylons.controllers.util import redirect_to
from pylons.decorators import PylonsFormEncodeState
import decorator
import formencode
class FormHandler(object):
def check(self):
return None
def defaults(self):
return request.GET
def validation_ctx(self):
return None
def process(self, result):
redirect_to(**dict(request.GET))
def validate(schema, handler, **htmlfill_kwargs):
def wrapper(func, *args, **kwargs):
errors = handler.check()
if errors:
return errors
if request.method=='GET':
defaults = handler.defaults()
else:
vctx = handler.validation_ctx() or PylonsFormEncodeState
try:
result = schema.to_python(request.params.mixed(),
vctx)
except formencode.Invalid, e:
errors = e.unpack_errors()
if not errors:
return handler.process(result)
defaults = request.POST
#display form
content = func(*args, **kwargs)
return formencode.htmlfill.render(content, defaults=defaults,
errors=errors, **htmlfill_kwargs)
return decorator.decorator(wrapper)
On Jan 4, 4:48 am, Mike Orr sluggos...@gmail.com wrote:
On Sun, Jan 4, 2009 at 3:57 AM, Tycon adie...@gmail.com wrote:
Using this decorator has greatly simplified my form handling code, so
if there is interest I can publish the source code for this decorator/
handler architecture.
Yes, please publish it and put a link in ticket
#405http://pylonshq.com/project/pylonshq/ticket/405
There has been a proposal to split @validate into three parts that can
be used independently in an action, while still keeping the decorator
compatible. Then Mike Bayer proposed a second solution which uses
Mako (and may be too much Mako code for a Pylons default?). But we
are still looking for other approaches. I use @validate but am not
that happy with it. I'm not sure that a validator is even the right
solution to this problem, because you can't pass action-specific state
through a decorator and that's often the most interesting state (the
database record corresponding to the request). One problem with
@validate currently is that it mixes code that's part of the basic
pattern with code to make the decorator flexible, and that makes it
cumbersome to inline the equivalent code in an action.
--
Mike Orr sluggos...@gmail.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
pylons-discuss+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: Problem with redirect_to and SSL
you need to set this header in apache so Routes will know that the
original
request was https:
RequestHeader set X_URL_SCHEME https
Use this only in the ssl virtual host so your site will be accessible
either with http or https.
On Jan 4, 4:53 am, Andre Kolell andre.kol...@bluesummit.de wrote:
Nn my Blog I habe written a complete example for using SSL (in
German):http://blog.andrekolell.de/2008/12/27/ssl-zugriff-auf-pylons-auf-past...
- Ursprüngliche Mail -
Von: Mike Orr sluggos...@gmail.com
An: pylons-discuss@googlegroups.com
Gesendet: Dienstag, 23. Dezember 2008 10:32:27 GMT +01:00
Amsterdam/Berlin/Bern/Rom/Stockholm/Wien
Betreff: Re: Problem with redirect_to and SSL
On Mon, Dec 22, 2008 at 2:36 AM, Andre Kolell
andre.kol...@bluesummit.de wrote:
I solved the problem regarding redirect_to and SSL by using mod_rewrite to
redirect each http-request to https:
NameVirtualHost *:80
virtualhost *:80
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^/(.*) https://%{SERVER_NAME}%{REQUEST_URI} [R]
/virtualhost
I'm not sure if this is an adequate solution.
I use a variation of this and have not had any problems with redirect_to:
VirtualHost IP:80
ServerName DOMAIN
RewriteEngine On
RewriteRule /(.*) https://DOMAIN/$1 [R=permanent]
CustomLog /dev/null combined
/VirtualHost
My main purpose for this is not redirect_to but in case the user tries
to go to the site with http:. But I guess it also solves a problem I
didn't know I had.
The 'RewriteCond %{HTTPS} !=on' is not necessary since you've
specified :80 and port 80 is always HTTP.
--
Mike Orr sluggos...@gmail.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
pylons-discuss+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: pylons.decorators.secure.https throws away the query string ?
One more note regarding nginx reverse proxy setup with a prefix - by
default nginx doesn't seem to strip the prefix when forwarding the
request (unlike apache which does), so you will also need to use the
rewrite directive in nginx to do that, for example:
location /prefix/ {
rewrite ^/prefix(.*) $1 break;
proxy_set_header X_FORWARDED_PROTO $scheme;
proxy_set_header X_FORWARDED_HOST $server_name;
proxy_pass http://localhost:5000;
proxy_redirect default;
}
Apache does the right thing by stripping the prefix, as this is the
job of the web server to to map logical URLs.
On Jan 4, 1:03 pm, Tycon adie...@gmail.com wrote:
Here's a new PrefixMiddleware that works correctly:
class PrefixMiddleware(object):
def __init__(self, application, config):
self.application = application
if 'url_prefix' in config:
self.prefix = config['url_prefix'].rstrip('/')
def __call__(self, environ, start_response):
environ['wsgi.url_scheme'] = environ.get
('HTTP_X_FORWARDED_PROTO', 'http')
if 'HTTP_X_FORWARDED_HOST' in environ:
environ['HTTP_HOST']=environ['HTTP_X_FORWARDED_HOST']
if self.prefix:
environ['SCRIPT_NAME']=self.prefix
return self.application(environ, start_response)
It depends on url_prefix setting in the config file (if using a
prefix), and on HTTP_X_FORWARDED_PROTO and HTTP_X_FORWARDED_HOST
headers in the http request to indicate the original host and
protocol.
In apache, HTTP_X_FORWARDED_HOST is set by default (when request is
forwarded using mod_proxy) and you can set the other one like this:
RequestHeader set X_URL_SCHEME https
In nginx, you set them like this:
proxy_set_header X_FORWARDED_PROTO $scheme;
proxy_set_header X_FORWARDED_HOST $server_name;
You can use the PrefixMiddleware at the end of config/middleware.py:
app = PrefixMiddleware(app, config)
return app
On Jan 3, 12:34 am, Tycon adie...@gmail.com wrote:
but the PrefixMiddleWare also doesn't seem to be setting the WSGI
environment url_scheme
(nor request.scheme). The PrefixMiddleware code never looks up
HTTP_X_FORWARDED_PROTO and doesn't set the url scheme in the wsgi
environment. So that needs to be fixed, as well as made clear to
users that they should include it (after it's fixed) if they use a
reverse proxy even without a prefix.
On Jan 2, 11:32 pm, Ben Bangert b...@groovie.org wrote:
On Jan 2, 2009, at 9:45 PM, Tycon wrote:
I submitted a ticket (#554) for this bug, with a proposed fix.
But there is another bug underlying this function which affects
detection of the request's url scheme. This decorator uses
request.scheme to find out if the request was http or https, but in
a reverse proxy configuration this is always set to http even if the
original request was https.
That's not a bug. In a reverse proxy you should be using the
PrefixMiddleware which fixes up the WSGI environ based on headers that
your proxy should set, like X_FORWARDED_FOR, etc.
The routes module (which provides url_for and redirect_to) actually
has a better way of checking the request scheme by using the
HTTP_X_FORWARDED_PROTO header (so it correctly creates fully qualified
URLs even in proxy mode).
This will likely be removed in favor of using middleware as
appropriate to fix the environ settings based on the deployment
environment.
Cheers,
Ben
smime.p7s
3KViewDownload
--~--~-~--~~~---~--~~
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
pylons-discuss+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: pylons.decorators.secure.https throws away the query string ?
Here's a new PrefixMiddleware that works correctly:
class PrefixMiddleware(object):
def __init__(self, application, config):
self.application = application
if 'url_prefix' in config:
self.prefix = config['url_prefix'].rstrip('/')
def __call__(self, environ, start_response):
environ['wsgi.url_scheme'] = environ.get
('HTTP_X_FORWARDED_PROTO', 'http')
if 'HTTP_X_FORWARDED_HOST' in environ:
environ['HTTP_HOST']=environ['HTTP_X_FORWARDED_HOST']
if self.prefix:
environ['SCRIPT_NAME']=self.prefix
return self.application(environ, start_response)
It depends on url_prefix setting in the config file (if using a
prefix), and on HTTP_X_FORWARDED_PROTO and HTTP_X_FORWARDED_HOST
headers in the http request to indicate the original host and
protocol.
In apache, HTTP_X_FORWARDED_HOST is set by default (when request is
forwarded using mod_proxy) and you can set the other one like this:
RequestHeader set X_URL_SCHEME https
In nginx, you set them like this:
proxy_set_header X_FORWARDED_PROTO $scheme;
proxy_set_header X_FORWARDED_HOST $server_name;
You can use the PrefixMiddleware at the end of config/middleware.py:
app = PrefixMiddleware(app, config)
return app
On Jan 3, 12:34 am, Tycon adie...@gmail.com wrote:
but the PrefixMiddleWare also doesn't seem to be setting the WSGI
environment url_scheme
(nor request.scheme). The PrefixMiddleware code never looks up
HTTP_X_FORWARDED_PROTO and doesn't set the url scheme in the wsgi
environment. So that needs to be fixed, as well as made clear to
users that they should include it (after it's fixed) if they use a
reverse proxy even without a prefix.
On Jan 2, 11:32 pm, Ben Bangert b...@groovie.org wrote:
On Jan 2, 2009, at 9:45 PM, Tycon wrote:
I submitted a ticket (#554) for this bug, with a proposed fix.
But there is another bug underlying this function which affects
detection of the request's url scheme. This decorator uses
request.scheme to find out if the request was http or https, but in
a reverse proxy configuration this is always set to http even if the
original request was https.
That's not a bug. In a reverse proxy you should be using the
PrefixMiddleware which fixes up the WSGI environ based on headers that
your proxy should set, like X_FORWARDED_FOR, etc.
The routes module (which provides url_for and redirect_to) actually
has a better way of checking the request scheme by using the
HTTP_X_FORWARDED_PROTO header (so it correctly creates fully qualified
URLs even in proxy mode).
This will likely be removed in favor of using middleware as
appropriate to fix the environ settings based on the deployment
environment.
Cheers,
Ben
smime.p7s
3KViewDownload
--~--~-~--~~~---~--~~
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
pylons-discuss+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: Ten reasons why couchdb is better than (off topic)
Oracle XML-DB is not client/server ? hahahahahahahahhahahaha On Jan 4, 12:57 pm, Lawrence Oluyede l.oluy...@gmail.com wrote: 2009/1/4 Tycon adie...@gmail.com: Oracle XML-DB can do the same thing (and more) - that is, allow you to store documents in filesystem-like structure, and get the DBMS transactional behavior as well as allow you to query based on document contents (be it structured or not). Oracle XML-DB is not client/server, it's embedded in the process and based on Berkeley DB. Definitely not the same thing. -- Lawrence,www.neropercaso.it- oluyede.org It is difficult to get a man to understand something when his salary depends on not understanding it - Upton Sinclair --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Problems with pylons.decorators.validate
PylonsHQ ticket system is down (does it run on pylons?) On Jan 4, 4:48 am, Mike Orr sluggos...@gmail.com wrote: On Sun, Jan 4, 2009 at 3:57 AM, Tycon adie...@gmail.com wrote: Using this decorator has greatly simplified my form handling code, so if there is interest I can publish the source code for this decorator/ handler architecture. Yes, please publish it and put a link in ticket #405http://pylonshq.com/project/pylonshq/ticket/405 There has been a proposal to split @validate into three parts that can be used independently in an action, while still keeping the decorator compatible. Then Mike Bayer proposed a second solution which uses Mako (and may be too much Mako code for a Pylons default?). But we are still looking for other approaches. I use @validate but am not that happy with it. I'm not sure that a validator is even the right solution to this problem, because you can't pass action-specific state through a decorator and that's often the most interesting state (the database record corresponding to the request). One problem with @validate currently is that it mixes code that's part of the basic pattern with code to make the decorator flexible, and that makes it cumbersome to inline the equivalent code in an action. -- Mike Orr sluggos...@gmail.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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Problems with pylons.decorators.validate
OK, thanks.
I have a small correction to the form I used in the example (used
email field twice, it should be email and name):
${h.form(h.url_for())}
Email ${h.text('email')} form:error name=email
br
Name ${h.text('name')} form:error name=name
br
${h.submit('register', 'Register')}
${h.end_form()}
Also as for dynamically setting up contextual information for the
validation, you can use the validation_ctx method of the derived
FormHandler class you define to store that info in the c global (or
your own validation state object) based on the request parameters. And
then you can use that info in your validators. The validation_ctx
method is called by the decorator just before invoking the schema
validation.
On Jan 4, 3:42 pm, Mike Orr sluggos...@gmail.com wrote:
On Sun, Jan 4, 2009 at 2:45 PM, Tycon adie...@gmail.com wrote:
PylonsHQ ticket system is down (does it run on pylons?)
Added. It must have been down momentarily. The tickets are in a Trac
project. I think pylonshq.com is Pylons.
--
Mike Orr sluggos...@gmail.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
pylons-discuss+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: url_for / redirect_to RAW mode
Another issue with url_for is the handling of query string parameters
using keyword arguments. Currently any extra keyword arguments will be
added to the generated URL as query string, for example:
url_for('/page', arg='val') == /page?arg=val
The problem is that you can't use keyword arguments for any of the
argument names reserved by the function, such as host, protocol,
etc, for example:
params = { 'arg': 'val', 'host': 'machine' }
url_for('/page', **params)
should return:
/page?arg=valhost=machine
but it treats the host key in params as the host name so it actually
returns:
http://machine/page?arg=val
On Jan 4, 2:29 pm, Tycon adie...@gmail.com wrote:
from the url_for doc string :
If no route by that name is found, the string is assumed to be a
raw URL.
Should the raw URL begin with ``/`` then appropriate SCRIPT_NAME
data will
be added if present, otherwise the string will be used as the url
with
keyword args becoming GET query args.
But what if I don't want to SCRIPT_NAME to be prefixed to the URL
because it's a link for a different application ? For example if
pylons app has SCRIPT_NAME of /pylons but I want to create a URL for
/blog/newposts which is served an a different blog application (so
it should not be converted to /pylons/blog/newposts) ?
Normally I wouldn't need to call url_for in this case, and just use
the external URL directly, but
if I need to do a redirect using pylons redirect_to it will
internally call url_for and add the SCRIPT_NAME
prefix.
--~--~-~--~~~---~--~~
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
pylons-discuss+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: pylons.decorators.secure.https throws away the query string ?
but the PrefixMiddleWare also doesn't seem to be setting the WSGI environment url_scheme (nor request.scheme). The PrefixMiddleware code never looks up HTTP_X_FORWARDED_PROTO and doesn't set the url scheme in the wsgi environment. So that needs to be fixed, as well as made clear to users that they should include it (after it's fixed) if they use a reverse proxy even without a prefix. On Jan 2, 11:32 pm, Ben Bangert b...@groovie.org wrote: On Jan 2, 2009, at 9:45 PM, Tycon wrote: I submitted a ticket (#554) for this bug, with a proposed fix. But there is another bug underlying this function which affects detection of the request's url scheme. This decorator uses request.scheme to find out if the request was http or https, but in a reverse proxy configuration this is always set to http even if the original request was https. That's not a bug. In a reverse proxy you should be using the PrefixMiddleware which fixes up the WSGI environ based on headers that your proxy should set, like X_FORWARDED_FOR, etc. The routes module (which provides url_for and redirect_to) actually has a better way of checking the request scheme by using the HTTP_X_FORWARDED_PROTO header (so it correctly creates fully qualified URLs even in proxy mode). This will likely be removed in favor of using middleware as appropriate to fix the environ settings based on the deployment environment. Cheers, Ben smime.p7s 3KViewDownload --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Problems with pylons.decorators.validate
I was trying to use this decorators like this:
@validate(schema=MySchema(), form='action')
def action(self):
if request.method=='GET':
return render('/form.mako')
else:
return _process_form(self.form_result)
But there are a few problems with this approach:
1. The first time the controller action is called, it renders the
template without removing the special error placement tags.
2. There is no way to set default values for the form other than
coding them into the template. It would be better to be able to set
default values that would be filled only the first time the form is
rendered.
3. There is no way to pass a dynamic state object to the decorator,
that would be passed to the form validators. This is because the
decorator is called at compile time, so the you can only pass to it
static objects as the state.
4. You actually have to specify the name of the action method that
renders the form as an argument to the decorator, and this method
can't be private (so even if it's not the original action method for
this request, it is callable as an action method directly by itself).
5. The action method will be run every time the form has to be
rendered, e.g. after every failed validation,
so you can't use it to perform initial one-time checks.
All the above problems happen because using the decorator approach to
do too many things using a single method. Trying to work around the
limitations by breaking up the action method into several different
functions also doesn't work well when using this decorator. So it
seems like it's better to do the validation the long way, or at
least redesign this decorator to be a class with different methods
that can be overridden.
--~--~-~--~~~---~--~~
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
pylons-discuss+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: Ten reasons why couchdb is better than (off topic)
what's the TPC-C score for couchdb ? On Jan 3, 1:09 pm, mobil mobiledream...@gmail.com wrote: Ten reasons why couchdb is better than (off topic) http://pylab.blogspot.com/2009/01/ten-reasons-why-couchdb-is-better-t... Guys I wrote up a small list of reasons why i think couchdb is way bettter than mysql. Do let me know what you think -- Gpirate the top torrent search enginehttp://gpirate.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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: pylons.decorators.secure.https throws away the query string ?
that would only work if the web server can determine if a particular request should be http or https, which it could do only if there was something in the request URI to indicate that (like the URI begnning with /secure for example). But what if I have an arbitrary URI (e.g. /hello/login) that should redirect to https, but others (e.g. /hello/logout) that should not ? On Jan 2, 3:29 pm, Bob Ippolito b...@redivi.com wrote: We do lots of HTTPS with Pylons, we just don't use that decorator. In our case, HTTP - HTTPS redirects are done at the web server layer and not in the application at all. On Fri, Jan 2, 2009 at 3:21 PM, Tycon adie...@gmail.com wrote: So no one is using this decorator for https ?? I guess it's only required for serious e-commerce websites, maybe there are no such pylons apps On Jan 1, 6:23 pm, Tycon adie...@gmail.com wrote: This decorator is supposed to redirect HTTP GET requests to HTTPS. But guess what ? The query string in the request URI is lost, so the redirected (https) request will not have any request.params even if the original (http) request did. --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: pylons.decorators.secure.https throws away the query string ?
I submitted a ticket (#554) for this bug, with a proposed fix. But there is another bug underlying this function which affects detection of the request's url scheme. This decorator uses request.scheme to find out if the request was http or https, but in a reverse proxy configuration this is always set to http even if the original request was https. The routes module (which provides url_for and redirect_to) actually has a better way of checking the request scheme by using the HTTP_X_FORWARDED_PROTO header (so it correctly creates fully qualified URLs even in proxy mode). Anyway, that is a separate issue that needs to be fixed in the middleware that sets the request.scheme and the environ ['wsgi.url_scheme'], because they should reflect the original request's scheme regardless if the app is served via proxying or embedding. On Jan 2, 7:26 pm, Philip Jenvey pjen...@underboss.org wrote: On Jan 1, 2009, at 6:23 PM, Tycon wrote: This decorator is supposed to redirect HTTP GET requests to HTTPS. But guess what ? The query string in the request URI is lost, so the redirected (https) request will not have any request.params even if the original (http) request did. I'm surprised nobody's noticed this bug yet, thanks for pointing it out. We'll get it fixed for 0.9.7 final, though you should log a ticket for it anyway, as we're really good at forgetting about bugs that aren't. A patch would be great -- there is an @https test also, which obviously also needs attention. -- Philip Jenvey --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: pylons.decorators.secure.https throws away the query string ?
Pylons is used for quite a few hip and serious websites (listed at the pylons wiki if you'd care to look it up) though my guess is that you Which of those sites do you consider hip and/or serious ? On Jan 2, 4:26 pm, Alberto Valverde albe...@toscat.net wrote: Tycon wrote: So no one is using this decorator for https ?? I guess it's only required for serious e-commerce websites, maybe there are no such pylons apps Pylons is used for quite a few hip and serious websites (listed at the pylons wiki if you'd care to look it up) though my guess is that you already know that and the provocative innuendo is just a (quite un-original) technique to prompt a quick response. Anyway, a can think of a few causes for the lack of answers so far: 1) No one is using that decorator. 2) Someone is using but not in an action requiring query string parameters. 3) People are achieving the same effect with different techniques 4) People in a position to fix have aren't reading this 'cause they've taken some days off given that new-years' has been on a Thursday (eg: myself. However, my life's so sad that I'm at home on a Friday night, with my girlfirend, my cat, my Citadelle gin tonic, and my laptop; with obviously nothing better to do than feed some random internet troll) 5) People in a position to fix this are out of patience and have decided to ignore your posts. #1 I doubt since people don't usually submit code for the sake of it. #3 wouldn't be a surprise since the Pylons usually targeted to developers who have already a well equipped toolbox around. I'll place my bets on a combination of #3#4 (#3.5?), I believe it's too early for #5 yet, though you're approaching it a good speed... Now seriously. You've found a bug, congratulations and thanks That's already 2 in less than a week which is quire remarkable and it's certainly preferable an out-of-tone bug report than none at all. However, I think you'd be more positively considered around here if instead of bitching around you'd showed at least a little appreciation for the software you're using for free to build a serious e-commerce website which will probably bring you some revenue. Bonus points if you submit a patch for the bug you've found (you've already proved that you're perfectly capable of doing so) through the conventional channels (the bug tracker is usually the best place) and a unit-test for it if you feel extra-generous. Thanks, Alberto --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
pylons.decorators.secure.https throws away the query string ?
This decorator is supposed to redirect HTTP GET requests to HTTPS. But guess what ? The query string in the request URI is lost, so the redirected (https) request will not have any request.params even if the original (http) request did. --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Do beaker session store supports using memcached ?
if it's not a system service then why does it have it's own /etc/ init.d file (the way it's packaged for most major distributions) ? While it is possible to have a memcached server dedicated to one application, you can't assume this is the default. On Dec 31, 12:48 pm, Michael Bayer zzz...@gmail.com wrote: On Dec 31, 3:19 pm, Tycon adie...@gmail.com wrote: whatever you end up doing NEVER EVER DO a flush_all on memcached. Memcached is a global system service, it is not your private scratch pad. yessir ! though I've never considered a single memcached process as a global service, like say apache. since it's not bound to a public port or anything like that. --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Do beaker session store supports using memcached ?
Cause if I use this setting in development.ini : beaker.session.type = ext:memcached beaker.session.url = 127.0.0.1:11211 then if I try to access the session global, I get this error: NotImplementedError: Memcache caching does not support iteration of all cache keys This is raised from Module beaker.ext.memcached:76 in keys(). Am I doing something wrong, or is using memcahced store for sessions messed up ?? Everything works if I don't set the beaker.session.type in development.ini, cause then it's using the filesystem to store sessions. Funny that when using the filesystem it's pickling the session object and storing it in a file, but when trying to use memcached, it's actually trying to store each session attribute as a separate record in memcached. And the code in beaker.ext.memcached seems to actually do a flush_all of memcached when the session is to be removed ! hahahahaha - that means that it will flush everything else from memcached, unless it expects memcahced to be dedicated to only one session's data (at a time) Not to mention the expiration memchanism also doesnt seem to work, as any setting I tried it always called memcached with no expiration specified. Not that it matters cause of the above error nothing works anyway. --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Do beaker session store supports using memcached ?
Let me clarify that using memcached in beaker doesn't work ONLY FOR STORING SESSIONS. It does work for regular caching in beaker (e.g. using @beaker_cache decorator to cache controller actions etc). This is not a bug, it's basically an incorrect implementation, which uses wrong design and is completely untested. For storing sessions in mecached you need to do the same thing as when storing session in a file - pickle the session and store it as a single key in memcached. So you can update or remove the session object in a single mecached call, and all the sessions attributes will have the same expiration. Storing each session attribute as a separate record is incorrect because memcached doesn't allow you to update/iterate/delete groups of records together. On Dec 30, 2:51 pm, Mike Orr sluggos...@gmail.com wrote: On Tue, Dec 30, 2008 at 1:10 PM, Tycon adie...@gmail.com wrote: So I guess no one is actually using memcached for storing sessions ? Or of you do, do you define your own memcached interface instead of the Beaker memcached interface for session storage ? I haven't use memcached, and I doubt many Pylons applications do. Some of the problems you're describing look like they may be Beaker bugs, but I think Ben is the only one who knows enough about Beaker's internals to evaluate that. -- Mike Orr sluggos...@gmail.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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Monitoring tool for paster http server
Yes, it would be easy to add something like echo $(date) restarting... in the loop, but I reckon this is already logged in the paster log. As for a python monitoring tool, yes I said I'm aware of those, it's just that I don't want to waste 20MB for something that can be done by a shell script (admittedly still consuming 1-2MB, which is too much). A C program would be the best (e.g. daemontools), it's just that I don't like daemontools and I didn't want to spend the time writing a simplified daemontools-like program in C. On Dec 29, 6:31 am, Alex Marandon alex.maran...@gmail.com wrote: 2008/12/28 Tycon adie...@gmail.com: For people running the web app using paster http server (usually behind a web server acting as a reverse proxy), what kind of tool do you use to monitor your app server (e.g. paster) ? I've heard of supervisor, daemontools etc, but for my purpose a simple shell script which acts as a parent process of python/paster and just restarts it when it dies is sufficient. So, the script I came up with is : #!/bin/bash test -f $2 exit echo $$ $2 trap 'kill $!; rm $2; exit' SIGTERM while true; do $1 wait; sleep 20; done This looks fine although you could also try to fetch a page and make assertions on the response, to make sure your users are not getting a 500 for example. I would also add some logging, as you probably want to trace back when the server had to be restarted, maybe even with an email notification. This would be easier to do if the script was in Python :-) --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Monitoring tool for paster http server
The monitor script I presented is infinetly preferable to the cron-job approach. Like I mentioned, I think the asynchronuos model for monitoring is better and cleaner (that is, using a SIGCHLD event, instead of continuous checking if a process is still alive). On Dec 29, 6:59 am, Dalius Dobravolskas dalius.dobravols...@gmail.com wrote: On Mon, Dec 29, 2008 at 12:36 AM, Tycon adie...@gmail.com wrote: For people running the web app using paster http server (usually behind a web server acting as a reverse proxy), what kind of tool do you use to monitor your app server (e.g. paster) ? Check this solution as well:http://wiki.pylonshq.com/display/pylonscookbook/Scripts+for+paster+serve -- Daliushttp://blog.sandbox.lt --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Having some trouble upgrading to Pylons 0.9.7
Directories in URLS should ALWAYS have / at the end. That prevents a lot of confusion as well as help the web/app server that analyzes the URL to determine the proper prefixes. For example, to match anything under /static directory, you need to use a prefix pattern /static/ and not simply /static otherwise URLs such as /static1 will also match. The problem is that the URL /static will not match the pattern / static/, so that's why you always want your generated URLs to have a / after EACH directory in the URL. The only case you don't control is when the user goes to the root page of your domain (e.g. www.mysite.com) but luckily in that case the web server will treat this URLs path info as / On Nov 19, 9:05 am, Mike Orr sluggos...@gmail.com wrote: On Wed, Nov 19, 2008 at 7:28 AM, Raoul Snyman raoul.sny...@gmail.com wrote: Hi all, I'm attempting to upgrade my Pylons app to 0.9.7, but I can't seem to get past the 302 you will now be redirected problem. What I did was I created a totally new Pylons app, and then I started moving my controllers and models and things across. I'm not sure if this is the best way, but I figured it was most probably the easiest. I also read through the What's new in 0.9.7 document and the Upgrading document on the wiki, and followed directions as much as I could. I've left map.minimize on False, and I added the extra lines in my routes.py file as per the documentation. I also made sure that my middleware.py file had the necessary lines. I also modified base.py and the BaseController class, because my authentication system checks for a valid user in the __before__ function. Now the problem comes in that when I hit the main page, my default controller sees that there's no user logged in and tries to redirect me to the login page. Except it just sits there saying 302 Found The resource was found athttp://localhost:5000/member/login/;you should be redirected automatically. and never redirects me. routes.py:http://codepad.org/d4lpLxas middleware.py:http://codepad.org/kdnRbRpl base.py:http://codepad.org/qIvkBnxK Any idea what am I doing wrong? I have a similar authentication system in a Pylons 0.9.7 app so I can verify it works. Looking at your modules, I didn't know Routes had an .append_slash option but that could be throwing it off. There's no reason to put slashes at the end of URLs except to make it look like a directory to the user, but even then it's not necessary (/messages and /messages/1234 work fine). There's another redirect_to function in pylons.controllers.util which you should be using instead, as routes.redirect_to is being phased out. But they should both behave the same. You should be putting h.url_for() around all URLs, as that will adjust the URL if it needs a prefix someday. Or you can use Pylons 0.9.7's fancy url() object (pylons.url), which will be its replacement in Pylons 1.0. You can turn on route debugging to see if it gives any clues. Add this to development.ini: === [logger_routes] level = DEBUG handlers = qualname = routes.middleware === And add 'routes' to the 'keys' option in [loggers]. If none of these help, I would check your app under Live HTTP Headers to see what it's actually doing. The 302 response should have a Location: header with the absolute URL to redirect to. -- Mike Orr sluggos...@gmail.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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Monitoring tool for paster http server
For people running the web app using paster http server (usually behind a web server acting as a reverse proxy), what kind of tool do you use to monitor your app server (e.g. paster) ? I've heard of supervisor, daemontools etc, but for my purpose a simple shell script which acts as a parent process of python/paster and just restarts it when it dies is sufficient. So, the script I came up with is : #!/bin/bash test -f $2 exit echo $$ $2 trap 'kill $!; rm $2; exit' SIGTERM while true; do $1 wait; sleep 20; done You use it by passing the command you want to execute and the name of a file to store the process id (which must not exist beforehand), for example: $ monitor paster serve production.ini main.pid To terminate the monitor as well as the app it's monitoring (the monitor script will kill the child app as well as remove the pid file): $ kill $(cat main.pid) If for any reason the monitored application terminates, then the monitor script will restart it after 20 seconds. --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
how many people actually use authkit, formbuild or tosca-widgets ?
to me it seems like a waste of time to deal with some poorly written, poorly documented, poorly supported library that someone wrote with not much effort. Funny thing people spend way more time trying to figure out and use these libraries then either the time it took to write them or the time they can write their own (or use something better). Tosca especially is silly since there are many more serious widget libraries such as YUI. I'm just saying I wish I didnt waste the time on them, and as it is they represent a mine-field for people trying to start with pylons, as they will get frustrated by wasting time on trying to use these components (and it's even worse if they actually do use them instead of something better). So there should be a warning or something for noobs (hopefully this will be it). Not saying the people that wrote them didn't have good intentions, but you know what they say about the road to hell. --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Opinion sought on example.com/username
It's always a bad idea to mix different types of urls without having clearly defined separate prefixes for each. Basically it's like having a global namespace, and even worse is that you don't get ambiguity errors in case of overlaps, you get one url superseding the other (this also applies to static files hijacking a request with the same url, which I guess both rails and pylons do by default, and then for each request you actually have to check if a file with that name exists and only if not then dispatch the rails/pylons action == that is really bad programming, performance wise and logic wise). it's like having the home directories not be under /home so if you get a user named etc you r screw3d !!! On Dec 20, 1:07 pm, Mike Orr sluggos...@gmail.com wrote: On Sat, Dec 20, 2008 at 11:42 AM, Wichert Akkerman wich...@wiggy.net wrote: Previously ED209 wrote: I'm planning on moving my users' profile pages to: example.com/:username but there has been some discussion amongst fellow developers that this might cause problems. I would have this route and subsequent routes as the last ones defined in my array of routes defenitions so any static routes would be matched first. What if at some point in the future you need a new static route and a user already registered with that username? Well, that is where the Rails helpers' convention of /images, /stylesheets, and /javascripts makes some sense, because that way you only have to reserve a few prefixes. You could also reserve 'static' in case something else comes along that doesn't fit into these categories. -- Mike Orr sluggos...@gmail.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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Opinion sought on example.com/username
I use /static for all my static file, except maybe robots and favicon which cant be moved. As for StaticURLParser, using that as the first choice in the Cascade is wasteful cause it means pylons will do a file lookup for every request (bad performance) in addition to the fact that filenames may hijack pylons controller mapped routes (bad design calling for bugs). You can (and should) get rid of StaticURLParser and the Cascade if your web server is serving the static files (with a /static url prefix), or at least move StaticURLParser to the second choice in the Cascade when accessing the app directly from Paster http server (without a separate web server). On Dec 27, 12:54 am, Mike Orr sluggos...@gmail.com wrote: On Sat, Dec 27, 2008 at 12:33 AM, Tycon adie...@gmail.com wrote: It's always a bad idea to mix different types of urls without having clearly defined separate prefixes for each. Basically it's like having a global namespace, and even worse is that you don't get ambiguity errors in case of overlaps, you get one url superseding the other (this also applies to static files hijacking a request with the same url, which I guess both rails and pylons do by default, and then for each request you actually have to check if a file with that name exists and only if not then dispatch the rails/pylons action == that is really bad programming, performance wise and logic wise). it's like having the home directories not be under /home so if you get a user named etc you r screw3d !!! Pylons, or rather the StaticURLParser app in middleware.py, has the first chance at the URL and looks for a file in the public directory. If it can't find it, it returns an HTTP 404 and it then tries the Pylons application. (This is all done by the Cascade application in middleware.py.) Pylons could set up a prefix for all static files, but then people would complain they want another prefix or they need multiple directories. Plus, certain files like /robots.txt and /favicon.ico can't have a prefix. So Pylons punts and lets you put your static files under any URL. It's up to the programmer to choose one or a few easy-to-remember directories to put under it. I had an application in another framework (Quixote) where you had to set up static file handling manually. I put them all under a /static prefix. Then I had to set up two more handlers for robots and favicon, and then another for a directory of user-uploaded images. But I put all the help files under static because they were pregenerated HTML made by RoboHelp. When I converted the application to Pylons, I got rid of the /static prefix and was happier. -- Mike Orr sluggos...@gmail.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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: category support for flash
The webhelpers.pylonslib.Flash class is kind of poor. It's a bad idea to flash a message about a previous operation after redirecting to an unrelated page. It's just as bad to use the session as temp storage for such things (incurs filesystem/db access if you use multi-process design to serve the app, unless you use memcached but that doesnt work in beaker right now). It's best to use the c global and display an acknoledge page with the flash message(s) and let the user redirect using link(s) on this page. On Dec 19, 11:57 am, Wichert Akkerman wich...@wiggy.net wrote: Often it is very useful to have flash/status messages of several different types, for example to be able to differentiate between informational messages, warnings and errors. To do that I made a simple extension to WebHelpers to add category support to its Flash class. The change is completely backwards compatible, so if you do not need categories you will never notice them. Patch attached. Wichert. -- Wichert Akkerman wich...@wiggy.net It is simple to make things.http://www.wiggy.net/ It is hard to make things simple. category.diff 1KViewDownload --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Opinion sought on example.com/username
Hey thank for repeating what I said... when using a web server to serve the static files you should get rid of Cascade and staticURLParser. But the underlying question remains, how do you distinguish between static files and urls for which we defined dynamic controller actions ? One (bad) idea, is to first check if there is a static file matching the URL and serve it if it exists, otherwise try to find a dynamic controller action mapped to the URL. This behavior is the default for pylons and rails I believe. But like I said it has two main disadvantages : 1. You have to do a file lookup (e.g. system fstat() call) to determine if the static file exists before routing it to a controller. This is wasteful. 2. If a file exists with the same name as a URL defined in the route mapping for a dynamic controller action, then this file will be served instead of invoking the controller action. This can lead to bugs if you create a such a file by mistake. The above problems also happen in the case of using a web server that performs the static file existence check before proxying the request to pylons. Instead, it's MUCH better to separate the namespace by choosing different prefixes for static files and dynamic content. For example, all URLs for static files can start with /static, and/or all URLs for dynamic actions should start with /dynamic. There are TONS of fools on rails blogs/forums discussing what kind of apache directives to use to test for files existence to decide wether to serve the file or proxy the request etc. They don't understand that this whole problem could be solved with using URLs with different prefixes. Hope this clarifies my point On Dec 27, 4:59 pm, Mike Orr sluggos...@gmail.com wrote: On Sat, Dec 27, 2008 at 1:26 PM, Tycon adie...@gmail.com wrote: I use /static for all my static file, except maybe robots and favicon which cant be moved. As for StaticURLParser, using that as the first choice in the Cascade is wasteful cause it means pylons will do a file lookup for every request (bad performance) in addition to the fact that filenames may hijack pylons controller mapped routes (bad design calling for bugs). You can (and should) get rid of StaticURLParser and the Cascade if your web server is serving the static files (with a /static url prefix), or at least move StaticURLParser to the second choice in the Cascade when accessing the app directly from Paster http server (without a separate web server). My, he's opinionated. In a high-traffic situation you'd have Apache or your favorite webserver serve the static URLs before the application sees them, and then you can get rid of StaticURLParser and Cascade entirely. I'm not sure whether moving StaticURLParser after the Pylons application would be better or worse. My instinct is that it would be worse because a typical dynamic page has several static components. As for a filename hijacking a mapped route, I'm not sure what you mean. If you mean that with identical URLs, the static one is chosen, that's the programmer's problem; he should arrange the URLs so they don't overlap (and think about putting static files under a few well-known directories while he's at it). -- Mike Orr sluggos...@gmail.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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Pylons Eclipse Pydev
I wouldnt change the python executable (nor should you).
/usr/bin/paster is a python source file, not an executable, so it
should be passed
to the real python executable as the first argument, for example:
python /usr/bin/paster serve development.ini
or more generally (which should work for local virtual env as well):
python $(which paster) serve development.ini
On Nov 24, 10:02 am, SystemicPlural sky.wicken...@gmail.com wrote:
I've managed to fix this now.
In 'WindowPreferencesPydevInterpreter - Python' remove the python
interpreters and reload it (select 'New') after installing pylons.
In 'RunOpen Debug Dialog' enter the location of paster in 'Main
Module'. For me this is '/usr/bin/paster' . Then in the 'Arguments'
tab in Program arguments enter 'serve /locationOfYourProject/
development.ini'
All set to go.
It took a lot of search for me to find out that break points will not
work if the arguments includes '--reload'
On Nov 24, 8:54 am, SystemicPlural sky.wicken...@gmail.com wrote:
Thanks Dalius. I'm not sure what it did, but that half worked.
I can now run pylons from eclipse but the debug breakpoints are not
working. There are no errors.
Any more help?
On Nov 23, 8:01 pm, Dalius Dobravolskas
dalius.dobravols...@gmail.com wrote:
On Sun, Nov 23, 2008 at 6:48 PM, SystemicPlural sky.wicken...@gmail.com
wrote:
I am trying to get Pylons working in Eclipse with Pydev (Ubuntu)
I can't get it to run or debug.
I've re-imported the python interpreter.
In the run dialog I have the main module as: /usr/bin/paster and
program arguments as serve --reload /home/sky/www/PylonTest/
development.ini but when I run I just get a bunch of errors (below)
If I run
/usr/bin/paster serve --reload /home/sky/www/PylonTest/development.ini
in terminal the
/home/sky/www/PylonTest/
directory then it works, but from any other directory it does not.
why?
I get the same errors in the terminal as I do in eclipse.
(Pretty much a newbie to Ubuntu/Eclipse/Pydev and Pylons)
Starting subprocess with file monitor
Traceback (most recent call last):
File /usr/bin/paster, line 8, in module
load_entry_point('PasteScript==1.3.6', 'console_scripts', 'paster')
()
File /usr/lib/python2.5/site-packages/PasteScript-1.3.6-py2.5.egg/
paste/script/command.py, line 78, in run
invoke(command, command_name, options, args[1:])
File /usr/lib/python2.5/site-packages/PasteScript-1.3.6-py2.5.egg/
paste/script/command.py, line 117, in invoke
exit_code = runner.run(args)
File /usr/lib/python2.5/site-packages/PasteScript-1.3.6-py2.5.egg/
paste/script/command.py, line 212, in run
result = self.command()
File /usr/lib/python2.5/site-packages/PasteScript-1.3.6-py2.5.egg/
paste/script/serve.py, line 227, in command
relative_to=base, global_conf=vars)
File /usr/lib/python2.5/site-packages/PasteScript-1.3.6-py2.5.egg/
paste/script/serve.py, line 250, in loadapp
**kw)
File /usr/lib/python2.5/site-packages/PasteDeploy-1.3.1-py2.5.egg/
paste/deploy/loadwsgi.py, line 193, in loadapp
return loadobj(APP, uri, name=name, **kw)
File /usr/lib/python2.5/site-packages/PasteDeploy-1.3.1-py2.5.egg/
paste/deploy/loadwsgi.py, line 213, in loadobj
global_conf=global_conf)
File /usr/lib/python2.5/site-packages/PasteDeploy-1.3.1-py2.5.egg/
paste/deploy/loadwsgi.py, line 237, in loadcontext
global_conf=global_conf)
File /usr/lib/python2.5/site-packages/PasteDeploy-1.3.1-py2.5.egg/
paste/deploy/loadwsgi.py, line 267, in _loadconfig
return loader.get_context(object_type, name, global_conf)
File /usr/lib/python2.5/site-packages/PasteDeploy-1.3.1-py2.5.egg/
paste/deploy/loadwsgi.py, line 393, in get_context
section)
File /usr/lib/python2.5/site-packages/PasteDeploy-1.3.1-py2.5.egg/
paste/deploy/loadwsgi.py, line 415, in _context_from_use
object_type, name=use, global_conf=global_conf)
File /usr/lib/python2.5/site-packages/PasteDeploy-1.3.1-py2.5.egg/
paste/deploy/loadwsgi.py, line 345, in get_context
global_conf=global_conf)
File /usr/lib/python2.5/site-packages/PasteDeploy-1.3.1-py2.5.egg/
paste/deploy/loadwsgi.py, line 237, in loadcontext
global_conf=global_conf)
File /usr/lib/python2.5/site-packages/PasteDeploy-1.3.1-py2.5.egg/
paste/deploy/loadwsgi.py, line 274, in _loadegg
return loader.get_context(object_type, name, global_conf)
File /usr/lib/python2.5/site-packages/PasteDeploy-1.3.1-py2.5.egg/
paste/deploy/loadwsgi.py, line 542, in get_context
object_type, name=name)
File /usr/lib/python2.5/site-packages/PasteDeploy-1.3.1-py2.5.egg/
paste/deploy/loadwsgi.py, line 562, in find_egg_entry_point
pkg_resources.require(self.spec)
File /usr/lib/python2.5/site-packages/pkg_resources.py, line 626,
in require
Re: Problem with redirect_to and SSL
Right, when you use a reverse proxy setup, the proxy request is always
http (not https)
even if the original request was https.
Then I set up the web server (nginx in my case) to redirect HTTP
requests that have a https=on parameter to HTTPS,
In nginx, you can do it like this:
server {
listen 80;
server_name www.mysite.com;
if ($args ~ https=on) {
rewrite ^(.*)$ https://$server_name$1 redirect;
}
...
Similarly, I redirect from HTTPS to HTTP if there is a https=off
parameter in the request URI.
In pylons I verify that a request was originally received as HTTPS by
checking that the https=on param is present,
and if it's not then add it and redirect to HTTPS:
def verify_https(request):
if not request.params.get('https')=='on':
params=['%s=%s' % (k,v) for (k,v) in request.params.items() if k!
='https']
params.append('https=on')
redirect_to(str(request.environ['PATH_INFO']+'?'+''.join
(params)))
Then, you can write your controller action like this:
class MyController:
def secure(self):
h.verify_https(request)
return 'secured! '
So, if someone tries to access this action using HTTP, there will be
TWO redirects:
first, verify_https() will add the https=on param and redirect (to
HTTP), and then the web server will
see that param and redirect again to HTTPS. I'm not sure if it can be
done with a single redirect.
Also you can save one redirect if you create the URL for the secure
action with the https=on param already
present (in the link/url you create with url_for)
On Dec 22, 2:10 pm, Graham Dumpleton graham.dumple...@gmail.com
wrote:
The real problem here is probably because Pylons server is only
accepting HTTP connections and so wsgi.url_scheme in WSGi environment
is always 'http' and doesn't reflect that a connection is originally
being accepted by Apache as HTTPS.
For discussion of similar issue when nginx is used as proxy, accepting
both HTTP and HTTPS, and with Apache/mod_wsgi behind but only
accepting HTTP, see:
http://groups.google.com/group/modwsgi/browse_frm/thread/94f952720c87...
In short, you need to have proxy front end pass some indication that
HTTPS was used for original requests and use a WSGI middleware/
application wrapper check for that flag and reset wsgi.url_scheme to
correct value based on how request was accepted by the proxy.
Sure someone here can indicate best way of achieving this with Pylons.
Graham
On Dec 22, 9:36 pm, Andre Kolell andre.kol...@bluesummit.de wrote:
I solved the problem regarding redirect_to and SSL by using mod_rewrite to
redirect each http-request to https:
NameVirtualHost *:80
virtualhost *:80
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^/(.*) https://%{SERVER_NAME}%{REQUEST_URI} [R]
/virtualhost
I'm not sure if this is an adequate solution.
- Ursprüngliche Mail -
Von: Andre Kolell andre.kol...@bluesummit.de
An: pylons-discuss@googlegroups.com
Gesendet: Freitag, 19. Dezember 2008 16:51:57 GMT +01:00
Amsterdam/Berlin/Bern/Rom/Stockholm/Wien
Betreff: Problem with redirect_to and SSL
Hello,
I'm using Apache with SSL and use it's Proxy functionality to forward
requests to the local running Paster (with Pylons 0.9.7rc2). SSL and Links
work fine (with Mako). Only when Pylons comes to use the
redirect_to-function it always ends up in http- instead of
https-Connections. Using protocol='https' as a redirect_to-Parameter only
solves my problem at first view, but as I'm developing local without SSL,
it's not really a solution.
I also seems as if request.environ['wsgi.url_scheme'] gives me http
instead of https. May be redirect_to uses
request.environ['wsgi.url_scheme']?
Does anyone know why redirect_to doesn't use SSL-Connections and how I can
make redirect_to using them?
Best regards,
Andre
--~--~-~--~~~---~--~~
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
pylons-discuss+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
