On Thu, 2010-11-11 at 00:46 -0800, Mike Orr wrote:
> On Wed, Nov 10, 2010 at 11:11 PM, Alexandre Conrad
> <alexandre.con...@gmail.com> wrote:
> > Hey Mike,
> >
> > I agree with you that having questions would be nice. And for people
> > not liking the questions, maybe we could have them answered
> > automatically by passing options such as --with-sqla --with-zodb
> > --with-mako --with-urldispatch, ... Just an idea.
>
> The question prompts are provided by "paster create". Supposedly you
> can pass variables at the end of the command line to pre-answer them
> but it hasn't worked for me.
>
> How do conditionals hinder application maintenance? Or should we just
> say that since it hasn't been a problem for Pylons maintainers, that
> level of complexity is OK. But if it gets much more complex it could
> be too much. E.g., ZODB should only need a couple of if's, but auth
> could require several if's and be too complex for the same template.
My current strategy for making paster template changes is this:
- I change the template.
- I use "paster create -t" to create an instance from the template.
- I run its tests.
- I make sure it runs, and I visit it in a browser.
This is definiltey a little silly and painful, there really should be
some automated tests for each template. But there isn't, because
writing automated tests for paster templates is harder than testing
"normal" code, so I haven't written any.
When we move to conditionalized templates, those steps become:
- I change the template.
- For each combination of features X*Y*Z:
- I use "paster create -t" to create an instance from the template
for the combination.
- I run its tests.
- I make sure it runs, and visit it in a browser.
So moving to conditionalized templates seems to imply:
- The risk that you will break one set of features by changing another
begins to exist. This isn't a problem for single-purpose templates
because they map to a single set of features.
- Automated testing will become required, because the combinatorial
effect of putting all the features into the same template makes it
infeasible to test by hand.
As long as we have some automated tests that tests each combination of
features in the master template (somehow), my distaste for conditionals
goes away. If we don't have any automated tests (or only partial
automated testing), I'd be -0 on a conditionalized template vs. a mess
of single-purpose ones, because even though it's awkward, it's possible
to manually make sure that you didn't break anything in a single-purpose
template by making a change.
> BTW, how would you make a template that handles both SQLAlchemy and
> ZODB? Pylons puts the model definitions and init_model() in
> '.__init__', and the Session and Base in 'meta' so they can be
> imported into everything without circular imports. but where would
> ZODB go? Or does it not really need a model but just a short
> initialization function?
Don't know. It's definitely more than a couple ifs.
> > We could also have just a bare bone Pyramid app with no template
> > engine an no sqla/zodb. Such a setup could be for a webservice app
> > that only returns JSON data, no HTML.
>
> That sounds like a job for pylons_minimal. You'd still have the
> distinction of URL dispatch vs traversal. This seems to be the most
> fundamental choice people make when they choose an application style.
> (Well, that and ZCML.)
>
> --
> 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.
