Fwd: ANN: Smorgasbord 0.1.0 is released
Here's the initial version of my rewrite of Buffet, Pylons' template front end. This is only for those who care about the template internals. It won't actually work with Pylons until I write a pylons.templating patch, but here's a preview of the direction I'm proposing. -- Forwarded message -- From: Mike Orr [EMAIL PROTECTED] Date: Jun 3, 2007 6:38 AM Subject: ANN: Smorgasbord 0.1.0 is released To: [EMAIL PROTECTED] There's an initial implementation of Smorgasbord, my rewrite of the Buffet universal templating front end, at the Python Cheeseshop or http://sluggo.scrapping.cc/python/smorgasbord/ . Documentation is at http://sluggo.scrapping.cc/python/smorgasbord/Smorgasbord-current/README.html Plugins are included for Mako, Cheetah, Genshi, Kid, string.Template. These pass a minimal Nose test (a template with a placeholder) but do not recognize template options yet. There are plugins for Myghty and Breve but they don't work yet. (Expert needed.) A universal loader that recognizes path and URI notation is built-in, and is expandable for dotted notation if somebody twists my arm hard enough.It looks up templates in a directory path and an extension path (a list of extensions to be appended in turn if the template is not found). There is also an optional caching subclass that saves compiled templates in a dict. Feedback is welcome. What options are important for which engines? What does TurboGears need? Shall we go with URI syntax across the board for all engines in both Pylons and TG? Or Path syntax? Do we have to support existing Pylons/TG sites unchanged even if it means doing dotted notation and Python imports and obsolete options? Is it necessary to import Python templates (for Kid/Cheetah), or can we let the dict cache be the alternative speeder-upper? What about those dozens of default options Pylons has for Myghty? -- 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 -~--~~~~--~~--~--~---
SQLAlchemy object
at Mike Orr's prodding, ive worked up a SQLAlchemy context object
based on his proposal for a facade that deals with the various session
(context)/engine/metadata mixtures. I think this would be a good
idea for the very reason that it encapsulates all the details of how
engines/metadata/session/etc get created and used. right now we have
tutorials and such all throwing out BoundMetaDatas and Sessions with
bind_to's and a lot of mixing up of paradigms. by putting it all
inside a single facade, nobody has to make those decisions anymore if
they dont want to. the facade would be configurable to support a few
different operational paradigms, including engines bound to tables,
or engines bound to sessions...each of which has its pros and cons
depending on the type of app youre writing (i.e. one app with one
database, one app with multiple databases for different objects, one
app with multiple databases for different use cases (e.g. separate
readonly/write db's), multiple apps on multiple databases, multiple
apps sharing common tables across multiple databases). by default it
would internally bind engines to metadatas which is the most flexible
configuration for a single application that may persist different
model classes to different dbs.
this object would just give you everything you need: metadata,
engine, session. how they got constructed, which one connects to
what, you dont care. because really, most people dont. qualified
method accessors engine/metadata for alternate connection names would
be provided. multiple applications that talk to different
tablesets, i.e. for middleware that has its own deal going on, just
makes its own SAContext. this probably would obviate the need for a
global engine registry at all (though im not sure).
from pylons.database import SAContext
sac = SAContext() # connects to engine in the .ini file by default
sac = SAContext(url='sqlite://', engine_args={}) # or send a url,
args in
# create a table. metadata is a BoundMetaData to the default engine.
users = Table('users', sac.metadata, Column(...)...)
# alternatively, we could have a table creation function on the
object w/o the metadata argument (opinions?)
users = sac.define_table('users', Column(...)...)
# add extra engine
sac.add_engine('pgconn', url='postgres://', engine_args={})
# table on alt engine. metadata is a BoundMetaData to the 'pgconn'
engine.
remote_users = Table('remote_users', sac.get_metadata('pgconn'),
Column(...)...)
# mappers can bind to the sessioncontext via the SAContext directly
# (its got a SessionContext inside, sends out SessionContext.ext out
# via ext)
mapper(User, users, extension=sac.ext)
mapper(RemoteUser, remote_users, extension=sac.ext)
# query accessor
sac.query(Users).filter_by(...).list()
# session. gets pulled from the SessionContext. note you never deal
# with the context itself.
# session doesnt even have a bind_to, its just using the engines for
# each table it gets.
sac.session.save(User())
sac.session.save(RemoteUser())
# that way this statement saves each user to its correct DB without
# any issues.
sac.session.flush()
if we get everyone on a simple object like this, then we can plug in
strategies for other scenarios, build up clustering strategies, etc.
--~--~-~--~~~---~--~~
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: SQLAlchemy object
On Sat, Jun 02, 2007 at 01:09:37PM -0400, Michael Bayer wrote: at Mike Orr's prodding, ive worked up a SQLAlchemy context object based on his proposal for a facade that deals with the various session (context)/engine/metadata mixtures. I think this would be a good idea for the very reason that it encapsulates all the details of how engines/metadata/session/etc get created and used. [...] from pylons.database import SAContext sac = SAContext() # connects to engine in the .ini file by default [...] I like your prosal a lot. It addresses everything that has annoyed me so far. But why is it limited to pylons.database? Elixir tries to make SA simpler. Can't the session context itself be jazzed up so thar pylons.database does little more than read the sqlalchemy.dburi and provide a session context? Christoph --~--~-~--~~~---~--~~ 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: Subdirectories and resource paths in Mako
Okay, I dug...
I edited the load_enviroment to taste, but I still get errors:
def load_environment(global_conf={}, app_conf={}):
map = make_map(global_conf, app_conf)
# Setup our paths
root_path =
os.path.dirname(os.path.dirname(os.path.abspath(__file__)))
paths = {'root_path': root_path,
'controllers': os.path.join(root_path, 'controllers'),
'templates': [os.path.join(root_path, path) for path in \
('components', 'templates', 'foo')],
'static_files': os.path.join(root_path, 'public')
}
the path foo is not recognized when I try to render a template from
it:
render_response('foo/newtemplate.html')
could someone help me out?
thanks
On Jun 2, 8:13 pm, voltron [EMAIL PROTECTED] wrote:
I tried using subdirectories to render templates in PYlons:
return render_response(/main/'standard.html)
this failed, how does one pass templates from other directories or
subdirecotires?
Also, for static resources, like images or CSS files that actually are
on the proxy server proxying for the Paster server, how can I pass a
sort of /media path to my templates that would always be resolved no
matter how deep the links are that are mapped?
Thanks
--~--~-~--~~~---~--~~
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: Subdirectories and resource paths in Mako
ahhh, it should have read:
render_response('newtemplate.html')
foo just gets added to the searchpath
neat
On Jun 3, 8:42 pm, voltron [EMAIL PROTECTED] wrote:
Okay, I dug...
I edited the load_enviroment to taste, but I still get errors:
def load_environment(global_conf={}, app_conf={}):
map = make_map(global_conf, app_conf)
# Setup our paths
root_path =
os.path.dirname(os.path.dirname(os.path.abspath(__file__)))
paths = {'root_path': root_path,
'controllers': os.path.join(root_path, 'controllers'),
'templates': [os.path.join(root_path, path) for path in \
('components', 'templates', 'foo')],
'static_files': os.path.join(root_path, 'public')
}
the path foo is not recognized when I try to render a template from
it:
render_response('foo/newtemplate.html')
could someone help me out?
thanks
On Jun 2, 8:13 pm, voltron [EMAIL PROTECTED] wrote:
I tried using subdirectories to render templates in PYlons:
return render_response(/main/'standard.html)
this failed, how does one pass templates from other directories or
subdirecotires?
Also, for static resources, like images or CSS files that actually are
on the proxy server proxying for the Paster server, how can I pass a
sort of /media path to my templates that would always be resolved no
matter how deep the links are that are mapped?
Thanks
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: Pylons Logo Design
On Jun 2, 2007, at 11:55 AM, Mike Orr wrote: Why is it called Pylons anyway? I thought a pylon was a large metal beam (girder), so as a building block it made sense. But dictionary.com says it means a tower. Here are all the definitions, which include some visual ideas we haven't tried. Ancient Egyptian theme, anyone? I'm open to taking a look at an Egyptian theme, especially if it results in a cooler logo. :) - 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: SQLAlchemy object
On 6/3/07, Michael Bayer [EMAIL PROTECTED] wrote: On Jun 3, 2007, at 10:49 AM, Christoph Haas wrote: On Sat, Jun 02, 2007 at 01:09:37PM -0400, Michael Bayer wrote: at Mike Orr's prodding, ive worked up a SQLAlchemy context object based on his proposal for a facade that deals with the various session (context)/engine/metadata mixtures. I think this would be a good idea for the very reason that it encapsulates all the details of how engines/metadata/session/etc get created and used. [...] from pylons.database import SAContext sac = SAContext() # connects to engine in the .ini file by default [...] I like your prosal a lot. It addresses everything that has annoyed me so far. But why is it limited to pylons.database? Elixir tries to make SA simpler. Can't the session context itself be jazzed up so thar pylons.database does little more than read the sqlalchemy.dburi and provide a session context? i consider this facade to be a framework feature. it has an opinion about how things should be organized. SA itself isnt a framework and doesnt want strong opinions about how things should be organized, and SessionContext is just a small building block towards an end-user solution. im pretty sure making a rich facade out of SessionContext would throw the zalchemy guys for a loop, for example. I also think something like SAContext would make a good optional feature for SQLAlchemy, but I'd rather see it proven in Pylons first. There's also a get_engine_args() function which Michael didn't say much about but it's going to be a large percentage of the code. It's not just a matter of sqlalchemy.dburi. There's also sqlalchemy.pool_recycle which is critical for MySQL, as well as the other engine options (or at least the scalar ones). It will also scale to multiple engines along the lines of sqlalchemy.engine_key.dburi. This code is very Pylons specific, or at least it is until other frameworks/applications start using the same config file format. -- 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 -~--~~~~--~~--~--~---
Pylons Security
I'm curious about the state of Pylons security, especially since AuthKit is not ready for production yet. Does pylons have the means to keep the bad guys out? I'm interesting in using it for an e-commerce app, and you anyone can the security requirments any e-commerce app would need. Does anyone have any input or experience with these type of security requirements for Pylons? Thanks, greentree --~--~-~--~~~---~--~~ 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: SQLAlchemy object
I like the proposal, anything that simplifies the whole context thing is
great! do you think your proposal will work with the assignmapper extension?
Jose
Michael Bayer wrote:
at Mike Orr's prodding, ive worked up a SQLAlchemy context object
based on his proposal for a facade that deals with the various session
(context)/engine/metadata mixtures. I think this would be a good
idea for the very reason that it encapsulates all the details of how
engines/metadata/session/etc get created and used. right now we have
tutorials and such all throwing out BoundMetaDatas and Sessions with
bind_to's and a lot of mixing up of paradigms. by putting it all
inside a single facade, nobody has to make those decisions anymore if
they dont want to. the facade would be configurable to support a few
different operational paradigms, including engines bound to tables,
or engines bound to sessions...each of which has its pros and cons
depending on the type of app youre writing (i.e. one app with one
database, one app with multiple databases for different objects, one
app with multiple databases for different use cases (e.g. separate
readonly/write db's), multiple apps on multiple databases, multiple
apps sharing common tables across multiple databases). by default it
would internally bind engines to metadatas which is the most flexible
configuration for a single application that may persist different
model classes to different dbs.
this object would just give you everything you need: metadata,
engine, session. how they got constructed, which one connects to
what, you dont care. because really, most people dont. qualified
method accessors engine/metadata for alternate connection names would
be provided. multiple applications that talk to different
tablesets, i.e. for middleware that has its own deal going on, just
makes its own SAContext. this probably would obviate the need for a
global engine registry at all (though im not sure).
from pylons.database import SAContext
sac = SAContext() # connects to engine in the .ini file by default
sac = SAContext(url='sqlite://', engine_args={}) # or send a url,
args in
# create a table. metadata is a BoundMetaData to the default engine.
users = Table('users', sac.metadata, Column(...)...)
# alternatively, we could have a table creation function on the
object w/o the metadata argument (opinions?)
users = sac.define_table('users', Column(...)...)
# add extra engine
sac.add_engine('pgconn', url='postgres://', engine_args={})
# table on alt engine. metadata is a BoundMetaData to the 'pgconn'
engine.
remote_users = Table('remote_users', sac.get_metadata('pgconn'),
Column(...)...)
# mappers can bind to the sessioncontext via the SAContext directly
# (its got a SessionContext inside, sends out SessionContext.ext out
# via ext)
mapper(User, users, extension=sac.ext)
mapper(RemoteUser, remote_users, extension=sac.ext)
# query accessor
sac.query(Users).filter_by(...).list()
# session. gets pulled from the SessionContext. note you never deal
# with the context itself.
# session doesnt even have a bind_to, its just using the engines for
# each table it gets.
sac.session.save(User())
sac.session.save(RemoteUser())
# that way this statement saves each user to its correct DB without
# any issues.
sac.session.flush()
if we get everyone on a simple object like this, then we can plug in
strategies for other scenarios, build up clustering strategies, etc.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Odd behavior with paster and Pylons
Hi all, I discovered some interesting behavior when using Pylons on WebFaction. For some very odd reason that I can't discern, whenever I run paster inside of a Pylons command, even if I don't pass any arguments, it launches gconfd-2. Normally, I wouldn't notice, but WebFaction limits the number of long running processes you have, and I got e-mailed about it. To top off the weirdness, it only seems to run when X forwarding is set up. The easy solution is to disable X forwarding since it's useless, which I have, but I'm wondering if there's actually some sort of point to launching gconfd, since it doesn't appear to store anything. Thanks, Dan --~--~-~--~~~---~--~~ 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: Using pater with other servers
On Wed, 2007-05-30 at 04:57 -0700, voltron wrote: http://hiawatha.leisink.org/ the fact that Hiawatha's source code is free of security-bugs, makes Hiawatha the most secure webserver available. besides stating the obvious in a rather unbelievable way, this assertion is followed by: Copyright (c) by Hugo Leisink | Powered by Hiawatha v5.8 | Generated in 1180924509.4455 seconds I'm not sure how much faith I'd put in the first assertion in light of the second :P 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: Pylons Security
On 6/3/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I'm curious about the state of Pylons security, especially since AuthKit is not ready for production yet. Who says AuthKit is not ready for production? Did its author disrecommend it? I took a quick glance at the manual and it says. AuthKit has not been audited by a security expert, please use with caution at your own risk (or better yet, report security holes). But the same goes for a lot of reasonably safe Python software. Of course it would be good to hire a security specialist to audit Pylons and its commonly-used dependencies -- are you offering to do this and file bug reports? Does pylons have the means to keep the bad guys out? I'm interesting in using it for an e-commerce app, and you anyone can the security requirments any e-commerce app would need. This is a very broad question and it sounds a bit demanding and condescending. There are many kinds of e-commerce apps that do different things. What kind of site are we talking about? Something that does its own credit-card transactions? It would be easier to discuss certain vulnerabilities and how well Pylons handles them, than Is Pylons adequate for e-commerce [whatever kind of e-commerce I'm thinking of in my head]? Does anyone have any input or experience with these type of security requirements for Pylons? Now that's a more practical question. As far as I know all the Pylons core developers make their living building commercial web sites, have done so for several years, and seem pretty well informed about the exploits in the industry and how to guard against them. Pylons has a lot going for it because the nature of Python limits certain classes of attacks (few large-scale buffer overflows compared to C apps, no widely-used insecure applications with well-known URLs, no wide-open security holes or inappropriate use of global variables in the web frameworks compared to the earlier versions of PHP, etc), and because we've built up a collective knowledge of things to watch out for through our experience with previous Python web frameworks over the past seven years or longer. Whether any of the developers have had specific security training, or experience with a site that does real-time credit card transactions, I don't know. I've worked on sites that do real-time transactions but not as the main developer. But the basic security needs of a site are more general than that: is sensitive information encrypted, do you remember to analyze and HTML-escape user input before displaying it back to them, are you an attentive sysadmin that checks logs and looks for suspicious activity? Much of that is not something Pylons can directly control; it's how you use the tools that matters. Mako, Genshi, and Kid all have a feature to escape data values across the board except those you specifically mark as safe. As for AuthKit, I haven't used it, but it sounds small enough that you can audit it yourself, at least from the journeyman programmer's perspective. The main vulnerabilities derive from the type of authentication chosen: plaintext password file, encrypted password file, SQL database, LDAP, etc. Each of these imply certain vulnerabilities that really overshadow how well AuthKit manages them. Meaning, AuthKit probably does a reasonably good job, but the factors outside its control are the ones most likely to bite you, and these should be looked at no matter whether you use AuthKit or some other library. -- 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 -~--~~~~--~~--~--~---
