Comments to Chris' comments. > MO: The static files are moved; they’re in the templates directory rather > than in “hello/static”.
> CM: I think we'll want to move the static files out of the templates directory and up into a peer of the templates directory. I made a mistake here. The traditional Pylons location is hello/public. not hello/static .So it's up to Ben whether to rename the location. There are arguments both ways. "static" is a more standard term, but "public" is backward compatible. But why are they in hello/templates/static in the first place? Is that what BFG normally does? It surprised me because they're not templates. But I can vaguely see the logic if you consider "template" and "renderer" in a broader sense than just template engines. Ben, what do you want to do with static files? I'm assuming they're staying where they are for now. > MO: Routes-like traversal is built into BFG > CM: "routes-like traversal" is probably not the right term. "Routes-like pattern-based URL dispatch" might be better. Routes does not dispatch [i.e., instantiate the class and call the method]. Routes just parses the URL and returns a dict of variables. So maybe "Routes-like URL parsing" would be more accurate. > MO: we could add our own middleware by wrapping the WSGI application before returning it > CM: Note that I *think* it's Ben's intent to encourage people to add middleware by putting it into a ``pipeline`` stanza in the Paste ``.ini`` file rather than by adding it imperatively by wrapping the result of ``make_wsgi_app``. Not that the latter can't be done, but it makes things like "paster shell" impossible to write without additional framework to handle excluding middleware when a shell is run. 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? Ben, what do you want me to do here? > CM: I suppose an introductory paragraph about BFG would be helpful somewhere > in here. I punted on that because I'm still figuring out how to present it. It may go on another page. I want to separate the basic introduction, the application code, a detailed look of differences between Pylons 1 and Pylons 2, and enough BFG to understand the BFG manual and how it relates to Pylons. I.e.,which parts Pylons uses and which parts are alternative application styles that Pylons doesn't use. Those Configurator.add_* methods are one example. > CM: the ability to share a well-known table-space for user data What does this mean? > 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. I see repoze.bfg.jinja2 exists in PyPI. At some point we'll need a repoze.bfg.genshi in case people have existing templates that don't work with Chameleon. > CM: + [filter:evalerror] + use = egg:WebError#evalerror + + [pipeline:main] + pipeline = evalerror So I guess I'll have to explain pipelines right up front. What's the best way to figure out the entry point name to use and the right syntax, for any arbitrary entry point? What about logging? Are we keeping the logging-in-the-same-INI-file paradigm? Whose responsibility is it to activate it? 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. -- 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.
