Re: What should I use to generate forms on the fly?
On Feb 14, 2007, at 11:25 AM, Max Ischenko wrote: Hi, Thank you for the quick answer. I'm wondering if I should go with formbuild or ToscaWidgets. Which of the two is more likely to be a stable solution in the near future? Hard question. I haven't used formbuild myself and ToscaWidgets is certainly not stable yet and I have no idea when it stabilize. I can suggest spend some time with both (starting with TW) and make your opinion. And look into source code, because chances are you may need to hack it. ;) I'd like to add that ToscaWidgets is already aiming for API stabilization since I released a first alpha a few weeks ago. I'm making heavy use of them in some projects and they're certainly stable in the sense that they don't break mysteriously ;). The desperately need some docs though... for sure, but there's a surprise regarding this in a few weeks... :) 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
when paster is 'serving' does it respond to any request? (I.e. is my problem the firewall?)
I just put my app on another box but can't hit it, is the problem probably the firewall? I.e. my development.ini has: [server:main] use = egg:Paste#http host = 0.0.0.0 port = 5000 Does it answer any request on 5000? Is there anywhere that explains what the different development.ini values are for? Assuming the above is correct, might it be a useful feature to allow a subnet mask so that paster only answered things matching the mask? If the assumption is not correct, is there a way to tell paster to answer requests that are not just from localhost? Cheers, John --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: when paster is 'serving' does it respond to any request? (I.e. is my problem the firewall?)
On 2/14/07, John_Nowlan [EMAIL PROTECTED] wrote: I just put my app on another box but can't hit it, is the problem probably the firewall? I'd imagine so. If you have ssh access to the other box, try: ssh -N -L 5000:localhost:5000 [EMAIL PROTECTED] This should forward port 5000 from your other box to port 5000 on your local machine. If you do this and you can see your app by connecting to http://localhost:5000/, the problem is with the firewall. Best wishes, Hamish --~--~-~--~~~---~--~~ 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: when paster is 'serving' does it respond to any request? (I.e. is my problem the firewall?)
On 2/14/07, John_Nowlan [EMAIL PROTECTED] wrote: I just put my app on another box but can't hit it, is the problem probably the firewall? I.e. my development.ini has: [server:main] use = egg:Paste#http host = 0.0.0.0 port = 5000 Does it answer any request on 5000? I do believe 0.0.0.0 means it should bind to all interfaces. Is there anywhere that explains what the different development.ini values are for? Assuming the above is correct, might it be a useful feature to allow a subnet mask so that paster only answered things matching the mask? You can do things like set host = 127.0.0.1 so that it only listens on localhost. If you want to get really fancy, you should probably setup the rules in your firewall since that's what it's made to do. Alternatively, you can use tcpwrappers. If the assumption is not correct, is there a way to tell paster to answer requests that are not just from localhost? You already are. I like the tip given by Hamish, but I also find it helpful to try telneting to the server instead of using a browser: telnet localhost 5001(~/work/foxmarks/src/foxmarks/apps/acctmgr) Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. GET / HTTP/1.0 HTTP/1.0 200 OK Server: PasteWSGIServer/0.5 Python/2.4.4c1 Date: Wed, 14 Feb 2007 21:34:32 GMT content-type: text/html; charset=UTF-8 Connection: close html... Telnet will tell you if it's not able to connect. Happy Hacking! -jj -- 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, genshi and xml
On 2/13/07, Ben Bangert [EMAIL PROTECTED] wrote:
On Feb 11, 2007, at 5:26 PM, Bob Ippolito wrote:
That is annoying... but not annoying enough to where I've gone and
tried to figure out where to make that change. I'd be curious as to
what the workaround is for that one.
As Matt mentions, this is intentional behavior due to how TurboGears
expects them to be module's. I'd like to look into a small extension
to the TG plugin so that one could indicate somewhere that they don't
want the template name 'mangled' on the way in (ie, have the template
extension added).
That's a problem with the way Pylons works with buffet. It's
impossible to do it with a render call, because it doesn't give you an
opportunity to pass in a format parameter. You need to basically go
behind the scenes and do what render() is doing. Here's an example of
what I'm using:
def render_atom(template_name, **namespace):
content = pylons.buffet.render(
template_name=template_name,
fragment=False,
namespace=namespace,
format='xml',
)
return Response(content, mimetype='application/atom+xml')
This has been fixed in r1859. You can now do:
return render_response('/some/template.xml', format='xml')
A lot of people want to change the mimetype at the same time they
render a template, so I'm considering adding that option directly to
render_response as well. I'm only slightly hesitant because keyword
options go into the template's namespace, and I'd like to keep it as
obvious as possible which names go to the template engine, and which
to the response object (in the case of mimetype).
It looks like it renders the whole document in memory before
sending it out.
This is a huge problem for templates where the result is large (like
above). The obvious problem is that it blows out memory on the
server side
for no reason. Another problem though is the latency as the
client must
wait until the whole page is generated before it sees any of the
response.
From what I've read it sounds like genshi is very stream oriented,
so it
shouldn't need to build all of it up in memory before it can start
streaming
the results out or did I misunderstand this? Is it the Response
object (or
pylons) that requires a full result prior to sending anything back?
Regardless of what actually causes it, how do I fix it?
As long as the template renderer returns a generator, then it'll
output as its done. I'm not sure how the Genshi plugin is written, or
whether its render output is returned as a string, or a generator.
I'm guessing its returned as a string which means you'd need to go to
raw Genshi itself to get back a generator and set that as the content
for a Response object.
Yep, instead of using render_response which renders the template and
puts it into a response, you should piece together a Response object,
passing a generator for content. Then, in this generator, you can use
Genshi to spit back a piece at a time. I've done this for CSV using
the csv module. A good test to see if you have the generators
working right is to use the following as your generator:
import itertools
def numbers():
for num in itertools.count():
yield %s\n % num
Then, view the page and watch the numbers scroll down. If you use
telnet instead of a browser, you get a remote counting server :-D
Happy Hacking!
-jj
--
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: WSGIRequest.charset and WSGIRequest.defaults
On 2/13/07, Max Ischenko [EMAIL PROTECTED] wrote: On Feb 13, 1:49 am, Shannon -jj Behrens [EMAIL PROTECTED] wrote: Awesome! Look at the cool diff I had to apply to my code: def decode_request(request, encoding=UTF-8, errors=strict): I have the following in base.py: def __call__(self, environ, start_response): decode_request(request) return WSGIController.__call__(self, environ, start_response) It's working. However, the other day, Ben dumped the following on me: If you do it in your middleware.py: # Return our loaded config object request_settings = dict(charset='UTF-8', errors='replace') return pylons.config.Config(tmpl_options, map, paths, request_settings=request_settings) However, my middleware.py doesn't look like that, so I'm still investigating the final answer. Best Regards, -jj -- 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, genshi and xml
On Feb 14, 2007, at 2:02 PM, Bob Ippolito wrote:
This just seems like a bad API decision. The namespace should really
be a dict argument rather than trying to mince it together with the
other arguments that do entirely different things. The current API is
just really unnatural.
In all of my controllers the namespace is already a separate dict, but
I have to **args it in (and hope that I don't use some name that the
render function cares about).
Agreed, I'd like to change it to take a dict that goes to the
namespace of the template though that'll probably break a few
people's projects. Most people are using the 'c' object to pass
variables so they won't be affected. I'll take a look at making it
able to take a dict as the first arg which it'd then use as the
namespace, and throw a deprecation warning for 0.9.5 should a full
set of keyword args be passed indicating that it should be switched
to a dict.
Ie:
render_response('/some/template',dict(arg='val'), format='xml')
Or if you want to do it all with keyword args:
render_response('/some/template', namespace=dict(arg='val'),
format='xml')
As none of the Response init args conflict with the Buffet render
args, I don't see any harm in letting you put keyword options like
mimetype in there that go to the Response object created. How's that
look?
Cheers,
Ben
--~--~-~--~~~---~--~~
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: WSGIRequest.charset and WSGIRequest.defaults
On Feb 14, 2007, at 2:24 PM, Shannon -jj Behrens wrote: It's working. However, the other day, Ben dumped the following on me: If you do it in your middleware.py: # Return our loaded config object request_settings = dict(charset='UTF-8', errors='replace') return pylons.config.Config(tmpl_options, map, paths, request_settings=request_settings) However, my middleware.py doesn't look like that, so I'm still investigating the final answer. I apparently wasn't paying attention to what file that was in. The Config object is made in environment.py, so you'd actually add that in there. Cheers, Ben --~--~-~--~~~---~--~~ 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: AuthKit and AuthDemo
On 2/11/07, Hamish [EMAIL PROTECTED] wrote:
Hi,
I'm new to Pylons but have heard good things about it and thought I
might give it a try for a simple web app I need to write.
I need some simple cookie-based authentication: the user should
initially be presented with a page asking for their email address; an
email should be sent to that address containing a link; when the user
visits that link, an association is made between cookie and email
address. If the user subsequently deletes the cookie, they will get a
new one and will need to associate it with their email address again
in the same way.
Would AuthKit be suitable for this? Would something more lightweight
be better?
Also, I tried to install AuthDemo but get:
pkg_resources.VersionConflict: (web 0.6.0 (/Library/Frameworks/
Python.framework/Versions/2.4/lib/python2.4/site-packages/web-0.6.0-
py2.4.egg), Requirement.parse('web=0.6.1,0.7'))
I can't find web0.6.0, and neither can easy_install. It's a bit
difficult to google for a package called web, can anyone point me to
where I might find a later version?
I rolled my own account management functionality using paste.auth.
However, I hope that, if not now, then one day this will be easier for
everyone else. Especially with all the business of sending out a
confirmation email, etc., this stuff can get tricky. Tell me how it
goes.
Best Regards,
-jj
--
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, genshi and xml
On 2/14/07, Ben Bangert [EMAIL PROTECTED] wrote:
On Feb 14, 2007, at 2:02 PM, Bob Ippolito wrote:
This just seems like a bad API decision. The namespace should really
be a dict argument rather than trying to mince it together with the
other arguments that do entirely different things. The current API is
just really unnatural.
In all of my controllers the namespace is already a separate dict, but
I have to **args it in (and hope that I don't use some name that the
render function cares about).
Agreed, I'd like to change it to take a dict that goes to the
namespace of the template though that'll probably break a few
people's projects. Most people are using the 'c' object to pass
variables so they won't be affected. I'll take a look at making it
able to take a dict as the first arg which it'd then use as the
namespace, and throw a deprecation warning for 0.9.5 should a full
set of keyword args be passed indicating that it should be switched
to a dict.
Ie:
render_response('/some/template',dict(arg='val'), format='xml')
Or if you want to do it all with keyword args:
render_response('/some/template', namespace=dict(arg='val'),
format='xml')
As none of the Response init args conflict with the Buffet render
args, I don't see any harm in letting you put keyword options like
mimetype in there that go to the Response object created. How's that
look?
+0.5
Anyway, the docs tell you to use c.
Happy Hacking,
-jj
--
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: Customizing SQLAlchemy connections
On 2/11/07, Max Ischenko [EMAIL PROTECTED] wrote: Hi, On Feb 10, 10:16 pm, Philip Jenvey [EMAIL PROTECTED] wrote: We definitely need to solve this somehow for 0.9.5. I was already thinking about adding *kwargs to create_engine, and possibly adding kwargs to make_session and having them passthru to create_engine. I think some might want to also pass specific arguments to SQLAlchemy's create_session call too, though. I'd prefer to set this in make_app(), along with other configuration. E.g. set some config dict which is then took into account by pylons.database. Can you configure an egg-style entry point for configuring the connection in the .ini? Best Regards, -jj -- 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, genshi and xml
On 2/14/07, Shannon -jj Behrens [EMAIL PROTECTED] wrote:
On 2/14/07, Ben Bangert [EMAIL PROTECTED] wrote:
On Feb 14, 2007, at 2:02 PM, Bob Ippolito wrote:
This just seems like a bad API decision. The namespace should really
be a dict argument rather than trying to mince it together with the
other arguments that do entirely different things. The current API is
just really unnatural.
In all of my controllers the namespace is already a separate dict, but
I have to **args it in (and hope that I don't use some name that the
render function cares about).
Agreed, I'd like to change it to take a dict that goes to the
namespace of the template though that'll probably break a few
people's projects. Most people are using the 'c' object to pass
variables so they won't be affected. I'll take a look at making it
able to take a dict as the first arg which it'd then use as the
namespace, and throw a deprecation warning for 0.9.5 should a full
set of keyword args be passed indicating that it should be switched
to a dict.
Ie:
render_response('/some/template',dict(arg='val'), format='xml')
Or if you want to do it all with keyword args:
render_response('/some/template', namespace=dict(arg='val'),
format='xml')
As none of the Response init args conflict with the Buffet render
args, I don't see any harm in letting you put keyword options like
mimetype in there that go to the Response object created. How's that
look?
+0.5
Anyway, the docs tell you to use c.
They do, but my templates are all ported over from TurboGears, which
uses a flat namespace. I'm not using c at all.
-bob
--~--~-~--~~~---~--~~
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: WSGIRequest.charset and WSGIRequest.defaults
On Feb 14, 2007, at 2:24 PM, Shannon -jj Behrens wrote: On 2/13/07, Max Ischenko [EMAIL PROTECTED] wrote: On Feb 13, 1:49 am, Shannon -jj Behrens [EMAIL PROTECTED] wrote: Awesome! Look at the cool diff I had to apply to my code: def decode_request(request, encoding=UTF-8, errors=strict): I have the following in base.py: def __call__(self, environ, start_response): decode_request(request) return WSGIController.__call__(self, environ, start_response) It's working. However, the other day, Ben dumped the following on me: If you do it in your middleware.py: # Return our loaded config object request_settings = dict(charset='UTF-8', errors='replace') return pylons.config.Config(tmpl_options, map, paths, request_settings=request_settings) However, my middleware.py doesn't look like that, so I'm still investigating the final answer. He must have meant environment.py. That code is straight from the docs I linked to earlier in this thread. http://pylonshq.com/project/pylonshq/browser/Pylons/trunk/docs/ internationalization.txt?order=name#L519 Let me know if they're unclear about anything. -- 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: New document -- first Pylons site how-to
On Feb 13, 8:25 pm, Jamie [EMAIL PROTECTED] wrote: Nicely done :-) Yeah, I was one of the ones complaining about the docs about a month back. I've since learned that the official docs aren't really as bad I originally thought. The main problem seems to be lack of organization. And the fact that Pylons uses so many third-party components makes that even more difficult. It's good to see a super-basic CRUD app from start to finish. Though I'm a bit confused as to why you're doing everything within a single action in you controller? It seems to be reminiscent of the old way of doing web development by posting back everything to the same URL. It might be more flexible to break things up a bit. Good question. Here is one answer -- This document is not intended to teach how to structure an application. This doc is an attempt to help a new Pylons user to handle some of the initial tasks that most new Pylons users will need to deal with. You are past that stage, now. So, your question about how to structure a Pylons application is more advanced. OK. Enough excuse making. This document does not answer questions about how to structure a Pylons application because I don't know how to do that. Maybe you can instruct me on application structure. Dave --~--~-~--~~~---~--~~ 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: New document -- first Pylons site how-to
Dave This document does not answer questions about how to structure a Dave Pylons application because I don't know how to do that. Maybe you Dave can instruct me on application structure. I'd also be interested in a what-goes-where-and-why tutorial. -- Skip Montanaro - [EMAIL PROTECTED] - http://www.webfast.com/~skip/ The hippies and the hipsters did some great stuff in the sixties, but the geeks pulled their weight too. -- Billy Bragg --~--~-~--~~~---~--~~ 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: WSGIRequest.charset and WSGIRequest.defaults
On 2/14/07, Philip Jenvey [EMAIL PROTECTED] wrote: On Feb 14, 2007, at 2:24 PM, Shannon -jj Behrens wrote: On 2/13/07, Max Ischenko [EMAIL PROTECTED] wrote: On Feb 13, 1:49 am, Shannon -jj Behrens [EMAIL PROTECTED] wrote: Awesome! Look at the cool diff I had to apply to my code: def decode_request(request, encoding=UTF-8, errors=strict): I have the following in base.py: def __call__(self, environ, start_response): decode_request(request) return WSGIController.__call__(self, environ, start_response) It's working. However, the other day, Ben dumped the following on me: If you do it in your middleware.py: # Return our loaded config object request_settings = dict(charset='UTF-8', errors='replace') return pylons.config.Config(tmpl_options, map, paths, request_settings=request_settings) However, my middleware.py doesn't look like that, so I'm still investigating the final answer. He must have meant environment.py. That code is straight from the docs I linked to earlier in this thread. http://pylonshq.com/project/pylonshq/browser/Pylons/trunk/docs/ internationalization.txt?order=name#L519 Let me know if they're unclear about anything. Ok, thanks. Sorry for being such a dufus ;) RTFM! -jj -- 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: So may ways to get config values
On Feb 14, 2007, at 2:20 PM, Shannon -jj Behrens wrote:
On 2/13/07, Mike Orr [EMAIL PROTECTED] wrote:
Pylons offers so many ways to get config values, I don't know
which to
choose when. If the WSGI environment is active I can get it from
there, or from one of the one-letter globals (can't find which one
now), or from the CONFIG, or from pylons.util.config_get(), and no
doubt other places.
The thing is, I'd like one way which would just always work no matter
what state the application is in. pylons.util.config_get() would be
ideal for this but it contains a docstring: This is for Pylons
internal use only. Why?
This is a goofy method that's intended to support projects using
either the current paste.deploy.CONFIG or for the future, the new
paste.config.CONFIG object.
paste.config.CONFIG is a rewrite of paste.deploy.CONFIG as a
StackedObjectProxy. We're intending to deprecate (or just move
everyone over from) paste.deploy.CONFIG for it in the future, but not
just yet (although maybe now would be the appropriate time).
Apps don't need to use this util.config_get because they'll use one
or the other CONFIG, not both.
I've added some config vars which are used by functions in my model.
I'd like the functions to be usable from paster shell for testing,
as well as during a web request.
Ah, yes, we've had this discussion before ;) I originally raised the
complaint here:
http://www.mail-archive.com/pylons-discuss@googlegroups.com/
msg01783.html
I thought I chimed in on this thread originally but apparently not.
The standard for accessing ini values should be via
paste.deploy.CONFIG. It's a global variable, accessible everywhere.
The Globals object's constructor accepts global_conf and app_conf:
after revisiting this topic, I'm realizing that encourages bad
behavior (avoiding CONFIG) and should be deprecated.
The notion of passing around global_conf and app_conf was inherited
from the PasteDeploy app factory interface (what your project's
middleware.make_app function implements). Many middleware
constructors also take these conf arguments if they care about about
configuration values.
Globals was originally crafted to similarly take these conf arguments
because CONFIG wasn't available when make_app was called. It was only
activated during the request (thread_config), via ConfigMiddleware.
Now CONFIG is initialized at the beginning of the make_app function
(process_config), as well as in websetup.py (at least the Pylons
paster template includes this initialization as of 0.9.3 or so). With
those changes, anything requiring the configuration within
Globals.__init__ or websetup should be able to get to it via CONFIG.
The Pylons Config (I mean pylons.config.Config) object also contains
references to app_conf and global_conf (g.pylons_config.app_conf?,
doh). These should probably be deprecated too if they can be.
Also, since we're on the subject, I should point out that accessing
configuration variables via CONFIG['app_conf'] is on its way out.
Apps typically don't care whether or not some configuration value was
set in the [DEFAULT] section of the ini ('global_conf') as opposed to
being set or overridden in the [app:main] section ('app_conf').
So the paster template's CONFIG initialization code was recently
changed to meld global_conf and app_conf together (with app_conf
taking precedent obviously), with that outcome being the actual CONFIG.
CONFIG['app_conf']['sqlalchemy.dburi']
will become
CONFIG['sqlalchemy.dburi']
(an 'app_conf' and 'global_conf' keys will exist for backwards
compatibility, and/or for when the app does care where values from)
You and I talked about this here:
http://www.mail-archive.com/pylons-discuss@googlegroups.com/
msg02164.html
I talk about how to get access to configuration in the model here:
http://pylonshq.com/project/pylonshq/wiki/SqlAlchemyWithPylons
I know why we have this mess--it's the whole multiple copies of the
same app in one process. I still wish it could be as easy as
importing a module full of globals. There's gotta be a way we can
make this a bit easier.
I'll have to edit that config wiki page:
http://pylonshq.com/project/pylonshq/wiki/CodeRecipes/
ExtractingConfigurationData
to reflect all this =]
--
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: So may ways to get config values
On 2/14/07, Shannon -jj Behrens [EMAIL PROTECTED] wrote: I still wish it could be as easy as importing a module full of globals. There's gotta be a way we can make this a bit easier. I ended up making a 'myapp.lib.config' module thus: === from pylons.util import config_get as _cg app_name = _cg(ui.app_name) famous_incidents_count = int(_cg(ui.famous_incidents_count, 10)) recent_incidents_limit = int(_cg(ui.recent_incidents_limit, 10)) date_format = _cg(ui.date_format, %Y-%d-%d) === This also converts the types for me, and concentrates exceptions at the beginning of the application (e.g., if a numeric value is non-numeric) rather than during some arbitrary request. pylons.util.config_get()'s comments say paste.deploy.CONFIG has been deprecated in favor of paste.config.CONFIG, but that's wrong. Under paster shell, paste.config.CONFIG does not have the configuration, but paste.deploy.CONFIG does. Also, I still disagree with config_get()'s docstring which discourages its use. config_get looks in all the right places, so there's no reason not to use it for one-stop-shopping. Another place I need config values is in Mako templates. I'm still looking for the best way to do that, perhaps % import ... %. -- 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: TransLogger not helpful with errors
Mike Orr wrote: I enabled paste.translogger.TransLogger to get a summary of transactions on the console, and it shows Not Found errors like this: === 127.0.0.1 - - [14/Feb/2007:18:49:47 -0700] GET /error/document/?message=Not+Foundcode=404 HTTP/1.1 200 - - Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.1) Gecko/20061208 Firefox/2.0.0.1 It was getting the path out of the environment after the request returns. I changed it in Paste trunk to figure out the path earlier, which should fix this. -- 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 -~--~~~~--~~--~--~---
