On Tue, Dec 29, 2009 at 2:28 PM, James PIC <[email protected]> wrote: > Hello everybody, > > After reading the thread about the sprint, I'm quiet perplex regarding > the objectives and strategies of Pinax. It looks against common sense > to me so i lack proper understanding. Thanks for considering my > questions. > > I don't understand why rigid, not reusable views functions are even > committed in the Pinax source. > > Why are views functions accepted in Pinax when they don't accept > arguments like extra_context, template_name, base_queryset .... ? (I > asked on IRC and the reply was: "i didn't see the use case when i > coded the view" ....)
I think there's a balance between reusability and DRY here. Having to specify a truckload of parameters for all view functions is tedious, and leads to a lot of boilerplate code. On the other hand, we have the goal of reusability, which requires better interfaces. I'm not saying that we've hit the balance perfectly, but neither do I think that there's reason to require that all view functions should accept a predefined set of parameters. So if there's a use case for more parameters, let's get them in :) > I don't understand why Pinax doesn't delegate the most tedious and > repetitive tasks. > > How will the Pinax team maintain forks of all the apps out there? For > example, do you really want to convert all templates of all apps and > maintain that in the Pinax tree? > > Why not convince the upstream application developers to directly > respect integration standards? I don't think there's a single coherent set of standards we can use for everything. In some areas we have convensions, but there's no gold standard of how to construct your views, name your templates, mark up your content, etc. Some prefer HTML4, some XHTML and some may even be doing HTML5 already, and the same goes for other areas. > I've forked tons of apps to be natively usable in my Pinax projects > with much success, so i don't understand why apps must be copied into > Pinax, it just looks like unnecessary work. > > Why not encourage respect of standards at the upstream application > development level? You make it sound a bit like we're not doing that already… Much of the work that goes on in Pinax goes upstream. Jannis Leidel has probably forked and improved half the Django apps on Github :) There's still room for improvement, but working with upstream is not always easy (or even possible), so sometimes we'll have to pull a fast one to make ends meet. That's okay, if you ask me :) > There are many "copies" of apps done in djangocon to integrate and > maintain, and apparently the workload is poorly distributed. > > Isn't one of the Pinax objectives to result in many more apps to be > natively reusable? If so, what's the plan? Copy apps in the Pinax tree > and maintain all the apps of the world? > > Why not change strategy for better workload distribution? > > Thanks, > > Regards, > > James > > -- > http://jamespic.com/contact > -- 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.
