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
see it in WebHelpers:
def link(label, *url_for_args, **url_for_kw):
"""Shortcut for h.link_to("label", h.url_for(*args, **kw)).
Any HTML markup in the label will be escaped.
"""
label = html_escape(label)
url = url_for(*url_for_args, **url_for_kw)
return link_to(label, url)
> > 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.
That's a good idea. 'base' obviously means base or parent. And if
the user really wants three favorite symbols at top level, he can
import those separately, but he'll still have all of them available.
And there won't be any need to remove imports from the base
controller.
> > 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'm not sure what cache and etag_cache do... I'm guessing they are
> replaced with methods on webob.Response.
'cache' is a Beaker cache, available to store anything.
etag_cache('tag') manages the etag response headers and raises the
"Not Modified" short circuit.
http://wiki.pylonshq.com/display/pylonsdocs/Getting+Started#pylons-globals
http://wiki.pylonshq.com/display/pylonsdocs/Caching+in+Templates+and+Controllers
> 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.
Ben has talked about improving the helpers, and directing ppl to other
Javascript libraries for the remote stuff. Why don't we plan a
WebHelpers reorganization for 0.9.8?
> > 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?
Well, I'm only talking about Pylons' current dependencies,
distinguishing the essential from the extra. SQLAlchemy and
ToscaWidgets are in the Pylons documentation but are not dependencies.
Mako, FormEncode/htmlfill, Beaker, and WebHelpers are all dependencies.
Buffet requires a default template engine, and there's talk about
using Mako internally for application templates. FormEncode, Beaker,
and WebHelpers are all features expected in every megaframework
nowadays.
However, dependencies are different than top-level imports. Every
action needs request/response/render. Abort/redirect_to/url_for
should be in your face because they're the "PEP 8" of Pylons
programming style -- things you should do this way. 'session',
'cache', forms, i18n are all optional services so they can be less
conspicous; the user can do them that way or another way.
> 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.
No more radical than the other things we're discussing. Eliminating
or consolidating SOPs would be the #1 way to make Pylons more
understandable and easier to get your head around. And don't you have
to avoid SOPs in mod_wsgi, I thought I heard?
Ben, need BDFL pronouncement on:
- Make all current SOPs attributes of a single SOP. (With possibly an
exception for render().)
- Make all current SOPs attributes of an object returned by a global function.
I wish you could attach properties to modules, but that doesn't work.
The property doesn't behave like it would in a class.
> 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.
Passing data to render() is OK but it's against Pylons current
recommendation. Do we want to switch to that as the primary
documented way? Also, it would have to be
return render(template, vars, **rendering_options)
Otherwise there would be no way to pass rendering options except by
mixing them with the data.
One snag is the moving argument. You can call render as:
render(template) # Uses default engine
render(engine, template)
It uses the presence of the second arg to recognize the second syntax.
If we add a third arg, what happens when the engine arg is/is not
present? Do we make the engine arg mandatory? What value would it be
for the default engine? ""? None?
And no, I don't want an essential argument to have to be a keyword.
Keyword means "optional argument" or "I have so many damn arguments
you can't keep track of them without keywords" or "My subclasses have
different arguments and I don't know what they are".
> 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.
That would be OK.
> And a name "context" doesn't mean much. It doesn't mean a whole lot
> more than "c", but it pretends to mean more.
Ditto. I hate the word context, both here and in SQLAlchemy. What
we're speaking in is a context.
--
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 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
-~----------~----~----~----~------~----~------~--~---
