I give +1 to the idea of separating out the admin and letting people fork and 
modify to their hearts content

I also still give my +1 to having it utilize less, but I am also cautious like 
others about prescribing bootstrap specifically , especially the JS since as 
others have pointed out is somewhat unstable right now and not very easy to use 
at times (took me a long time to figure out modals)

Sent from my iPhone

On Feb 3, 2012, at 1:25 AM, Harris Lapiroff <[email protected]> wrote:

> The Django admin is a major—if not *the* major—selling point to
> budding developers. I worry that externalizing it (hence making it a
> *separate* piece of software that needs to be discovered and
> installed, which seems simple but can be quite a challenge to new
> coders) might take away Django's non-expert appeal. When I started
> using Django, I knew no python. The only reason I was able to make
> that work was because of the Django admin. If the admin gets kicked
> out, I think it should be made *very* obvious where to find one.
> 
> I'd be wary of putting them in core but I think using Bootstrap and
> Less for a new admin (whether internal or external) would make its
> development much faster. Dependencies should not be a problem. I think
> jQuery is a pretty apt analogy here. You probably won't write much
> javascript for the Django admin without learning jQuery. You can if
> you want to. But most people don't need or want to write javascript
> for the Django admin anyway. I think a framework like Bootstrap it
> would actually simplify adding new features. It provides so many CSS
> classes that there's a pretty good chance your feature wouldn't
> require you to write even a line of CSS. I was able to convert an
> unstyled app that I've been working on to functionally using Bootstrap
> in just about an hour after starting to learn it.
> 
> That having been said, I'd still be cautious with Bootstrap. It is a
> young piece of software that is incredibly impressive and mind-
> bogglingly easy to use, but obviously still in flux.
> 
> On Feb 2, 5:38 pm, Sean Brant <[email protected]> wrote:
>> 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.
> 

-- 
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.

Reply via email to