Re: Pylons 2 users guide, first draft
Hi,
from pylons.views import action
from ebro.db import DBSession as db
from ebro.sf import SFSession as sf
from pylons.controllers.util import Response
class MyHandler(object):
def __init__(self, request):
self.request = request
def login(self):
login = db.load_form('login.kk') # Pyro
response = Response(login)
response.content_type = 'application/vnd.mozilla.xul+xml'
The remote template is works well.
Thanks
kk
On Sep 30, 8:02 pm, Ben Bangert b...@groovie.org wrote:
On Sep 30, 2010, at 9:43 AM, Mike Orr wrote:
CC'ing pylons-devel because these will be FAQs.
@action
def login(self):
login=(db.load_form('login.kk'))
self.request.response_content_type =
'application/vnd.mozilla.xul+xml'
return login
@action
TypeError: __init__() takes exactly 1 argument (2 given)
The constructor is called with a request argument:
def __init__(self, request):
self.request = request
And @action is a decorator that requires arguments. Using @action is only
needed if you need to tweak the default's, ie, to limit the calling to a
request_method, or to assign a renderer. If you're doing something like:
config.add_handler('home_page', '/', handler=Home, action='index')
Then you don't need to use @action if its going to return its own Response
object.
So the easy way to think of it, the methods in your handler are all actions
still (just like in a Pylons 1 controller!), *but*, if you need to modify how
the action is called, how the return value of it is handled (ie, using
renderer), or how the action is registered (ie, its name), then you use the
@action decorator to modify those parameters.
def login(self):
login=(db.load_form('login.kk'))
self.request.response_content_type =
'application/vnd.mozilla.xul+xml'
return login
from pylons.controllers.util import Response
Then return a response object:
def login(self):
login = db.load_form('login.hh')
response = Response(login)
response.content_type = 'application/vnd.mozilla.xul+xml'
return response
There is also a render_template_to_response() function somewhere,
maybe in pylons.templating. It fills a template and creates a response
and returns it.
Yup.
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.
Re: Pylons 2 users guide, first draft
CC'ing pylons-devel because these will be FAQs.
On Wed, Sep 29, 2010 at 10:55 PM, Alagu Madhu alma...@gmail.com wrote:
I was thinking of:
@action
def login(self):
self.request.response.content_type = application/vnd.mozilla.xul+xml
login=ts.load_form('login.kk')
return login
If that doesn't work, remove the @action line entirely.
--
Thanking you for your support...
1.
@action
def login(self):
login=(db.load_form('login.kk'))
self.request.response_content_type =
'application/vnd.mozilla.xul+xml'
return login
@action
TypeError: __init__() takes exactly 1 argument (2 given)
The constructor is called with a request argument:
def __init__(self, request):
self.request = request
2.
def login(self):
login=(db.load_form('login.kk'))
self.request.response_content_type =
'application/vnd.mozilla.xul+xml'
return login
ValueError: Non-response object returned from view named (and no renderer):
So you have to return the response object.
response = self.request.response
response.convent_type = application/vnd.mozilla.xul+xml
response.body = db.load_form(login.kk)
return response
There is also a render_template_to_response() function somewhere,
maybe in pylons.templating. It fills a template and creates a response
and returns it.
--
Mike Orr sluggos...@gmail.com
--
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.
Re: Pylons 2 users guide, first draft
On Sep 30, 2010, at 9:43 AM, Mike Orr wrote:
CC'ing pylons-devel because these will be FAQs.
@action
def login(self):
login=(db.load_form('login.kk'))
self.request.response_content_type =
'application/vnd.mozilla.xul+xml'
return login
@action
TypeError: __init__() takes exactly 1 argument (2 given)
The constructor is called with a request argument:
def __init__(self, request):
self.request = request
And @action is a decorator that requires arguments. Using @action is only
needed if you need to tweak the default's, ie, to limit the calling to a
request_method, or to assign a renderer. If you're doing something like:
config.add_handler('home_page', '/', handler=Home, action='index')
Then you don't need to use @action if its going to return its own Response
object.
So the easy way to think of it, the methods in your handler are all actions
still (just like in a Pylons 1 controller!), *but*, if you need to modify how
the action is called, how the return value of it is handled (ie, using
renderer), or how the action is registered (ie, its name), then you use the
@action decorator to modify those parameters.
def login(self):
login=(db.load_form('login.kk'))
self.request.response_content_type =
'application/vnd.mozilla.xul+xml'
return login
from pylons.controllers.util import Response
Then return a response object:
def login(self):
login = db.load_form('login.hh')
response = Response(login)
response.content_type = 'application/vnd.mozilla.xul+xml'
return response
There is also a render_template_to_response() function somewhere,
maybe in pylons.templating. It fills a template and creates a response
and returns it.
Yup.
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.
Re: Pylons 2 users guide, first draft
hi,
Pylons 1.0:
def login(self):
response.content_type = 'application/vnd.mozilla.xul+xml'
login=st.load_form('login.kk')
return login
I would like to try in Pylons 2.0.The template source
(st.load_form('login.kk') ) load from the remote server.
thanks
kk
On Sep 25, 8:21 pm, Chris McDonough chr...@plope.com wrote:
On Sat, 2010-09-25 at 09:27 -0700, Ben Bangert wrote:
On Sep 25, 2010, at 4:43 AM, Santhosh wrote:
I checked the new developing version of pylons .The new version is
entirely different from the older version . How can the developers
follow this ? .The developers compelled to have change the developed
software because if they remain in the older version there may be have
no support .
I don't understand what you mean by How can the developers follow this?.
I posted the entire thread here to try and help any other developers follow
it.
It's quite different, because the current Pylons 1.0 implementation is more
or less frozen, the implementation of most of it can't be changed since
so much of it was directly subclassed by developers in their own apps. This
style of customization was useful, but led to practical limitations on
extensibility, and our own ability to move Pylons forward. Rather than
re-inventing a bunch of code all over again, this new version went forward
to build on other code to allow the new Pylons to be substantially more
extensible, more efficient, and not have developers subclassing objects
from Pylons (which limits our ability to make changes to the framework).
I don't see what the worry is about remaining on the older version, the
Pylons book and the documentation is not going anywhere. The same level of
documentation support is going to remain available for Pylons 1.0, as there
is a large installed base that most likely isn't transitioning all that
quickly. There is no book for the new Pylons paradigms yet, so you'll see a
much higher level of 'support' in the way of blog postings, and
documentation for 1.0 for some time to come I believe.
The trunk is also currently entirely bw compatible with Pylons 1.0. You
don't *need* to use the new features.
--
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.
Re: Pylons 2 users guide, first draft
Dear all I checked the new developing version of pylons .The new version is entirely different from the older version . How can the developers follow this ? .The developers compelled to have change the developed software because if they remain in the older version there may be have no support . Please clear the doubts about this . Thanks and Regards -- 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.
Re: Pylons 2 users guide, first draft
On Sep 25, 2010, at 4:43 AM, Santhosh wrote: I checked the new developing version of pylons .The new version is entirely different from the older version . How can the developers follow this ? .The developers compelled to have change the developed software because if they remain in the older version there may be have no support . I don't understand what you mean by How can the developers follow this?. I posted the entire thread here to try and help any other developers follow it. It's quite different, because the current Pylons 1.0 implementation is more or less frozen, the implementation of most of it can't be changed since so much of it was directly subclassed by developers in their own apps. This style of customization was useful, but led to practical limitations on extensibility, and our own ability to move Pylons forward. Rather than re-inventing a bunch of code all over again, this new version went forward to build on other code to allow the new Pylons to be substantially more extensible, more efficient, and not have developers subclassing objects from Pylons (which limits our ability to make changes to the framework). I don't see what the worry is about remaining on the older version, the Pylons book and the documentation is not going anywhere. The same level of documentation support is going to remain available for Pylons 1.0, as there is a large installed base that most likely isn't transitioning all that quickly. There is no book for the new Pylons paradigms yet, so you'll see a much higher level of 'support' in the way of blog postings, and documentation for 1.0 for some time to come I believe. 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.
Re: Pylons 2 users guide, first draft
On Sat, 2010-09-25 at 09:27 -0700, Ben Bangert wrote: On Sep 25, 2010, at 4:43 AM, Santhosh wrote: I checked the new developing version of pylons .The new version is entirely different from the older version . How can the developers follow this ? .The developers compelled to have change the developed software because if they remain in the older version there may be have no support . I don't understand what you mean by How can the developers follow this?. I posted the entire thread here to try and help any other developers follow it. It's quite different, because the current Pylons 1.0 implementation is more or less frozen, the implementation of most of it can't be changed since so much of it was directly subclassed by developers in their own apps. This style of customization was useful, but led to practical limitations on extensibility, and our own ability to move Pylons forward. Rather than re-inventing a bunch of code all over again, this new version went forward to build on other code to allow the new Pylons to be substantially more extensible, more efficient, and not have developers subclassing objects from Pylons (which limits our ability to make changes to the framework). I don't see what the worry is about remaining on the older version, the Pylons book and the documentation is not going anywhere. The same level of documentation support is going to remain available for Pylons 1.0, as there is a large installed base that most likely isn't transitioning all that quickly. There is no book for the new Pylons paradigms yet, so you'll see a much higher level of 'support' in the way of blog postings, and documentation for 1.0 for some time to come I believe. The trunk is also currently entirely bw compatible with Pylons 1.0. You don't *need* to use the new features. -- 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.
Re: Pylons 2 users guide, first draft
On Sep 20, 2010, at 10:17 PM, Mike Orr wrote: How many full-time staff do you have available for two months? Just converting the hundreds of references to plain text would take hours, plus rewording the hundred-some pages of BFG docs and hundred-some other docs and a few more for SQLAlchemy (or you want to put the entire SQLAlchemy manual in too). The Encyclopedia of Pylons! I don't consider SQLAlchemy to be 'core' to Pylons, the core things are: - Sessions - Caching - Request Object - Response Object - Configuration - Dispatch - Template Rendering - Extensibility Points I really hope it doesn't take hundreds of pages of text to cover those. Hundreds and hundreds of pages and full-time staff are what books are for. If someone feels like that, they should write a book. :) Since many people use relational databases, we'll of course document how to write an app with it, like we do now. Anyways, I'll give it a shot first, and we'll see how it goes. -- 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.
Re: Pylons 2 users guide, first draft
I need to add content_type. On Sep 20, 5:19 am, Chris McDonough chr...@plope.com wrote: On Sun, 2010-09-19 at 19:11 -0700, Ben Bangert wrote: On Sep 19, 2010, at 7:01 PM, Chris McDonough wrote: My $.02.. if you don't have a threadlocal tmpl_context around for people to jam values onto/into, it'd just confuse people if the dict values they returned from a view weren't passed as top-level names to the template, and instead were made available as the subkey tmpl_context. Well, there is a tmpl_context created on the request, that is available in templates as well. So it is around, created per-request as in Pylons 1.0, for ppl to add things to. So it might seem like a disconnect when someone add's things to tmpl_context in one case, but then it gets dropped in as a template global under the 'renderer=' scenario. Having everything a person wants to pass in, always go in under tmpl_context seems more consistent. Drawing an equivalence between Pylons 1 and 2 by having a request.tmpl_context seems like a bit of lose to me, because what people like about Pylons 1 tmpl_context is that they don't need to pass it around and they can just jam crap on to it from anywhere. Needing to both pass the request around as well as needing to write templates in terms of a tmpl_context seems like the worst of both worlds to me personally. What would the view return value mean in such a world? It just seems like a lot of indirection to document, and it would also mean forks of all the existing BFG templating systems. - 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.
Re: Pylons 2 users guide, first draft
self.request.response_content_type = 'application/vnd.mozilla.xul+xml' thanks kk On Sep 20, 2:13 pm, Madhu Alagu alma...@gmail.com wrote: I need to add content_type. On Sep 20, 5:19 am, Chris McDonough chr...@plope.com wrote: On Sun, 2010-09-19 at 19:11 -0700, Ben Bangert wrote: On Sep 19, 2010, at 7:01 PM, Chris McDonough wrote: My $.02.. if you don't have a threadlocal tmpl_context around for people to jam values onto/into, it'd just confuse people if the dict values they returned from a view weren't passed as top-level names to the template, and instead were made available as the subkey tmpl_context. Well, there is a tmpl_context created on the request, that is available in templates as well. So it is around, created per-request as in Pylons 1.0, for ppl to add things to. So it might seem like a disconnect when someone add's things to tmpl_context in one case, but then it gets dropped in as a template global under the 'renderer=' scenario. Having everything a person wants to pass in, always go in under tmpl_context seems more consistent. Drawing an equivalence between Pylons 1 and 2 by having a request.tmpl_context seems like a bit of lose to me, because what people like about Pylons 1 tmpl_context is that they don't need to pass it around and they can just jam crap on to it from anywhere. Needing to both pass the request around as well as needing to write templates in terms of a tmpl_context seems like the worst of both worlds to me personally. What would the view return value mean in such a world? It just seems like a lot of indirection to document, and it would also mean forks of all the existing BFG templating systems. - 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.
Re: Pylons 2 users guide, first draft
On Sun, Sep 19, 2010 at 6:36 PM, Ben Bangert b...@groovie.org wrote: 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. It's a good enough name for now. It does connote an entire a rather than just the URL (cf. webhelpers.html.tags.link_to()). But I can't think of a better name. 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. Well, hopefully '.. autoclass' will work if the package is installed. WebHelpers and other packages uses '.. autoclass' extensively. It's one thing to copy ReST documentation from another package. It's another thing to reconstruct the ReST from the HTML or paste it directly from the docstrings. which is what you'd have to do if autoclass doesn't work. -- Mike Orr sluggos...@gmail.com -- 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.
Re: Pylons 2 users guide, first draft
On Mon, 2010-09-20 at 13:41 -0700, Mike Orr wrote: On Sun, Sep 19, 2010 at 6:36 PM, Ben Bangert b...@groovie.org wrote: 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. It's a good enough name for now. It does connote an entire a rather than just the URL (cf. webhelpers.html.tags.link_to()). But I can't think of a better name. 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. Well, hopefully '.. autoclass' will work if the package is installed. WebHelpers and other packages uses '.. autoclass' extensively. It's one thing to copy ReST documentation from another package. It's another thing to reconstruct the ReST from the HTML or paste it directly from the docstrings. which is what you'd have to do if autoclass doesn't work. The problem isn't the tool's ability to find the implementation and use its existing documentation. That we have down pretty much cold, and it will work just fine. The problems are instead: - :ref: links buried inside docstrings of the existing BFG implementation docstrings which point at BFG narrative documentation. These will point off to nowhere when the same documentation is rendered as part of the Pylons doctree. - Ben wants to create a facade Pylons API for all (most?) BFG APIs. Existing BFG implementation docstrings have :class:, :function:, :method:, etc references buried inside then, which, for Pylons will point to the wrong places (each will point at the BFG dotted name instead of the Pylons dotted name). I am willing to remove unnecessary references from BFG docstrings to help slightly here, but I don't think it will help much. I can't remove them all: their existence is deliberate, to help people navigate the BFG docs. I think the best bet would be some sort of facade generator which not only creates the Pylons facade module(s) for BFG functions, but which also scrubs or modifies the docstrings of BFG APIs. - 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.
Re: Pylons 2 users guide, first draft
On Mon, 2010-09-20 at 13:50 -0700, Mike Orr wrote: On Sun, Sep 19, 2010 at 7:01 PM, Chris McDonough chr...@plope.com wrote: On Sun, 2010-09-19 at 18:36 -0700, Ben Bangert wrote: Yea, we're going to have to compose copy/paste to an extent, from the other docs. I've indicated to Ben that I am willing to genericize the BFG docs to some extent by not linking to internal stuff in API documentation needlessly. But I doubt this will really do much good; there are places where those kinds of links are just required. It will probably boil down to everything needing to be cutnpasted. Most of the other Pylons dependencies are pretty solidified so they shouldn't change much, and when they do it's some obscure feature rather than the basic Pylons API. For BFG, we'll have to see how the documentation comes out, how much of it refers to things that are changing. As long as you're aware of which parts of the API the Pylons docs cover, it should be pretty easy to remember, This part affects the Pylons docs. Especially as we'll be covering only a Pylons-typical application, and referring directly to the BFG docs for anything beyond that. AFAIK, Ben doesn't want to do that. He wants all the docs presented in terms of Pylons, not punting to the BFG docs for anything at all. - 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.
Re: Pylons 2 users guide, first draft
On Mon, 2010-09-20 at 21:09 -0700, Ben Bangert wrote: On Sep 20, 2010, at 2:58 PM, Mike Orr wrote: BFG is bigger than all the other Pylons dependencies combined. We can't have 30% of the Pylons manual referring to BFG features that aren't normally used in Pylons apps, especially if Pylons has a more specific way to enable it. Indeed, but after looking through the BFG docs, I'm having difficulty finding something that people might not need to reference. Chris had mentioned he planned on trimming quite a bit from the BFG docs as they are overly verbose (650 pages printed apparently!), so I think there's room to trim and be more concise. Pylons won't be documenting it quite the same either, the declarative way (using ZCML) will be relegated to a single chapter for those that want/need to use it. I will probably get rid of some stuff in the next book release, but it's going to be at least 500 (printed) pages even trimmed. A lot of that is narrative and tutorial content, which you probably either don't want or you want to carve out and present in a Pylons-ish fashion. The API docs without the rest of the stuff is about 100 pages. - 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.
Re: Pylons 2 users guide, first draft
On Mon, Sep 20, 2010 at 9:09 PM, Ben Bangert b...@groovie.org wrote: On Sep 20, 2010, at 2:58 PM, Mike Orr wrote: BFG is bigger than all the other Pylons dependencies combined. We can't have 30% of the Pylons manual referring to BFG features that aren't normally used in Pylons apps, especially if Pylons has a more specific way to enable it. Indeed, but after looking through the BFG docs, I'm having difficulty finding something that people might not need to reference. Chris had mentioned he planned on trimming quite a bit from the BFG docs as they are overly verbose (650 pages printed apparently!), so I think there's room to trim and be more concise. Pylons won't be documenting it quite the same either, the declarative way (using ZCML) will be relegated to a single chapter for those that want/need to use it. It sounds like we need a preprocessor to import documentation sources and sanitize foreign cross-references. Can that be done as a Sphinx plugin? That sounds like it might be more effort than just copy/pasting the bits we need in, and ensuring their docs flow well with the rest of the Pylons docs. How many full-time staff do you have available for two months? Just converting the hundreds of references to plain text would take hours, plus rewording the hundred-some pages of BFG docs and hundred-some other docs and a few more for SQLAlchemy (or you want to put the entire SQLAlchemy manual in too). The Encyclopedia of Pylons! -- Mike Orr sluggos...@gmail.com -- 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.
Re: Pylons 2 users guide, first draft
On Sep 19, 2010, at 6:36 PM, Ben Bangert wrote: BTW, for anyone else that just saw this message appear apparently out of the blue, Google Groups does have the full thread but failed to e-mail it out. To catch up, just go to: http://groups.google.com/group/pylons-devel/browse_thread/thread/cf357889d81e37b3 - 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.
Re: Pylons 2 users guide, first draft
On Sun, 2010-09-19 at 19:11 -0700, Ben Bangert wrote: On Sep 19, 2010, at 7:01 PM, Chris McDonough wrote: My $.02.. if you don't have a threadlocal tmpl_context around for people to jam values onto/into, it'd just confuse people if the dict values they returned from a view weren't passed as top-level names to the template, and instead were made available as the subkey tmpl_context. Well, there is a tmpl_context created on the request, that is available in templates as well. So it is around, created per-request as in Pylons 1.0, for ppl to add things to. So it might seem like a disconnect when someone add's things to tmpl_context in one case, but then it gets dropped in as a template global under the 'renderer=' scenario. Having everything a person wants to pass in, always go in under tmpl_context seems more consistent. Drawing an equivalence between Pylons 1 and 2 by having a request.tmpl_context seems like a bit of lose to me, because what people like about Pylons 1 tmpl_context is that they don't need to pass it around and they can just jam crap on to it from anywhere. Needing to both pass the request around as well as needing to write templates in terms of a tmpl_context seems like the worst of both worlds to me personally. What would the view return value mean in such a world? It just seems like a lot of indirection to document, and it would also mean forks of all the existing BFG templating systems. - 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.
Re: Pylons 2 users guide, first draft
On Sun, Sep 12, 2010 at 5:13 PM, Chris McDonough chr...@plope.com wrote:
I saw that pipeline in an example INI Ben showed me, but I didn't
realize he wanted to do it across the board. I have never liked IN I
pipelines; they're hard to understand and non-Python syntax (which
means it could be hard to trace why it can't find one of the
components, for instance). What middleware does paster shell
exclude?
It exludes every piece of middleware (or should).
Note that the following currently this works in lieu of paster shell,
assuming you've named your newminimal project Hello:
paster bfgshell development.ini Hello
Or, for reasons I don't quite understand, you might need:
paster --plugin=repoze.bfg bfgshell development.ini Hello
This works because the second arg to paster bfgshell, Hello, is the
real application object as defined in the Paste .ini file. It will
not work if Hello is wrapped in any middleware, however.
I had always suggested to Ben that paster shell should run a fake request to a
fake responder, but he never took me up on that. Since things are being
rethought maybe that can be rethought too. Like:
class PasterShell:
def run(self):
app = getapp()
req = Request.blank('/PasterShell')
req.environ['paste.paster_shell'] = True
resp = req.get_response(app)
Then in the routing special case that environmental variable and/or path.
You'd want to do this wherever it's closest to the app. E.g., PylonsApp? I
don't know what that will be in the new system. But the controller would just
call cmd, ipython, whatever. Both request and response are superfluous, but
you will be entirely within the context of any middleware, configuration, etc.
You could implement all commands this way if you wanted to (shell, setup-app,
etc).
--
Ian Bicking | 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 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.
Re: Pylons 2 users guide, first draft
On Sun, 2010-09-12 at 15:29 -0700, Ben Bangert wrote: On Sep 12, 2010, at 3:13 PM, Chris McDonough wrote: What's the best way to figure out the entry point name to use and the right syntax, for any arbitrary entry point? It's egg:DistributionName#entrypointname The entry point names for a given package are in EGG-INFO/entrypoints.txt . Paste defaults to using the name main as the entry point name, so these two Paste names are equivalent: Also, not sure what type of license Ian has his Paste docs under, but I want to pull in the necessary information about how to configure INI files, such that a user doesn't have to go to the PasteDeploy docs to look-up how to set a filter middleware, etc. Having this in one Configuration section of the Pylons docs also means we can provide a list of all the available middleware (and entry point names!) so that someone could look through, see what they want in their stack, and easily add it to the appropriate INI file (cause the dev.ini will prolly differ from the prod.ini). Right now, its kind of a pain to: A) See what middleware is available with stock Pylons B) Figure out what the heck the entry point name is, without which, you can't use it in the INI file, I usually have to read the source to find the damn entry point names, we should save our users from doing that C) Know what options each piece of middleware can take in the INI file Most of this is already handled via paster points, e.g. do env/bin/paster points paste.filter_app_factory in a virtualenv that has Pylons installed. What that doesn't do is give you the egg name, although you don't really need the egg name; it gives you the dotted name to the middleware factory, which can also be used. - 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.
Re: Pylons 2 users guide, first draft
Hello (capitalized) is working now, and the interactive traceback. I adjusted the guide for those and for the new location of the static files. I adjusted the text for describing Routes and CM's other points. -- Mike Orr sluggos...@gmail.com -- 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.
Re: Pylons 2 users guide, first draft
On Sun, Sep 12, 2010 at 3:13 PM, Chris McDonough chr...@plope.com wrote: CM: the ability to use a common main template for theming That's good. the more we can describe the practical benefits, the better. There are several things like theming and a grandparent site template for subapplications that Pylons users haven't done because they're so cumbersome in the old structure. Sorry if it wasn't clear, but for the record, when I mentioned a shared main template, it was in the context of saying that Pylons *isn't* the right layer at which a normal user should try to compose a system out of a bunch of random pre-written third-party applications. IMO, allowing a user to plug in some random third-party application and making it easy to have a common main template (or other theme) between all such applications, and mediating access to a data store that must be shared between arbitrary applications is something that Pylons should just not try to do. Instead, a higher-level system should be built atop Pylons that allows for a saner composition of reusable applications (one with enough constraints in it to make the result of plugging them together more predictable). On the other hand, Pylons *should* (and does) allow for a single existing application to be extended and overridden, and it does allow a composition of non-reusable applications to be created and deployed by a *single* developer. It just isn't the piece that will allow an integrator to collect up a bunch of applications that a bunch of random people have written and plug them all together to form a cohesive system; it doesn't have enough constraints to allow that to happen in a sane way (the Django folks are hitting this wall right now, and I don't think we want to follow them down that path). We'll have to look at this later. My main application at work is a collection of independent components that share the same domain and login. I've kept it as one big application because Pylons is so unfriendly to nested apps (how to integrate the templates and routing?), and it was moreso when the app was written two years ago. So I have a site template, section templates, and page templates, which all inherit from each other. Anyway, I think we should provide suggestions on how to compose apps like this later. What about logging? Are we keeping the logging-in-the-same-INI-file paradigm? Whose responsibility is it to activate it? Probably should still live in INI file. I suppose a logging configuration may not belong in the minimal application, but in that case I'd have to provide the code to paste in. (Maybe using paste.translogger as a sample middleware that uses logging.) On the other hand, it can be argued that logging is so central to everything, it belongs in the minimal application. Especially because libraries may log, and there really should be handlers and formatters already set up for it in that case. Should be fine to add that configuration there. I guess that means myapp/__init__.py will have to initialize the logging. Because who else will? This might be good to make the logging activation explicit. One problem with paster serve is nobody can figure out where logging is activated or why it doesn't automatically work with paster shell or custom commands. It gives the impression that Paste activates the logging as a basic Paste service, but it doesn't, paster serve or something below it does. -- Mike Orr sluggos...@gmail.com -- 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.
Re: Pylons 2 users guide, first draft
On Sep 13, 2010, at 12:09 AM, Mike Orr wrote: I'll move some of the background paragraphs into separate pages. But this page will focus on the minimal app. Do you have any sample applications in both Pylons 1 and Pylons 2 that I can include? The more sophistocated one with multiple actions and a redirect may be a start. Not at the moment. Where is pylons.url now? request.url? from pylons.url import route_url Then just, route_url(request, 'route_name', **extra_args). It works largely like the BFG route_url, except honors an additional URL generator option that a route can have. This is how I have a sub-domain setup implemented. I'll prolly have to move route_url elsewhere, as there's a 'url' object hanging out in pylons/__init__.py. That may be too much to manage this phase. But I can link to the manuals. I guess I can make a Makefile that checks out the repositories of all the dependencies, and let Sphinx recursively build all the manuals. It started doing that with BFG and Pylons unexpectedly until I excluded their parent directory in conf.py. Ah, unfortunately that won't be good enough. Chris and I had chatted about trying to do something with Makefiles so that things would be included, but unfortunately this means that the included stuff retains reference to its own docs. This creates a very hacked up reading experience that is not going to be pleasant. I think we need the distinction for the transitional phase. Existing Pylons users need to understand where everything is. So they can find the docstrings in the source code, for one thing. And I, as a reader, would certainly want to know where the different Request methods come from. Otherwise it's too confusing, especially if I'm trying to figure out how Request changed. Well, I guess I just mean that I wouldn't waste the reader's time explaining the history of every object they might want to use, vs just saying, here is where you import the Request from, and then linking to its API docs. Our API docs can mention where it comes from, which methods come from where, etc. There's no reason to bog down the documentation explaining things that the reference API can explain as it documents the objects. This also means that as we document *everything* we expect Pylons users to have, we can include doc strings with Sphinx as needed, and editorialize them ourself as well. Sphinx makes it quite easy to ignore doc strings, or ignore module docs and supply your own. That'd be a good place to add in additional info about what comes from where, etc. If the docs are written with the expectation of a first-time Pylons user, then an existing Pylons user should be helped just as much to see where things are. I don't think de-emphasizing all the packages involved means that someone wouldn't know where something they need to use it. It just means we wouldn't waste the users time explaining the history of XX, or why ZZ was done. Keep the focus on how to do it, where the objects they need to import are, and point them to the reference API for said objects. I plan on adding a Design Defense page similar to what repoze.bfg has, that explains the 'why' of the design decisions in Pylons, so we can avoid repeating explanations throughout the docs, which should keep a tight focus on what the developer needs to know to get going. Then have a section for migrating users that explains what moved where, how to use new features with an existing app using the legacy_view, etc. For example, take sessions, Pylons 2 has an add_sessions that sets them up, and a request.session object they make use of for the session. I would imagine the Sessions section would indicate that you use add_sessions, how to use the request.session object, how to change the configuration options, and then send the user to the Session API docs. The Session API docs would include the complete set of configuration options, include any relevant info on the package (Beaker) that actually implements the sessions, and then have all the relevant module docs someone wanting all the details would need. This keeps the How to use Sessions bit short, concise, and fast for a developer to get going with, and then leaving the Reference API section to fully document the additional configuration options, what objects come from where, what type they are, etc. The existing Pylons user will generally jump straight to the Reference section when they need to know about an object, or its methods, or configuring it since they already know *how to use* it. Alternatively, a documentation style that might be worth trying, is what Mike Bayer has done with the latest version of the SQLAlchemy docs, which I'm kind of liking. That is, we'd have a Pylons Overview chapter, that includes a short bit on how to do all the standard things a Pylons user would want to do. Installation, Hello World, Using Sessions, etc. Each one then links to the full chapter, and the
Re: Pylons 2 users guide, first draft
On Sep 13, 2010, at 11:49 AM, Mike Orr wrote: Can it be made into a request method so you don't have to pass the request object? That would be more OO. Sure, request.url though makes it ambiguous if its the request URL vs a url function. Ian called it request.link in his example app using Routes, so maybe something like that? 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. Yes, you paste in the ones where appropriate (some of the sub-projects have none, or little docs, so we'd have to write those). This is part of the main issue btw, when we punt on doing it and just tell people to go look at that, and then the docs we pointed them to are incomplete, fail to mention how it applies in the context of the framework, etc. we just fail. Yes, it takes time to document the big picture and its parts effectively, in some cases we can copy/paste or still have Sphinx auto-generate an objects doc from the doc-string still, but in other cases we'll have to fill in gaps. Regardless of how its done, using and documenting Pylons as it consists of other projects requires time to keep the docs up to date as dependencies change. We're not doing anyone a favor by not addressing this issue at the moment. I don't think this means we need to document *all* of every single project, but we need to copy the docs or document anything ourself which we expect a Pylons developer to use that comes with Pylons. Except for BFG, the other dependencies are pretty much 'done' though, their docs aren't changing as they're not really changing anymore. Easy for you maybe. I still have to pour through the Sphinx manual sometimes wishing it would explain more clearly how to do something. If we could sprint together it would be easier. Agreed. 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. Oh, I'd never aim it at a total non-Python or non-webdev. That's what books are for. Pylons documentation is for: 1) How do I do XXX with Pylons? 2) What are all the options to do XXX with Pylons? 3) How do I extend and utilize other web dev patterns with Pylons? These leads to a set of docs that are generally fairly short and concise to go over how to do various things (prolly a Quick Start / Overview), where each section hyperlinks them to the more extensive web dev patterns of that topic, all of which link to the reference docs (which show all the options). Once you know how add_sessions works, there's really no point in wasting space in the narrative docs explaining each option, when just a list of all the options and what they do would work just as well. The latter being the reference API docs. 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. Sure, sounds good. I don't think I've encountered legacy_view yet. How does it work? There's a legacy pylons template that shows it. It essentially lets you hook up an existing Pylons app with zero changes, and then start adding new handlers with the Configurator. BTW, where is the cache? No where right now. Technically all you need to do is import the cache module from Beaker, set the options, and use @cache_region as desired. I should prolly add a setup function for that on the configurator and an import in Pylons though, as that'll make it feel more cohesive. 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. Technically, those can be added to the application registry as 'utilities', but it'd make sense maybe to have a config arg that lets you designate some functions that want to setup 'global' type objects, and when configuration is completely done, it'd call those functions and let them set it up. That'd also ensure that they're only setting up the 'app globals' when all the config information is available. 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
Re: Pylons 2 users guide, first draft
On Sun, Sep 12, 2010 at 3:29 PM, Ben Bangert b...@groovie.org wrote: Also, not sure what type of license Ian has his Paste docs under, but I want to pull in the necessary information about how to configure INI files, such that a user doesn't have to go to the PasteDeploy docs to look-up how to set a filter middleware, etc. I'm not worrying about licenses now. I assume the licenses will be adjusted before release to allow any parts to be pasted into the Pylons guide. I thought that was already the case anyway. Everything's MIT-based, and if there is anything that's GPL, we're releasing the documentation sources anyway so it shouldn't matter. -- Mike Orr sluggos...@gmail.com -- 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.
Re: Pylons 2 users guide, first draft
On Mon, 2010-09-13 at 00:09 -0700, Mike Orr wrote: I notice that ``request[foo]`` shadows ``request.environ[foo]``. Has WebOb always done that? This is a behavior of the repoze.bfg subclass of WebOb (in repoze.bfg.request.Request). It's only for backwards compatibility with applications written for version 1.0 of BFG, and shouldn't be relied upon in user applications; it is not part of the request API and the behavior will be removed in BFG 1.4, or possibly sooner. For the general documentation, here are the directions Chris and I were thinking would be a big priority: - Integrated documentation This means that *everything* one needs to write and use Pylons 2 will be in a single spot. This will involve documenting everything that we expect a user to use, in the main Pylons docs. All the configuration options and how sessions work (from Beaker), all the methods they would want to use of the Request and Response object (from Pylons, BFG, and WebOb), all the docs on how to register handlers, views, etc. (from BFG/Pylons), how to test an application and the methods/object docs, and probably all the important bits someone will use in Mako templates. That may be too much to manage this phase. But I can link to the manuals. I guess I can make a Makefile that checks out the repositories of all the dependencies, and let Sphinx recursively build all the manuals. It started doing that with BFG and Pylons unexpectedly until I excluded their parent directory in conf.py. - Avoid mentioning what package provides what bit for the most part This helps make the entire framework feel like an integrated whole. And the majority of the time, no user really cares that the Request/Response are WebOb subclasses, that the Pylons Configurator is a BFG subclass, that the events they imported from Pylons are shadow points for BFG ones, etc. Maybe in an Advanced chapter, where the components are dived into in detail, then the background of where these things originate will be mentioned. For the new and average user though, they just make the docs longer, and add unnecessary information that makes it feel more hacky. (I know that right now the main reason all the origins are mentioned is mainly because Pylons avoids re-documenting them, which will no longer be the case.) I think we need the distinction for the transitional phase. Existing Pylons users need to understand where everything is. So they can find the docstrings in the source code, for one thing. And I, as a reader, would certainly want to know where the different Request methods come from. Otherwise it's too confusing, especially if I'm trying to figure out how Request changed. Later we can de-emphasize the packages, and make the documentation all Django-like. And get somebody to publish a new book! Hmm, I wonder if James, Noah, or Alfredo would want to mull that one over. But much of the content would come from this open source project, so it would be a different situation than a Manning/Apress/Packt book. We'd have to retain the copyright up front. I wonder which publishers would be willing to be just a printer and marketer. The package list you note there has me thinking that maybe we can drop decorator, FormEncode, Routes, and WebHelpers from the Pylons dependencies. This means that the things using it in the Pylons code-base will need to be wrapped in try/except imports so that everything still works for legacy apps with Pylons 2. Decorator is really a basic Python utility that belongs in the stdlib. It would be silly to drop it now if we might need it again later. You talked about a separate Pylons-FormEncode package. Although I don't know what it would include besides the dependency. Buit WebHelpers could go with that. What try/excepts? I don't think there's anything in the Pylons core or application template that imports FormEncode or WebHelpers. Routes is more central, of course. What's wrong with a Pylons1-Compatibility package like I suggested earlier. Just tell people they need to install that if they want to run a Pylons 1 applicaton under Pylons 2. It's similar to Pylons 0.10, which keeps compatibility code, but done in a different way. But if the try/excepts have to be in the application, we're kind of screwed, because we can't go auto-modifying people's applications and breaking them. The whole issue of excess dependencies will really have to be dealt with at another level. BFG pulls in a lot of things that aren't relevant to a typical Pylons application, like Chameleon. App Engine users will certainly be interested in what they can exclude from uploading. I think we can worry about that later, to provide a list or regexp of files that can be excluded. There's a bit of info about that for BFG here: http://docs.repoze.org/bfg/1.3/tutorials/gae/index.html#zipping-files-via-pip -- You received this message because you are
Re: Pylons 2 users guide, first draft
On Mon, Sep 13, 2010 at 12:33 AM, Chris McDonough chr...@plope.com wrote: I guess that means myapp/__init__.py will have to initialize the logging. Because who else will? I figured it would just go in the .ini file as before, and PasteDeploy would initialize it as always. Oh, duh, I didn't realize it would keep doing that, but of course it would. -- Mike Orr sluggos...@gmail.com -- 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.
Re: Pylons 2 users guide, first draft
On Mon, 2010-09-13 at 10:45 -0700, Ben Bangert wrote: On Sep 13, 2010, at 12:09 AM, Mike Orr wrote: I'll move some of the background paragraphs into separate pages. But this page will focus on the minimal app. Do you have any sample applications in both Pylons 1 and Pylons 2 that I can include? The more sophistocated one with multiple actions and a redirect may be a start. Not at the moment. Blaise Laflamme began this project: http://bitbucket.org/blaf/pylonswiking/overview . It's a transliteration BFG wiki example into newpylons. The code is in src, the rest of it is RST documentation. - 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.
Re: Pylons 2 users guide, first draft
On Mon, Sep 13, 2010 at 10:45 AM, Ben Bangert b...@groovie.org wrote: Where is pylons.url now? request.url? from pylons.url import route_url Then just, route_url(request, 'route_name', **extra_args). It works largely like the BFG route_url, except honors an additional URL generator option that a route can have. This is how I have a sub-domain setup implemented. I'll prolly have to move route_url elsewhere, as there's a 'url' object hanging out in pylons/__init__.py. Can it be made into a request method so you don't have to pass the request object? That would be more OO. That may be too much to manage this phase. But I can link to the manuals. I guess I can make a Makefile that checks out the repositories of all the dependencies, and let Sphinx recursively build all the manuals. It started doing that with BFG and Pylons unexpectedly until I excluded their parent directory in conf.py. Ah, unfortunately that won't be good enough. Chris and I had chatted about trying to do something with Makefiles so that things would be included, but unfortunately this means that the included stuff retains reference to its own docs. This creates a very hacked up reading experience that is not going to be pleasant. How would you do this then? If I have all the source repositories in a subdirectory and exclude them from auto-building, can I still link to subproject .rst files and it'll include all their dependencies? Does .. autoclass work through subprojects? 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. Sphinx makes it quite easy to ignore doc strings, or ignore module docs and supply your own. That'd be a good place to add in additional info about what comes from where, etc. Easy for you maybe. I still have to pour through the Sphinx manual sometimes wishing it would explain more clearly how to do something. If we could sprint together it would be easier. If the docs are written with the expectation of a first-time Pylons user, then an existing Pylons user should be helped just as much to see where things are. 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. Keep the focus on how to do it, where the objects they need to import are, and point them to the reference API for said objects. I plan on adding a Design Defense page similar to what repoze.bfg has, that explains the 'why' of the design decisions in Pylons, so we can avoid repeating explanations throughout the docs, which should keep a tight focus on what the developer needs to know to get going. 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. Then have a section for migrating users that explains what moved where, how to use new features with an existing app using the legacy_view, etc. I don't think I've encountered legacy_view yet. How does it work? BTW, where is the cache? 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. Alternatively, a documentation style that might be worth trying, is what Mike Bayer has done with the latest version of the SQLAlchemy docs, which I'm kind of liking. That is, we'd have a Pylons Overview chapter, that includes a short bit on how to do all the standard things a Pylons user would want to do. Installation, Hello World, Using Sessions, etc. Each one then links to the full chapter, and the full chapter goes into all the details, and includes the API docs in-line. 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. No, I meant in the places where Pylons is importing WebHelpers and FormEncode, it wraps the imports in try/excepts so that the legacy
