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.
