After talking with Ian Bicking a bit tonight, I'm finally fully sold
on retiring the one-letter variable names from Pylons. The most likely
replacement names:
c -> context
g -> ??? (as globals/global is already taken)
h -> GONE (import the modules you need, most ppl want similar
functions an
On Dec 18, 2007, at 12:12 AM, Ben Bangert wrote:
In controllers, I think we can do away with the 'from ... import *'.
While this works nicely for awhile, it almost always tends to leave
a bad taste on people's mouth. The default controller template could
instead come with the only necessary
On Dec 18, 2007 12:12 AM, Ben Bangert <[EMAIL PROTECTED]> wrote:
> After talking with Ian Bicking a bit tonight, I'm finally fully sold
> on retiring the one-letter variable names from Pylons. The most likely
> replacement names:
> c -> context
> g -> ??? (as globals/global is already taken)
> h -
On Dec 18, 2007 12:26 AM, Ben Bangert <[EMAIL PROTECTED]> wrote:
> On Dec 18, 2007, at 12:12 AM, Ben Bangert wrote:
> > In controllers, I think we can do away with the 'from ... import *'.
> > While this works nicely for awhile, it almost always tends to leave
> > a bad taste on people's mouth. Th
On Dec 18, 2007 12:26 AM, Ben Bangert <[EMAIL PROTECTED]> wrote:
> I'm also looking at some of the locations for things, and since beaker
> handles its own stacked object proxy, I'm thinking it might be cleaner
> and less confusing if projects imported the session object from where
> the package t
Hi Ben,
I wholeheartedly agree and I like the idea of explicit session imports from
things like Beaker too so everything is explicit. The less work the user
has to do to find out what is actually going on the better in my view, even
if it makes Pylons *look* less like an integrated framework.
g
On Tue, Dec 18, 2007 at 01:07:50AM -0800, Mike Orr wrote:
>
> On Dec 18, 2007 12:26 AM, Ben Bangert <[EMAIL PROTECTED]> wrote:
> > I'm also looking at some of the locations for things, and since beaker
> > handles its own stacked object proxy, I'm thinking it might be cleaner
> > and less confusi
On Dec 17, 2007 11:44 PM, Ian Bicking <[EMAIL PROTECTED]> wrote:
>
> Mike Orr wrote:
> > There are two ways to go with the loader:
> > t = loader("mytemplate.html")
> > output = renderer.render(t, variables)
> > Or:
> > output = renderer.render("mytemplate.html", variables) # Uses
> >
On Dec 18, 2007 1:40 AM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Hi Ben,
>
> I wholeheartedly agree and I like the idea of explicit session imports from
> things like Beaker too so everything is explicit. The less work the user
> has to do to find out what is actually going on the better
Mike Orr wrote:
> On Dec 18, 2007 1:40 AM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>> Hi Ben,
>>
>> I wholeheartedly agree and I like the idea of explicit session imports from
>> things like Beaker too so everything is explicit. The less work the user
>> has to do to find out what is actually
Hi Mike,
Mike Orr wrote:
> Ugh, you really expect people to want to memorize this? Sessions are
> supposed to be built into megaframeworks, not require some obscure
> import. "I think I'll just use Rails instead; it's more
> straightforward."
The problem at the moment is worse, people start us
On Dec 18, 2007 3:12 AM, Ben Bangert <[EMAIL PROTECTED]> wrote:
> After talking with Ian Bicking a bit tonight, I'm finally fully sold
> on retiring the one-letter variable names from Pylons. The most likely
> replacement names:
> c -> context
> g -> ??? (as globals/global is already taken)
> h ->
Ben Bangert wrote:
> After talking with Ian Bicking a bit tonight, I'm finally fully sold
> on retiring the one-letter variable names from Pylons. The most likely
> replacement names:
>
> c -> context
> g -> ??? (as globals/global is already taken)
Awesome. I am so glad you have seen the light
Mike Orr wrote:
>> When you want sessions, you'd add: from beaker.middleware import
>> beaker_session as session
>
> Ugh, you really expect people to want to memorize this? Sessions
> are supposed to be built into megaframeworks, not require some
> obscure import. "I think I'll just use Rails i
Ben Bangert wrote:
> On Dec 18, 2007, at 12:12 AM, Ben Bangert wrote:
>> In controllers, I think we can do away with the 'from ... import *'.
>> While this works nicely for awhile, it almost always tends to leave a
>> bad taste on people's mouth. The default controller template could
>> instead
Ben Bangert wrote:
> When you want sessions, you'd add:
> from beaker.middleware import beaker_session as session
After thinking about it overnight, I'm beginning to think this is the
least objectionable part of the whole proposal. Sessions are not
universally used, and having the word "beaker"
Mike Orr wrote:
> Ben Bangert wrote:
>> When you want sessions, you'd add:
>> from beaker.middleware import beaker_session as session
>
> After thinking about it overnight, I'm beginning to think this is the
> least objectionable part of the whole proposal. Sessions are not
> universally used, a
On Dec 18, 2007 11:33 AM, Ian Bicking <[EMAIL PROTECTED]> wrote:
> h.url_for always reads weird to me. url_for is a first-class function,
> why not just put it at the top level for templates? That said, I
> generally like h.
I've found this function very useful in templates, and would like to
s
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 care
On Tue, 2007-18-12 at 07:41 -0500, Mark Ramm wrote:
> On Dec 18, 2007 3:12 AM, Ben Bangert <[EMAIL PROTECTED]> wrote:
> > After talking with Ian Bicking a bit tonight, I'm finally fully sold
> > on retiring the one-letter variable names from Pylons. The most likely
> > replacement names:
> > c ->
On Tue, 2007-18-12 at 00:26 -0800, Ben Bangert wrote:
> On Dec 18, 2007, at 12:12 AM, Ben Bangert wrote:
> > In controllers, I think we can do away with the 'from ... import *'.
> > While this works nicely for awhile, it almost always tends to leave
> > a bad taste on people's mouth. The defau
Quoth Jonathan LaCour (2007-12-19 06:54):
> pylons.c -> pylons.request.state
> pylons.session -> pylons.request.session
> pylons.g -> pylons.request.app_globals
Excuse my ignorance, but why can't all these just be attributes of
the controller instance? An abstract base
On Dec 18, 2007 2:46 PM, avdd <[EMAIL PROTECTED]> wrote:
>
> Quoth Jonathan LaCour (2007-12-19 06:54):
> > pylons.c -> pylons.request.state
> > pylons.session -> pylons.request.session
> > pylons.g -> pylons.request.app_globals
>
> Excuse my ignorance, but why can't all
Mike Orr wrote:
>> g should be renamed persist. The interesting thing about g isn't that it is
>> global, rather that the variables attached to it persist across requests.
>
> The interesting thing about 'g' is, um... is there anything
> interesting about it?
> I've found two rare cases for it.
On Dec 18, 2007, at 1:07 AM, Mike Orr wrote:
Ugh, you really expect people to want to memorize this? Sessions are
supposed to be built into megaframeworks, not require some obscure
import. "I think I'll just use Rails instead; it's more
straightforward."
No, I expect someone using sessions t
On Dec 18, 2007, at 1:44 AM, Christoph Haas wrote:
+1 on that. Please provide the "session" by default. Pylons may be
re-using other components but IMHO that should be hidden from the
user.
Yea, the thing is, it isn't really re-using the other components, its
just putting their WSGI app in
On Dec 18, 2007 4:06 PM, Ben Bangert <[EMAIL PROTECTED]> wrote:
> Pylons is not a megaframework, its the
> opposite, its a lightweight framework, that loosly couples some WSGI
> components into a WSGI stack and puts the stack under your control.
Well, it depends on your definition. I call it a m
On Dec 18, 2007 4:06 PM, Ben Bangert <[EMAIL PROTECTED]> wrote:
> Consider how simple sessions and the WSGI layer can be explained:
>
> Beaker has middleware that sets up and handles sessions for you, by
> adding the SessionMiddleware to your stack, you can now use sessions
> in your controllers.
On Dec 18, 2007 3:21 PM, James Gardner <[EMAIL PROTECTED]> wrote:
> Personally I like it but in hindsight I
> think Global is misleading and persistent is a better description.
Well, its essential characteristic is being appinstance_local, it
sounds like. 'persistent' generally means "saved acros
On Dec 18, 2007 9:11 PM, Mike Orr <[EMAIL PROTECTED]> wrote:
>
> Would anybody cry if I change the render argument order to put the
> template always first. Either:
I promise not to cry if you rip the band aid off quick ;)
--~--~-~--~~~---~--~~
You received this
> pylons.c -> pylons.request.state
> pylons.session -> pylons.request.session
> pylons.g -> pylons.request.app_globals
I don't think session belongs in request personally, isn't the whole
point of the session that it persists _across_ requests.
I think app_local is be
Would anybody cry if I change the render argument order to put the
template always first. Either:
render(template, engine=None, variables=None, ... cache args)
Or:
render(template, variables=None, engine=None, ... cache args)
That would get rid of the moving argument, but people usin
> h.url_for always reads weird to me. url_for is a first-class function,
> why not just put it at the top level for templates? That said, I
> generally like h.
TurboGears 1 had a registry of things that ought to be automatically
imported into the template namespace as top level variables.
And
> 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.
I agree that it mak
On Dec 18, 2007 6:30 PM, Mark Ramm <[EMAIL PROTECTED]> wrote:
>
> > pylons.c -> pylons.request.state
> > pylons.session -> pylons.request.session
> > pylons.g -> pylons.request.app_globals
>
> I don't think session belongs in request personally, isn't the whole
> point o
35 matches
Mail list logo
