On Thu, Feb 2, 2012 at 4:17 PM, Alex Gaynor <[email protected]> wrote: > > > On Thu, Feb 2, 2012 at 5:01 PM, Adrian Holovaty <[email protected]> wrote: >> >> On Thu, Feb 2, 2012 at 2:49 PM, Sean Brant <[email protected]> wrote: >> > Is this up somewhere public? I've been fighting the urge to do this as >> > well. Using django-compressor with less on Heroku is a non-starter >> > since you can't install node. Having this as a Python module would be >> > handy. >> >> Not yet, alas, but hopefully soon. >> >> Adrian >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers" 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/django-developers?hl=en. >> > > Perhaps this is too far in the future looking. But at a certain point the > admin must become a separate project. One of the major goals of > newforms-admin ('lo those years ago) was to demote the admin from special > status, with hooks inside core left and right, to "just an app". Let's > carry that to the logical conclusion: just an app *outside of Django*. > > That gives the maintainers the freedom to reinvent it, and use tools like > less or bootstrap without it needing to be an issue of policy for all of > Django. Because when I first read saw this thread my thought was, "Hmm, > what unholy mess of requirements am I going to need if I want to just run > the test suite. Will I still be able to write new features in forms without > needing to learn what the hell less or compass is?". Several years ago, I > opposed using jQuery in the admin, on the principle that Django should be > completely free of entangling alliances. I made that argument more or less > out of habit, just because I felt it was an argument that ought to be made, > but really I was pretty happy to get to use jQuery. Now I'm saying, it's > pretty clear that admin 2.0 (or 3.0, or 4.0, anyone counting?) is going to > be a beast that far outstrips almost anything else in Djanog (besides the > ORM ;)) in complexity, with more dependencies, more associated tooling, and > more usecases (i.e. it's not just a tool for developers to use, it's also > something for end users of *our* users' apps to use). Keeping that in > Django itself is going to stunt it's growth, and it's going to suck for new > developers to Django who, like many of us (or at least myself), were and > still are, Python developers at heart, who can write some HTML, badly. > > Alex > > -- > "I disapprove of what you say, but I will defend to the death your right to > say it." -- Evelyn Beatrice Hall (summarizing Voltaire) > "The people's good is the highest law." -- Cicero > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" 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/django-developers?hl=en.
+1 Given how flexible the admin is doing somethings is still pretty annoying. I feel like if it was a external project with its own release schedule more progress could be made. FWIW i'm experimenting with an admin interface that relies heavily on class based views. So far I like it. CBVs seem to have more useful hooks then the admin currently has. At the very least I think the new admin needs to not be backwards compatible with the current admin. So my vote is for django-admin2 as an external project. -- You received this message because you are subscribed to the Google Groups "Django developers" 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/django-developers?hl=en.
