On Tue, Dec 29, 2009 at 2:28 PM, James PIC <[email protected]> wrote: > > I don't understand why rigid, not reusable views functions are even > committed in the Pinax source.
This isn't the only reason but bear in mind we're not even at 1.0 yet. The way Pinax works now shouldn't be assumed to be the way we want Pinax to work evenutally. We're all just a bunch of volunteers and Pinax has had to "invent" a lot of techniques. There has been a lot of experimentation and we haven't necessarily worked everything out yet. > 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" ....) Extensibility and abstraction can sometimes really hurt usability and learnability. The approach in Pinax is often to see what people want and abstract from the common elements and not abstract prematurely. > I've forked tons of apps to be natively usable in my Pinax project > with much success, so i don't understand why apps must be copied into > Pinax, it just looks like unnecessary work. Whose apps have your forks to make them usable in Pinax? Have you contributed back patches? Have they been incorporated in the original apps? Not sure what you mean by "copied into Pinax". We often *start* developing an app inside Pinax because it is easier to prototype apps that way. But *if* the app makes sense to be used outside Pinax (which many do) we eventually move it out. Or do you mean the Pinax *account* on GitHub? If so, what apps are you talking about? > There are many "copies" of apps done in djangocon to integrate and > maintain, and apparently the workload is poorly distributed. 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. > Isn't one of the Pinax objectives to result in many more apps to be > natively reusable? The primary goal is to provide a platform that enables websites to be developed more quickly and with less repetition. In many cases, that involves making apps that are more reusable. But note that I think it's highly misleading to talk about apps being "reusable" or "not-reusable". It's not a binary property apps have. An app may have hard-coded URLs, forms and template names and still be incredibly reusable across a wide variety of sites. An app may have highly abstracted views and be a glowing example of a "reusable app" and be a complete pain to get to work with other apps in Pinax. Pinax has always been about making certain compromises, trading flexibility for rapid development. I'm not interested in creating a cathedral of clever abstractions, extensibility and design patterns. I want people to be able to built their websites faster. Bottom line, though, is that we're still at an early stage and we're still learning how best to make it faster for people to develop their websites with Pinax. Note: it is not a goal of Pinax to make it easier to develop websites *without* Pinax. > If so, what's the plan? Copy apps in the Pinax tree and maintain all the apps > of the world? I'm still not sure what's giving you the impression that we are doing this or plan to do it. > Why not change strategy for better workload distribution? I still don't see any suggestions other than make views more abstract and parameterized but I don't see that solving the issue. James -- 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.
