Ian Bicking wrote:
>> There's a reason controllers have "from myapp.lib.base import *".
>> It's to ensure that every controller has a certain baseline of
>> objects
>> available. Better than importing 30 symbols into every controller
>> and
>> then you have to look at the import stanzas carefully to see if one
>> controller has this, or is missing it, or importing stuff it's not
>> using. It also makes controllers harder to print out if half the
>> first page is imports.
>
> For several of the symbols using dotted notation wouldn't be a big
> deal.
> Controller itself is only used once in a controller file, to subclass
> it. It could just be base.Controller. It would take some sorting out
> to figure out exactly how to set that up, since they are all in base
> now.
I was just about to suggest this very thing. I view:
from myapp.lib import base
as a huge improvement over:
from myapp.lib.base import *
Its far easier to track your local namespace when you have no "import *"
madness, which is usually only reserved for my interactive prompt.
>> Anyway, this is all what I was told as I was learning Pylons. "Put
>> things for all controllers in the base controller." "Put generic
>> functions in 'h' that are called by both controllers and templates."
>> "One-letter globals are great." "Use 'abort' and 'redirect_to' and
>> 'model' and 'cache' and 'etag_cache'; they're preconfigured for
>> you." Now we're saying that what was good is bad. War is peace.
>> Freedom is slavery. Ignorance is strength.
>
> Why aren't abort and redirect_to methods on the controller?
Good idea.
> I think everything that is a SOP right now could hang off a single
> request SOP. I personally would prefer that; I think it makes all
> this stuff much more clear. It's easy to remember that the request
> object is per-request -- heck, it's obvious once you write it down.
> That its attributes like session are also per-request is then also
> obvious.
<snip, snip...>
> And a name "context" doesn't mean much. It doesn't mean a whole lot
> more than "c", but it pretends to mean more.
I hadn't thought of any of this before, but I really like the concept.
It seems to me that `context` is certainly better than `c` but you
are right that it doesn't really convey the fact that its essentially
request local state. My personal preference, after hearing your ideas,
would be:
pylons.c -> pylons.request.state
pylons.session -> pylons.request.session
pylons.g -> pylons.request.app_globals
The only excuse I can think of for single-character variables is that
it allows you to type a little less, but if thats your main concern,
you might as well switch to Perl. I hear they have lots of shortcuts
over there ;) Finally, even if the names switch over to "context" and
"app_global", what's to prevent you from doing this:
from pylons import context as c, app_global as g
You'll still have your shortcut, but the more sane variable names can
still be used and referenced in all core Pylons code, examples, and
docs.
--
Jonathan LaCour
http://cleverdevil.org
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"pylons-devel" group.
To post to this group, send email to pylons-devel@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-devel?hl=en
-~----------~----~----~----~------~----~------~--~---
