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" in the import wouldn't
be a bad idea.
But the other stuff -- the one-letter globals, the imports -- is
cutting into what makes Pylons Pylons. Pylons' characteristics are
c/g/h, "return render('template')", etc. 95% of the lines in
controllers and templates depend on these variables and imports, so
they'll all have to be changed. This is the *same* Ben Bangert who
wouldn't drop Mapper.connect because he didn't want to rewrite some
routing rules. A large percentage of ${substitutions} in templates
use helpers, especially h.url_for which we've been encouraging.
Yes, I can keep importing 'h' myself, but it kind of loses the point
when I'm following a past Pylons tradition rather than a current
Pylons tradition. Plus I've added my own functions to 'h', especially
formatting functions.
'c' -> 'context' is even more obtrusive. The primary job of most
actions is to set variables for the template. "c.var = value" is
minimally obtrusive because it's only one letter. "context.var =
self._method('long arg 1', 'long arg 2')" starts to run off an
80-column line. You can put "c = context" at the top if the action,
but then you have to repeat it for every action and it becomes
boilerplate clutter. That's what starts to make the alternative of
returning a dict more attractive, and whether I should've just stuck
with TurboGears.
I've just done a rather major step at work of convincing people we
need to switch from Quixote to Pylons due to better Unicode support
and more standard libraries, and now Pylons is changing substantially.
Meaning the people I train will have to learn the 0.9.6 way and also
another way which is almost a different framework. I'm stunned that
this was dropped into 0.9.7 without warning close before the beta as
if it were something minor like "now we're going to use the global
response instead of creating our own".
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.
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.
On Dec 18, 2007 2:13 AM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> 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 using Pylons having heard
> how obvious/customisable it is and then can't work out where something
> simple like a helper comes from.
The biggest impediment to finding helpers is the WebHelpers home page.
I want a tag function, which one of the five tag-related modules is
it in? Did I miss it or is it in another module? Where do I find a
function to escape HTML markup? Or URL escape? What's an "asset"
tag; is that something for a store's inventory system? Why is url_for
here when it's a Routes thing?
> Explicit imports also make it more obvious to the user
> how they can replace some Pylons default with another which is a good thing.
Well, we need to decide and document what's essentially Pylons, or
what's so important it should be treated as a standard extra, vs
things that are just add-ons.
> My point of view is that there are enough people confroming to the
> framework norm and trying to make things *appear* easy whereas for me,
> Pylons is more about things actually being easy because no-one is trying to
> over-simplify things or produce convenient abstractions that hide what's
> really going on.
Well, then you have to ask what's really easy and what isn't. The
StackedObjectProxies are the #1 things that don't make sense. They
push and pop in mysterious ways, and sometimes you have to use
._current_obj() and sometimes not. A single magic object like
'pylons' would be ideal, or even better a function that makes it clear
that "I'm fetching some current-request stuff from some magical
place". Second best is grouping all the StackedObjectProxies in one
place, which is an argument for keeping them under 'pylons'. However,
pylons.templating.render may become a SOP in the next go-around, so
that will scatter them even more. Poor PylonsApp.__call__, that has
to know where they all are. How does it know that Beaker is activated
and it should register an SOP on its session? How would it know if a
different session implementation that needs a different SOP were used?
You are planning a section on SOPs in the book, right?
> Incidentally I really dislike things like the @validate decorator too for a
> similar reason, it actually hides what's going on too much and decorators
> in general are harder for people to get their heads around than functions.
> I think things like @validate should be an ordinary function in Pylons. If
> people want to use it as a decorator in their own apps and they understand
> decorators they can easily write their own @validate decorator which uses
> Pylons' validate() function. That way beginners won't get put off and
> experts don't loose any power.
I don't care so much about decorators, though I think TurboGears uses
too many of them for basic things. (Three or four decorators on an
action is a bit much.) But I do like returning a dict, especially if
it closes the compatibility gap between traditional actions vs @expose
actions ("to 'c' or not to 'c'") and also makes jsonifying easier. To
me the point is elegance and clarity, and conciseness is usually the
best way to get both, and I'd argue that "context.var = value" or "c =
context" are negatives.
--
Mike Orr <[EMAIL PROTECTED]>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"pylons-devel" group.
To post to this group, send email to [email protected]
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
-~----------~----~----~----~------~----~------~--~---
