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, 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.
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.
g is weird; I think app_global is probably a good name, and a short name
isn't required. People might actually use it when it has a long name ;)
> '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.
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.
> 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?
I'm not sure what cache and etag_cache do... I'm guessing they are
replaced with methods on webob.Response.
> 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?
I kind of wish the complete Rails-compatible helpers were just in their
own webhelpers.rails module, and a smaller set of clear helpers was at
the top level, selected for utility and completeness.
>> 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.
Maybe there could be some categories:
* Required by Pylons. These are always present. Stuff like Paste or
now WebOb, WebError, Cascade, etc.
* Part of Pylons; you don't have to use these pieces, but there's no
real alternative, so it's simply a matter of weather you need the
functionality. Includes Beaker, WebHelpers, maybe FormEncode validators.
* Recommended components; some people use other components, but these
components are recommended. Includes Mako, SQLAlchemy, maybe htmlfill,
some other things. Using another library for templating, persistence,
forms, is specifically allowed for if you are so inclined.
* Optional components, stuff that's written with Pylons in mind.
Includes ToscaWidgets... what else?
>> 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?
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.
I'd actually prefer a getter function (get_request()) instead of
proxies, but that's too radical a change for Pylons at this point.
> 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.
What is the advantage of returning a dict vs. return render(template,
**vars)? I don't personally see any advantage -- rendering variables to
a template or JSON or XML or whatnot, like TG, seems dubious to me.
That the keyword arguments currently go to the Buffet interface is lame,
as those arguments are relatively much less useful than variable
assignments.
It's reasonable you could reasonably do both **vars and context; **vars
becomes top-level variables, and context is there is you choose to use
it. You wouldn't have to use context then. At which point the longer
name doesn't seem too bad, since it's not something you'd typically use
directly in the action method.
I have in the past used stuff like context for applications, but that
was a previous style of my own development, before I used Pylons at all.
I tend to bake all my values centrally now. As long as you can do
render("template", domain_object=self.get_domain_object()) (for whatever
kind of domain object you have, which might have arbitrary internal
complexity), then that seems preferable to me. Again, you can track the
names back to their sources more easily.
And a name "context" doesn't mean much. It doesn't mean a whole lot
more than "c", but it pretends to mean more.
--
Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
