dojo folder location
Hello, there. I'm just wondering where I should place the dojo folder on my project. I have created a project called myapp. And one of its sub-folders is also called myapp where you can find things like templates, controllers, etc. I'm pretty new to both pylons and dojo. Any help would be really appreciated. Thanks a lot in advance. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: WSGI Fails ImportError: No module named deploy
On Mon, Jun 16, 2008 at 3:48 PM, Chris Spencer [EMAIL PROTECTED] wrote: Turns out easy_install PasteDeploy installs to site-packages/PasteDeploy-1.3.1-py2.5.egg/paste/deploy instead of site-package/paste/deploy. Not sure why that's the default behavior... It's installing it as an egg. It puts an entry in site-packages/easy_install.pth to make python add the egg to sys.path. That's what easy_install always does. Because Pylons depends on other packages and also depends on setuptools, you can't just install it the old-fashioned way (python setup.py install). -- Mike Orr [EMAIL PROTECTED] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: best practices for static resources
Previously Cliff Wells wrote: On Mon, 2008-06-16 at 13:03 +0200, Wichert Akkerman wrote: I am trying to figure out what the best practices for dealing with static resources such as CSS, Javascript and images are. With a default pylons setup every request goes through two StaticURLParser instances and files returned by them do not get any caching headers. This is very practical for development but not ideal for a deployment For a deployment it would be nice to be able to serve static resources from apache or nginx. How do others do that? Do you use url_for to generate a URL for those static resources and have that return a non-paster/pylons URL for deployment environments and use the StaticURLParsers when running in in development mode? If so, how did you set that up? I usually just setup Nginx to handle whatever location my static content is at. It doesn't matter if Routes is setup to handle that location as the request never reaches Pylons. How do you do that during development? Do you hardcode /public/ paths for static resources everywhere? I'm starting to think that a best practice setup is something like: - instead of dumping static resources in / as currently done always put the in a private place, similar to how webhelper put its javascript files in /javascript/ - setup a separate route for static resources and always use url_for to them. I'm not entirely sure routes supports this at the moment. - setup a URLMap in development.ini so you can run the whole site with just paster - for production use a dedicated webserver to serve resources, possibly running on another host(name) even Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Plyons WSGI on Apache2.2
Previously Graham Dumpleton wrote: Read: http://code.google.com/p/modwsgi/wiki/ConfigurationIssues Not sure why you want run a single thread. From memory would only want to do that if trying to attach gdb to daemon process and debug at C code level. I tried to run with a single thread for a bit since egg:Paste#evalerror complained it doesnot work in a multi-thread environment, but it turns out it still complains even if you limit mod_wsgi to one thread. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Plyons WSGI on Apache2.2
On Jun 17, 6:55 pm, Wichert Akkerman [EMAIL PROTECTED] wrote: Previously Graham Dumpleton wrote: Read: http://code.google.com/p/modwsgi/wiki/ConfigurationIssues Not sure why you want run a single thread. From memory would only want to do that if trying to attach gdb to daemon process and debug at C code level. I tried to run with a single thread for a bit since egg:Paste#evalerror complained it doesnot work in a multi-thread environment, but it turns out it still complains even if you limit mod_wsgi to one thread. Is Paste#evalerror the same as EvalException or something different? Whatever it is, presuming it sees: wsgi.multithread: False in WSGI environment it should be satisfied that it is single threaded. If you can confirm what Python class #evalerror maps to, will have a quick look at what its requirements are. Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Plyons WSGI on Apache2.2
Previously Graham Dumpleton wrote: Is Paste#evalerror the same as EvalException or something different? It's an entry point which maps to paste.evalexception.middleware.make_eval_exception which indeed sets up EvalException. Looking at the code I must have misremembered: it does not support a multi-process environment, but does support multi-threading. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Plyons WSGI on Apache2.2
On Jun 17, 7:24 pm, Wichert Akkerman [EMAIL PROTECTED] wrote: Previously Graham Dumpleton wrote: Is Paste#evalerror the same as EvalException or something different? It's an entry point which maps to paste.evalexception.middleware.make_eval_exception which indeed sets up EvalException. Looking at the code I must have misremembered: it does not support a multi-process environment, but does support multi-threading. Which means that: WSGIDaemonProcess debug alone, ie., allowing default single process to be created, should be sufficient. Note, don't use: WSGIDaemonProcess processes=1 The use of 'processes' option with any number makes mod_wsgi think you have a multiprocess configuration and sets wsgi.multiprocess to be True as a default. Having thus subtle difference was probably not good in hindsight and should have allowed flagging of single process as being part of multi process configuration in a different way. FWIW, you would use 'processes=1' where want only one process on a specific Apache instance, but are loading balancing overall across multiple Apache installations. Need some way in that case to override wsgi.multiprocess so application knows that although only one process in this Apache instance, that may also be running elsewhere. Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: best practices for static resources
On Tue, 2008-06-17 at 10:36 +0200, Wichert Akkerman wrote: Previously Cliff Wells wrote: I usually just setup Nginx to handle whatever location my static content is at. It doesn't matter if Routes is setup to handle that location as the request never reaches Pylons. How do you do that during development? Do you hardcode /public/ paths for static resources everywhere? Actually, I never use webhelpers. I generally use hardcoded paths in my template and map them in the webserver, but don't see what the issue would be when using webhelpers. I don't see the whole process as being very complicated (nor any need to make it complicated). Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: best practices for static resources
El mar, 17-06-2008 a las 04:33 -0700, Cliff Wells escribió: On Tue, 2008-06-17 at 10:36 +0200, Wichert Akkerman wrote: Previously Cliff Wells wrote: I usually just setup Nginx to handle whatever location my static content is at. It doesn't matter if Routes is setup to handle that location as the request never reaches Pylons. How do you do that during development? Do you hardcode /public/ paths for static resources everywhere? Actually, I never use webhelpers. I generally use hardcoded paths in my template and map them in the webserver, but don't see what the issue would be when using webhelpers. I don't see the whole process as being very complicated (nor any need to make it complicated). Well, it can be complicated, for example, you are developing with paster in the url localhost:5000/ But, in production, your web is served under http://mydomain.com/cool/things/... I use the url_for for all static content, and with mod_wsgi all is transparent (thanks G. Dumpleton :), doesn't matter where you put your web root. Greetings. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: best practices for static resources
Previously Antonio Beamud Montero wrote: El mar, 17-06-2008 a las 04:33 -0700, Cliff Wells escribió: On Tue, 2008-06-17 at 10:36 +0200, Wichert Akkerman wrote: Previously Cliff Wells wrote: I usually just setup Nginx to handle whatever location my static content is at. It doesn't matter if Routes is setup to handle that location as the request never reaches Pylons. How do you do that during development? Do you hardcode /public/ paths for static resources everywhere? Actually, I never use webhelpers. I generally use hardcoded paths in my template and map them in the webserver, but don't see what the issue would be when using webhelpers. I don't see the whole process as being very complicated (nor any need to make it complicated). Well, it can be complicated, for example, you are developing with paster in the url localhost:5000/ But, in production, your web is served under http://mydomain.com/cool/things/... And then you want to scale up even further and have to offload static resources to another machine. You don't want to have to edit all your templates to do that. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: best practices for static resources
On Tue, 2008-06-17 at 14:23 +0200, Antonio Beamud Montero wrote: I use the url_for for all static content, and with mod_wsgi all is transparent (thanks G. Dumpleton :), doesn't matter where you put your web root. I have all my static content urls hardcoded, I was not able to figure out how to get url_for to work for them. I have all my static content in /public (served by apache). What do I need to do to get url_for working? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Pylons Empty Query Error Handling
Sorry I am a completely newbie to Pylons, Python, and I'm trying to built a web page with pylons.. so i got a page setup and have it query to my database for searching.. query is fine when user enter the correct arguments but when they are not below is a pylons pages with error log class 'sqlalchemy.exceptions.InvalidRequestError': No rows returned for one() is there anyway that i can make it a page display a alert or something to user? or search it anyway? thanks for your time and help --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Best possible webserver setup
Just trying to figure out the best combination for pylons: - Apache / Lighttpd - FCGI / Proxy / WSGI All the information I've found about relative performance seems to be rather outdated. I've played with Apache + FCGI and mod_wsgi quite a bit and it seems that FCGI is quite a lot faster. Is using mod_proxy faster still (as I think it used to be)? When using mod_wsgi, apache keeps track of the number of connections and the overflow. With mod_proxy is it the Paste http server or apache that makes sure that paste is not overwhelmed? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
custom domain mapping to a controller/id path?
i have this routing set up /user/id /user/id/project if you went to www.myhost.com/user/id, you'll see a page with a link on it generated by h.url_for() containing user/id/project thus bringing you to www.myhost.com/user/id/project i now want to map a custom domain that my webserver would rewrite as www.example1.com/(.*) = /user/1/$1 www.example2.com/(.*) = /user/2/$2 however, h.url_for() generates links from the root path, so i would end up on a 404 page like this www.example2.com/user/2/project instead of www.example2.com/ project ideally, i would want both www.example2.com and www.myhost.com/user/2 to both work, rather than to break one at the sacrafice of the other. has anyone come up with a satisfying approach to this? or is their a way to get h.url_for() to output URLs not set from the root webpath? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: custom domain mapping to a controller/id path?
create your own url_for function in helpers, and just wrap url_for
with it.
ie:
lib/helpers
def custom_url_for( name ):
domain = getDomain
if domain == 'a':
return '%s/%s' % ( url_for(name) , 'a' )
elif domain == 'b':
return '%s/%s' % ( url_for(name) , 'b' )
else:
raise ValueError('[EMAIL PROTECTED]@#!')
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: custom domain mapping to a controller/id path?
thanks. the disadvantage to your approach is that it requires my webapp to have knowledge about the domain pointing to it. however, i think i can modify it a bit, such that my custom_url_for() strips off the paths that are hidden during the url.rewrite done by the webserver. that way i can avoid hardcoding any domains, and will only have to hardcode which controller paths will be hidden (which is likely to only be one path). again, thanks for pointing me in a useful direction... --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: jsonp support
Shannon -jj Behrens wrote: I'm using the jsonify decorator. It'd be nice if that decorator were updated to *automatically* support the jsonp parameter http://bob.pythonmac.org/archives/2005/12/05/remote-json-jsonp/. Hence, if I request a URL like http://localhost:5000/api/service?jsonp=foo, and jsonify is used, it should automatically wrap the JSON in foo(). Isn't JSONP a security concern if you aren't exposing something intended to be public? That is, you can use JSONP to read data using the browser's credentials, which is sometimes okay and sometimes not. So optionally turning it on is nice, but always turning it on is dangerous. -- Ian Bicking : [EMAIL PROTECTED] : 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: jsonp support
On Tue, Jun 17, 2008 at 2:55 PM, Ian Bicking [EMAIL PROTECTED] wrote: Shannon -jj Behrens wrote: I'm using the jsonify decorator. It'd be nice if that decorator were updated to *automatically* support the jsonp parameter http://bob.pythonmac.org/archives/2005/12/05/remote-json-jsonp/. Hence, if I request a URL like http://localhost:5000/api/service?jsonp=foo, and jsonify is used, it should automatically wrap the JSON in foo(). Isn't JSONP a security concern if you aren't exposing something intended to be public? That is, you can use JSONP to read data using the browser's credentials, which is sometimes okay and sometimes not. So optionally turning it on is nice, but always turning it on is dangerous. I can't comment on that. My service is a public service. Perhaps you can explain what you mean in more detail. Bob talks about security a bit on his blog post: http://bob.pythonmac.org/archives/2005/12/05/remote-json-jsonp/. -jj -- I, for one, welcome our new Facebook overlords! http://jjinux.blogspot.com/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: jsonp support
On Tue, Jun 17, 2008 at 3:21 PM, Shannon -jj Behrens [EMAIL PROTECTED] wrote: On Tue, Jun 17, 2008 at 2:55 PM, Ian Bicking [EMAIL PROTECTED] wrote: Shannon -jj Behrens wrote: I'm using the jsonify decorator. It'd be nice if that decorator were updated to *automatically* support the jsonp parameter http://bob.pythonmac.org/archives/2005/12/05/remote-json-jsonp/. Hence, if I request a URL like http://localhost:5000/api/service?jsonp=foo, and jsonify is used, it should automatically wrap the JSON in foo(). Isn't JSONP a security concern if you aren't exposing something intended to be public? That is, you can use JSONP to read data using the browser's credentials, which is sometimes okay and sometimes not. So optionally turning it on is nice, but always turning it on is dangerous. I can't comment on that. My service is a public service. Perhaps you can explain what you mean in more detail. Bob talks about security a bit on his blog post: http://bob.pythonmac.org/archives/2005/12/05/remote-json-jsonp/. The JavaScript does have to *trust* the remote server. Of course, if it doesn't, it shouldn't be using script tags to pull stuff from that remote server. -jj -- I, for one, welcome our new Facebook overlords! http://jjinux.blogspot.com/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: jsonp support
Shannon -jj Behrens wrote: On Tue, Jun 17, 2008 at 2:55 PM, Ian Bicking [EMAIL PROTECTED] wrote: Shannon -jj Behrens wrote: I'm using the jsonify decorator. It'd be nice if that decorator were updated to *automatically* support the jsonp parameter http://bob.pythonmac.org/archives/2005/12/05/remote-json-jsonp/. Hence, if I request a URL like http://localhost:5000/api/service?jsonp=foo, and jsonify is used, it should automatically wrap the JSON in foo(). Isn't JSONP a security concern if you aren't exposing something intended to be public? That is, you can use JSONP to read data using the browser's credentials, which is sometimes okay and sometimes not. So optionally turning it on is nice, but always turning it on is dangerous. I can't comment on that. My service is a public service. Perhaps you can explain what you mean in more detail. Bob talks about security a bit on his blog post: http://bob.pythonmac.org/archives/2005/12/05/remote-json-jsonp/. Let's say I have a JSON method that returns your list of friends. That's private, and the method is restricted based on authentication. But any random website could include this: script src=http://somesocialnetwork.org/api/friends?jsonp=readFriends;/script and then it would be able to read your private list of friends if you had logged into somesocialnetwork.org. Simply requiring people to explicitly turn on jsonp support, with a warning that only public data should be exposed that way, would address that issue. -- Ian Bicking : [EMAIL PROTECTED] : 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: custom domain mapping to a controller/id path?
i've included my custom url_for() function below.
since the point of the custom domain mappings is to 'hide' a
controller from the URL, the function exploits this when rewriting
urls returned by h.url_for().
if the request_uri string contains a reference to the controller, then
we are not using the custom domain mapping and we don't need to mangle
h.url_for()'s results. however, if it is missing, then we are using a
custom domain that hides the path to the controller, and we need to
make sure h.url_for() does not include a reference to it.
i still need some fine tuning (edge cases, or if i decide to hide a
controller+action from the url), but i seem to be on the right track
with this
def url_for(*p, **k):
url = h.url_for(*p, **k)
path =
request.environ['REQUEST_URI'].replace(request.environ['QUERY_STRING'],
'')
cont = request.environ.get('pylons.routes_dict').get('controller')
if path.find(cont) != -1:
return url
else:
return re.sub('^/' + cont + '/?', '/', url)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: jsonp support
On Tue, Jun 17, 2008 at 3:25 PM, Ian Bicking [EMAIL PROTECTED] wrote: Shannon -jj Behrens wrote: On Tue, Jun 17, 2008 at 2:55 PM, Ian Bicking [EMAIL PROTECTED] wrote: Shannon -jj Behrens wrote: I'm using the jsonify decorator. It'd be nice if that decorator were updated to *automatically* support the jsonp parameter http://bob.pythonmac.org/archives/2005/12/05/remote-json-jsonp/. Hence, if I request a URL like http://localhost:5000/api/service?jsonp=foo, and jsonify is used, it should automatically wrap the JSON in foo(). Isn't JSONP a security concern if you aren't exposing something intended to be public? That is, you can use JSONP to read data using the browser's credentials, which is sometimes okay and sometimes not. So optionally turning it on is nice, but always turning it on is dangerous. I can't comment on that. My service is a public service. Perhaps you can explain what you mean in more detail. Bob talks about security a bit on his blog post: http://bob.pythonmac.org/archives/2005/12/05/remote-json-jsonp/. Let's say I have a JSON method that returns your list of friends. That's private, and the method is restricted based on authentication. But any random website could include this: script src=http://somesocialnetwork.org/api/friends?jsonp=readFriends;/script and then it would be able to read your private list of friends if you had logged into somesocialnetwork.org. Simply requiring people to explicitly turn on jsonp support, with a warning that only public data should be exposed that way, would address that issue. Good point. So you're saying that if you don't use jsonp, then when the attacker causes the victim to view a script tag that pulls stuff down via JSON, since there's no function to receive the JSON, it gets pulled down, but immediately disappears, right? What a strange defense mechanism. XSRF is a pain, eh? I'm okay with needing to turn on jsonp support. If there were a jsonp flag for the jsonify decorator, then you could enable it in as few places as possible. Best Regards, -jj -- I, for one, welcome our new Facebook overlords! http://jjinux.blogspot.com/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: WebHelpers-dev change: select() option order
On Tue, Jun 17, 2008 at 2:52 PM, Mike Orr [EMAIL PROTECTED] wrote:
The option order in webhelpers.html.tags.select() has changed from
[(label, value)] to [(value, label)]. This matches most real-world
lists including dict.items() where the dict is {id : label}. It's the
opposite of the old rails helper options_for_select(), however.
There are tradeoffs both ways. Now to display lables alphabetically
you have to do:
sorted(my_options, key=lambda x: x[1])
However, I was finding that the other order causes way too many:
[(x[1], x[0]) for x in some_list]
I fear that this is too likely to cause weird bugs for people.
Perhaps you should create a new method name. You can have the old one
defined in terms of the new, and then deprecate it.
-jj
--
I, for one, welcome our new Facebook overlords!
http://jjinux.blogspot.com/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: WebHelpers-dev change: select() option order
On Tue, Jun 17, 2008 at 7:48 PM, Shannon -jj Behrens [EMAIL PROTECTED] wrote:
On Tue, Jun 17, 2008 at 2:52 PM, Mike Orr [EMAIL PROTECTED] wrote:
The option order in webhelpers.html.tags.select() has changed from
[(label, value)] to [(value, label)]. This matches most real-world
lists including dict.items() where the dict is {id : label}. It's the
opposite of the old rails helper options_for_select(), however.
There are tradeoffs both ways. Now to display lables alphabetically
you have to do:
sorted(my_options, key=lambda x: x[1])
However, I was finding that the other order causes way too many:
[(x[1], x[0]) for x in some_list]
I fear that this is too likely to cause weird bugs for people.
Perhaps you should create a new method name. You can have the old one
defined in terms of the new, and then deprecate it.
Perhaps I misread your email. You're creating a new API, not
refactoring an existing API, right? If so, then please disregard my
comment.
-jj
--
I, for one, welcome our new Facebook overlords!
http://jjinux.blogspot.com/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: best practices for static resources
On Mon, Jun 16, 2008 at 2:37 PM, Cliff Wells [EMAIL PROTECTED] wrote:
On Mon, 2008-06-16 at 14:26 -0700, Cliff Wells wrote:
On Mon, 2008-06-16 at 13:03 +0200, Wichert Akkerman wrote:
I am trying to figure out what the best practices for dealing with
static resources such as CSS, Javascript and images are. With a
default pylons setup every request goes through two StaticURLParser
instances and files returned by them do not get any caching headers.
This is very practical for development but not ideal for a deployment
For a deployment it would be nice to be able to serve static resources
from apache or nginx.
How do others do that? Do you use url_for to generate a URL for those
static resources and have that return a non-paster/pylons URL for
deployment environments and use the StaticURLParsers when running in
in development mode? If so, how did you set that up?
I usually just setup Nginx to handle whatever location my static content
is at. It doesn't matter if Routes is setup to handle that location as
the request never reaches Pylons.
Here's an example:
server {
server_name *.domain.com;
listen 1.2.3.4:80;
location /public/ {
root/var/www/myapp;
expires 30d;
}
location / {
proxy_pass http://127.0.0.1:8000$request_uri;
include/etc/nginx/proxy.conf; # common settings for proxying
}
}
In this case, any request for, say /public/css/style.css would map to
/var/www/myapp/public/css/style.css.
Regards,
Cliff
I let Nginx handle the URL if such a file exists. Otherwise, I let
Pylons have a shot at it:
...
server {
listen 80;
server_name localhost;
location / {
# Let Nginx handle static content, but proxy to paster for all the
# dynamic content.
root/.../wwwaiter/wwwaiter/public;
if (!-e $request_filename) {
proxy_pass http://127.0.0.1:5000;
}
}
That way I don't have to include public in my URLs ;-)
(Of course, including public in the URL would probably make life
easier if I needed to move to something more complicated like a CDN.)
-jj
--
I, for one, welcome our new Facebook overlords!
http://jjinux.blogspot.com/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: Adding content-length in all responses
On Mon, Jun 16, 2008 at 4:11 PM, Agustín (Cucho) Villena [EMAIL PROTECTED] wrote: Hi! At work we need to add the content-length header in all our responses, but we don't want to hack any method in our controllers to do that. Is there any way to factor out this behaviour in a single place? Can you use Apache or Nginx to do that for you? -jj -- I, for one, welcome our new Facebook overlords! http://jjinux.blogspot.com/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Pylons-based JSON-RPC service?
On Sun, Jun 15, 2008 at 1:12 PM, KJ [EMAIL PROTECTED] wrote: Would Pylons be a good choice for implementing a JSON-RPC-based web service? If yes, can someone point me to a good example? (Actually, I'd be interested in seeing examples of any Pylons-based web service, even if it doesn't use JSON.) If not what other framework would more suited for this task? I decided to implement a RESTful, JSON API instead of using JSON-RPC. That means: * All the parameters are put in GET and POST parameters. * I shove as much stuff in the URL as makes sense. * I use HTTP response codes to indicate errors. * I put whatever the heck I want in the JSON response. * I use a JSON response for both successes and many failures. It's not as brain-dead simple as XML-RPC use to be, but it's working for me. Reading the Wikipedia page on REST was helpful for me. Best Regards, -jj -- I, for one, welcome our new Facebook overlords! http://jjinux.blogspot.com/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: WebHelpers-dev change: select() option order
On Tue, Jun 17, 2008 at 7:49 PM, Shannon -jj Behrens [EMAIL PROTECTED] wrote:
On Tue, Jun 17, 2008 at 7:48 PM, Shannon -jj Behrens [EMAIL PROTECTED]
wrote:
On Tue, Jun 17, 2008 at 2:52 PM, Mike Orr [EMAIL PROTECTED] wrote:
The option order in webhelpers.html.tags.select() has changed from
[(label, value)] to [(value, label)]. This matches most real-world
lists including dict.items() where the dict is {id : label}. It's the
opposite of the old rails helper options_for_select(), however.
There are tradeoffs both ways. Now to display lables alphabetically
you have to do:
sorted(my_options, key=lambda x: x[1])
However, I was finding that the other order causes way too many:
[(x[1], x[0]) for x in some_list]
I fear that this is too likely to cause weird bugs for people.
Perhaps you should create a new method name. You can have the old one
defined in terms of the new, and then deprecate it.
Perhaps I misread your email. You're creating a new API, not
refactoring an existing API, right? If so, then please disregard my
comment.
It's a change in the development version of WebHelpers, which by
definition is not stable. There's no way to rename select() without
making it worse forever, because select is clearly the optimal name
by far.
--
Mike Orr [EMAIL PROTECTED]
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
