Jacob Kaplan-Moss wrote: > One altertative to your proposal that Adrian and I tossed around at > one point was to alias certain "normal" modules into a set of > "tasks." That way writing a view would become::
This would certainly be a vast improvement from an end-user's perspective and it would mean that the screencasts wouldn't have to skip over that bit ;) Actually I think there are at least two separate problems here: 1) Too much boilerplate (end-user problem) 2) Too hard to navigate Django code base (advanced user and new developer problem) I agree that there is no One True Way to structure a package so that it seems intuitive to everyone. The namespace churn I put forward was really just to stimulate discussion about how the current structure might be improved. As I said, I think that the main problem is the second tier, which does little to clarify purpose. (extract from subconscious mind: "httpwrappers"...that sounds pretty "core"..."mail"...i know this one - that's definitely a utility...) Those who have commented so far are all pretty intimate with the existing code base so for you lot problem 2 may not exist. The benefits would be mostly to new and dementing folk. Django has the luxury of having control over the namespace of the entire component set, but this cannot yet be considered a feature. +1 on the tasks idea being a quick fix for problem 1 - though this creates a new problem: What are the basic requirements for any view? Do you have a list in mind? Kieran
