On Sep 13, 11:49 am, Mike Orr <sluggos...@gmail.com> wrote:
> Can it be made into a request method so you don't have to pass the
> request object? That would be more OO.
Yea, maybe request.link? request.url would conflict with the webob url
property.
> Or do you have to paste the markup text from the subprojects and
> convert all "autoclass" to "class" by hand? The problem with this is
> it would gradually drift out of date unless you went through every few
> months looking for differences between your docs and the originals,
> which would take a lot of time.
Yea, we're going to have to compose copy/paste to an extent, from the
other docs.
> I'm inclined to agree with James, that explaining it at a non-Python
> or non-web-developer level triples the workload. (Once to write the
> new text, and again to test all the examples on platforms you don't
> use.) Anyway, once we get the higher-level text squared away, the
> newbie text will be just a matter of filling in the background. And
> James' book provides a guide on what the newbie needs explained.
Yea, I think the docs should focus on the assumption that the user has
some clue about web dev, and knows Python decently. A book is the
place for more expansive documentation.
> OK, maybe I can outsource that part to you. The first page ("Intro")
> starts to get into that (at least re the changes since Pylons 1), but
> it just takes so long to write with all the necessary background that
> I postponed it. Plus, you guys can remember the new practical
> features better than I can.
Yea, no prob.
> I don't think I've encountered legacy_view yet. How does it work?
It lets you hook in an entire existing Pylons wsgi app into the
configurator for a new style Pylons app.
> BTW, where is the cache?
You can use cache_region once you set some cache options and do
config.add_cache(). This was just recently added to trunk.
> Will there be an app_globals? I'd also suggest a thread_locals (or
> app_globals.locals), because uses keep wondering where to put
> threadlocals and end up reinventing it themselves.
Yep, we'll prolly have a key/value style access to the registry which
will hold the things you would've put in app_globals.
> I was disconcerted when I looked at the SQLAlchemy docs last week and
> the entire API section seemed to be missing. I actually thought it was
> a bug and figured it would come back in a few days. Then I noticed
> that the API docs were integrated with the narrative sections rather
> than all together. I'm not sure if I like it or not. Do all the API
> sections have narrative sections? Because sometimes I need to look up
> an undocumented method, e.g., to access column metadata in a program.
Good point, lets try a single reference API section for now, but
organized differently than Sphinx generally does it. I.e., rather than
just an unhelpful module listing of all the various bits, we'll
organized the API docs by topic. Caching, Sessions, Database, Request/
Response, Exceptions, etc. I think that'd make the module API much
easier to go through for detail on all the options various methods/
classes can take.
> Do you mean just changing the message to "ImportError: please install
> the 'formencode' package", or something more elaborate?
Well, no, I just mean that it'll only define the legacy things if
formencode is present. So that its not actually required to install
formencode.
On a side-note, when using the "renderer=" approach to rendering a
template, the dict results go into the template global namespace....
should they instead go into tmpl_context?
Cheers,
Ben
--
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.
