Max Ischenko wrote:
> Hello,
>
> I have created a Pylons project (with paster create --template=pylons
> qw) and I am a bit intimidated with amount of data pre-generated for
> me: 33 files with 573 lines in them (16Kb)! Similar situation in
> TurboGears, btw.
>
> Is it really necessarily? Is it because no one yet figured out how to
> simplify things or this approach does provide some benefits?
Well, there's a bit of a conflict I suppose. Of course there's the
minimal template, which is a bit better. But the reason for the size is
mostly setting up the middleware stack, and some extra components (like
Myghty and the file paths).
So I guess there's a couple locations that have a lot of substantive
content:
config.routing:
Not really that bad; just lots of comments. Most of the file can
be usefully edited.
config.environment:
Mostly setting up some Myghty paths. This doesn't seem very
interesting or worth editing.
config.middleware:
This one is quite large. It has two config objects (a bit
confusing), and then it sets up some of the mini-apps (e.g.,
static_apps) and middleware.
Some of the middleware doesn't need to be there. E.g., PylonsApp
could apply ConfigMiddleware by default. Probably httpexceptions could
be in place by default too, since it always should be tightly bound to
the app anyway.
In Paste WebKit, I basically have that "asbool(full_stack)" in the
upstream code (not in the generated code), so everything gets
constructed based on that, and if you want to change the stack you just
turn it all off and put it into place yourself.
In a recent projects I have had reason to fiddle with this file
quite a bit, so that it's generated has worked fine for me. But then
I'm probably not typical that way.
controllers.error & template:
template is basically just a docstring. The error handler seems
reasonable.
lib.globals:
Mostly a docstring
lib.base:
A bunch of imports; all the stuff you use in your controllers. I
don't think this can be usefully trimmed without moving all the imports
into individual controllers.
After looking at it all, I don't see a lot to be trimmed down. But
that's based on using Pylons as a full-stack framework. I think
mini-apps are also valid to extract; I opened a ticket about that here:
http://pylonshq.com/project/pylonshq/ticket/148 -- that would require
controllers to be much more independent of the environment they are
running in.
--
Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~----------~----~----~----~------~----~------~--~---
