On Jan 1, 2010, at 10:33 AM, James PIC wrote: > First of all: thanks for your quality replies. > > You're talking a lot about faster website initial development, a goal > elegantly reached by Pinax. > > My concern is more about *faster website maintenance and upgrades*. > I've (finally) found a work around by changing my business model, so > it doesn't really matter much to me anymore.
Could you elaborate a bit more on the concerns you have with *faster website maintenance and upgrades*? We'd like to help if at all possible. If there is something we are doing that isn't exactly helpful or something we are doing entirely we'd like to hear it. > > Thanks for explaining to me more complex reasons for committing: > > def myview(request): > template_name = '...' > return render_to_response(template_name...) > > Instead of what i believe is "just better" in *any* case: > > def myview(request, template_name = '...'): > return render_to_response(template_name...) > > Of course, we can live peacefully with this disagreement (as i said > I've found a work around). I don't think there is as much disagreement as you might think. Apps in Pinax were all developed at varying points of extensibility and some have only added the extra options you mention. If we have any views that don't take some of the basic overrides there is no reason not to report it as bug. > >> Whose apps have your forks to make them usable in Pinax? Have you >> contributed back patches? Have they been incorporated in the original apps? > > There are unresolved technical issues with that: there is currently no > template architecture that allow an app to be usable both with and > without Pinax. > > So patches are not integrated upstream. > >> Not sure what you mean by "copied into Pinax". >> > > I mean that the patches are integrated in the Pinax tree because they > are rejected upstream. They are rejected upstream because they break > compatibility with non-Pinax projects. I really don't think this is the case. I am of the opinion that apps should *never* bundle templates. If it were an app I am in control of I'd reject *any* template. There are some very isolated cases where templates in an app are acceptable. Templates are your integration point and should be project level. Pinax provides a set of *default* templates that help with getting started. Most of the sites I work on that need custom looks end up getting its own overrides of default templates. I wouldn't expect templates to be a good contribution to an app. If you have improvements for our default templates we'd love to hear about it. > >> Note: it is not a goal of Pinax to make it easier to develop websites >> *without* Pinax. > >> Yes, the core devs have not had as much time as they've needed to integrate >> contributions. I'm not sure what you are suggesting that would help that. >> > > I'm not suggesting anything that would help *that* precisely. > > Why not allow the upstream app developers to make their app directly > usable directly both with and without Pinax? The core devs could then > concentrate on other issues. > > I know this might complicate app development a little, but wouldn't > that optimize workload distribution? I generally don't like the notion that apps have to care about Pinax. You are really putting a huge burden on app developers that are not in touch with the Pinax development process. In most cases we have to push app developers to fix minor bugs or take the issue into our hands. While this generally works out the workload always falls in the hands of the Pinax contributors. Brian Rosner http://oebfare.com http://twitter.com/brosner -- You received this message because you are subscribed to the Google Groups "Pinax Core Development" 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/pinax-core-dev?hl=en.
