Whoops, I meant to respond to your inline questions too. I responded to the ones I knew the answers to.
On Sun, 2010-09-12 at 04:24 -0700, Mike Orr wrote: > I've got a first draft of the Pylons 2 Users Guide done. The "hello > world" page is the only page that's completed; it goes through > installing a default application and looking through the application > code. I haven't gone through the Pylons code or BFG code or BFG manual > yet; I just went with "it must be so in order for the application code > to work", based on an earlier email exchange with Ben about the > application structure. The emails are also included for reference on a > separate page. > > HTML version: http://sluggo.scrapping.cc/tmp/execution/ > > Repository: http://bitbucket.org/sluggo/execution > > I found a few bugs and unknown things as I went along. > > 1) I couldn't create an application with a capital letter, as shown in > the traceback below. > > 2) The interactive traceback doesn't work; I just got an "Internal > Server Error" when I raised RuntimeError. This makes it impossible to > inspect a live request. Both of these are fixed. > > 3) "paster shell" doesn't work, so I couldn't inspect a request that way. This is not yet fixed. > 4) Where is "routehelper" imported from? > > 5) What is Request.abort_session() for? is that to rollback changes to > the session? Or is it to forget the session when you log out? > > 6) Where is the code behind @action? The definition simply puts **kw > on the .__exposed__ attribute of the view method. But I couldn't find > anything in Pylons or BFG that would plug the return dict into a Mako > template and create a Response, yet it must be doing it somehow. The @action decorator is more or less unrelated to the values returned by a handler to a "renderer", except to name which renderer should be used (e.g. renderer='sometemplate.mak'). (Most other arguments to the @action decorator just make narrower the set of circumstances that will cause the thing it's decorating to be found and executed). See these sections of the BFG docs for information about what a "renderer" does: http://docs.repoze.org/bfg/1.3/narr/views.html#writing-view-callables-which-use-a-renderer http://docs.repoze.org/bfg/1.3/narr/templates.html#templates-used-as-renderers-via-configuration A templating system is just another kind of renderer, except you register it for an extension (e.g. '.mak'). > 7) How do you change template engines? Specifically Genshi and Jinja2, > which are popular among Pylons users. You: 1) associate a "renderer" with a file extension (see comments in my fork for a concrete mako example) 2) Then use a renderer= line in the @action configuration or use one of these APIs to render such an extensioned template: http://docs.repoze.org/bfg/1.3/api/renderers.html#repoze.bfg.renderers.render_to_response or http://docs.repoze.org/bfg/1.3/api/renderers.html#repoze.bfg.renderers.render > > 8) Is it worth documenting Request.add_response_callback(), > config.add_subscriber, .add_view, .add_route, and the config.__init__ > args for Pylons? It seems like .add_handler is enough. I skipped over > a bunch of other Config methods that looked irrelevant. Probably not. All of this stuff is already well-documented in the BFG docs, and it's likely we can just steal it from there if we think it's necessary to include in the Pylons docs. - C -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-de...@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
