We would modify our base admin template when we merge it. There are a
number of third party applications which provide modified versions of their
admin pages (FeinCMS is a good example of a moderately complex one). They
would normally support two versions of Django (maybe also an LTS now), and
so would need to provide one code base which works with both. So the
shipping of and old one doesn't make third party app developers headache
any worse.

We will need to release the old one as a third party app, or ship both for
a deprecation period because of users own admin style changes and overrides
they may have made.

I'm not sure the best approach for swapping between the two, even if they
are shipped separately. Perhaps the easiest option is to ship both
versions, add an AdminSite.theme parameter set to the new one. The main
issue I can see with this would be two lots of static files collected every
time (annoying for S3 users), but this is liveable with.

On 7 April 2015 at 16:52, elky <[email protected]> wrote:

> On Tuesday, 7 April 2015 20:23:28 UTC+5, Collin Anderson wrote:
>>
>> There's a ticket about icons here: https://code.djangoproject.
>> com/ticket/20597
>>
>
> Thanks Collin.
>
>
> On Tuesday, 7 April 2015 20:25:57 UTC+5, Marc Tamlyn wrote:
>>
>> The primary questions to establish answers to before a possible merge in
>> my opinion are:
>> - Do we ship both, or just the new one and release the old one as a third
>> party package?
>>
>
> If we release old one as a third-party app we need to support it as well.
> And it is additional headache for the third-party apps developers.
>
>
>> - How could we identify the difference for third party app developers who
>> integrate with both versions, at least across the 1.8/1.9 release cycle?
>> The easy answer here would be to add a new body class, potentially to both
>> versions.
>>
>
> How we can add this class? Someone suggested a setting to enable new
> theme. Ideally Django needs something like CSS framework because as far as
> I can see most of apps just uses their own styles and markup.
>
>
>> My suggestion would be that we should publicise via this mailing list
>> (and django-users etc) that we are planning to integrate this, and you can
>> use it now via your app. This should hopefully get you more bug reports
>> early and we can merge it in a more finished state for the 1.9 alpha.
>>
>
> That would be great.
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To post to this group, send email to [email protected].
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/0a3c2428-fe8e-48de-9b25-c658446548a5%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/0a3c2428-fe8e-48de-9b25-c658446548a5%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1FDmk%3DXZsTiJ5hxJ3utjXW_HCyDu1TKoSRnzwPsv2E13g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to