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 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'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?

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.


Reply via email to