a less compiler is needed to make developers add custom variables to
match color scheme they like.

i prefeer using an existing framework, a lot of work less to do, no
docs to make, just a link.
bootstrap it's fantastic, it's well done and is flexible.

django should use a base style, already compiled for backward
compatibility.

i would make a theme framework, something like django.contrib.themes,
a css/js/less framework to customize every view and the admin.

imagine a subclass of django.forms.Media

class MediaMiddleware(object):

    def process_exception(self, request, e):
        request.media = GlobalMedia()

user can add css doing

>>> request.media.add_css(

django admin could do this to add media it gets from admin forms doing

request.media += self.media + adminForm.media

and then push media in context


we could create a GlobalMediaContextProcessor, it import an instance
of global_media and put it in every template with a namespace of
"global_media".

def base(request):

    return {
        'media':request.media,
    }

and than in template use

{{ media.css }}

now, with this kind of hook, user can choose, site wide, what media
use.
with a context_processor, a media class is injected in every template,
and views can add js and css on the fly, pushing them over
request.media

with some less rule, admin template could be reskinned, and user can
select a different type of themes

THEME_CLASS = "django.contrib.themes.DefaultTheme"

then wu could add a "django.contrib.themes.Bootstrap"

a globalmedia class that host less definition for a bootstrap theme.

with an app like this users could choose if continue to use default
theme or switch to a bootstrap template, to develop faster a front-end
interface.

no backward compatibility issues, just one more possibility for
developers.


what views can do is to
On 3 Feb, 20:07, Ryan D Hiebert <vgac...@gmail.com> wrote:
> I think that Django's admin app is a killer feature for two main reasons:
> 1. It is automatically installed, and integrated into the tutorial.
> 2. It is used all over in third-party apps, because they can expect it to be 
> there.
>
> While I appreciate that there may be differences in core vs admin that may 
> slow down development of the admin, I'm wary of removing it from the django 
> install, thinking that it might hurt reason 2, even if it is integrated in 
> the tuturial, and possibly even installed automatically.
>
> Although as far as the automatic install goes, I'm not sure how that would 
> work. Would it be a dependency? That doesn't make sense.
>
> On Feb 3, 2012, at 6:21 AM, Max Thayer wrote:
>
>
>
>
>
>
>
> > The point about admin's appeal to new people is important, but 
> > externalizing it and keeping new people from ever seeing it are very 
> > different. Consider: admin isn't even enabled by default. You have to 
> > follow the tutorial on how to enable it. If admin weren't included in 
> > Django proper, we could just change the tutorial to "Apps are awesome; 
> > here's how to download and install one written by someone else." New users 
> > could meet pip sooner, and otherwise understand how to integrate with the 
> > broader python/django community's various creations.
>
> > Actually, a friend of mine and I have been plotting out externalizing 
> > various parts of contrib, like admin and auth. Are any groups currently 
> > pursuing those goals as well?
>
> > Best regards,
> > Max
>
> > On Fri, Feb 3, 2012 at 8:35 AM, Brendan Smith 
> > <bren...@nationalpriorities.org> wrote:
> > 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 <harrislapir...@gmail.com> 
> > 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 <brant.s...@gmail.com> wrote:
> > >> On Thu, Feb 2, 2012 at 4:17 PM, Alex Gaynor <alex.gay...@gmail.com> 
> > >> wrote:
>
> > >>> On Thu, Feb 2, 2012 at 5:01 PM, Adrian Holovaty <adr...@holovaty.com> 
> > >>> wrote:
>
> > >>>> On Thu, Feb 2, 2012 at 2:49 PM, Sean Brant <brant.s...@gmail.com> 
> > >>>> 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 
> > >>>> django-developers@googlegroups.com.
> > >>>> To unsubscribe from this group, send email to
> > >>>> django-developers+unsubscr...@googlegroups.com.
> > >>>> 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 django-developers@googlegroups.com.
> > >>> To unsubscribe from this group, send email to
> > >>> django-developers+unsubscr...@googlegroups.com.
> > >>> 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 django-developers@googlegroups.com.
> > > To unsubscribe from this group, send email to 
> > > django-developers+unsubscr...@googlegroups.com.
> > > For more options, visit this group 
> > > athttp://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 django-developers@googlegroups.com.
> > To unsubscribe from this group, send email to 
> > django-developers+unsubscr...@googlegroups.com.
> > For more options, visit this group 
> > athttp://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 django-developers@googlegroups.com.
> > To unsubscribe from this group, send email to 
> > django-developers+unsubscr...@googlegroups.com.
> > For more options, visit this group 
> > athttp://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 django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Reply via email to