SURVEY/ANN: grappelli as standalone-app?
patrickk
as some of you might have noticed, there are problems with grappelli
used with the current django svn-checkout. this is due to some heavy
changes going on with the django admin-interface. up to now, grappelli
is developed against the latest official django-release ... sometimes
though, the official release is not what you want (because you might
need some stuff only available with the svn-version).
because of the time intervals between official django-releases and the
heavy development going on with the svn-version we thought about
making grappelli a standalone-app.
what does that mean?
# all python-files available within django.contrib.admin are also
available with grappelli.
# grappelli should be more stable (with either the lates official
release and the svn-version of django).
# it might be possible to run the original admin-interface alongside
grappelli (although we still have to figure out how to deal with
templatetags if both apps are installed).
the drawbacks:
# you need to change django.contrib.admin to grappelli.admin within
your admin-definitions.
# not every functionality implemented with the original admin-
interface will automatically be available with grappelli (since we
have to track these changes and there will be a time-delay).
NOW, THE QUESTIONS:
1. what do you think about making grappelli a standalone-app? pros/
cons?
2. how should we change the structure/layout of grappelli?
notes about question nr. 2:
# we could add a folder "admin" with all the original admin-files. we
´d then change these files a bit. you´d need to add "grappelli.admin"
to your installed-apps. second, we could add a folder "extensions"
with all grappelli-related stuff (bookmarks, navigation, ...). you´d
need to add "grappelli.extensions" to your installed-apps as well.
# we could stuff everything into grappelli as is. this might be a bit
confusing, but you only need to add grappelli to your installed-apps.
# any other suggestions are very much appreciated ...
regards,
patrick
h3
should be a standalone app..
I don't see changing django.contrib.admin to grappelli.admin as a
drawback but rather as a welcomed flexibility.
The ability to run both in parallel would be great I think. I also
think it would permit us to make it really easy
to install, the current state of the installation process isn't really
great.
The only real drawback in my opinion is to cut the dowmstream flow of
patches, bug fixes and new features from django.
On the flipside, it can be limiting to base ourselves on the django
admin while trying to keep things well sorted and stable
between two projects that are quite big and increasingly different.
So we basically have to decide if forking the django admin to create a
standalone grappelli outweight the work of making
them work hands in hands.
I don't have the answer now .. but we have to find it before we can
find out the best way to do it.
As a personnal comment, I think that for 2.1 we should stick to what
we know and release a 2.5 or even a 3.0 version later if
we decide to change the whole thing.
cheers
patrickk
On 1 Feb., 18:22, h3 <hainea...@gmail.com> wrote:
> I think that from a development AND end developper point of view it
> should be a standalone app..
>
> I don't see changing django.contrib.admin to grappelli.admin as a
> drawback but rather as a welcomed flexibility.
> The ability to run both in parallel would be great I think. I also
> think it would permit us to make it really easy
> to install, the current state of the installation process isn't really
> great.
installation won´t change much ... the biggest problem for most users
is copying the media-directory. one still needs to do that.
>
> The only real drawback in my opinion is to cut the dowmstream flow of
> patches, bug fixes and new features from django.
yep, that is a problem.
another advantage: we can change the python-files a bit, e.g. removing
unnecessary javascipts (instead of using grappellis middleware).
>
> On the flipside, it can be limiting to base ourselves on the django
> admin while trying to keep things well sorted and stable
> between two projects that are quite big and increasingly different.
>
> So we basically have to decide if forking the django admin to create a
> standalone grappelli outweight the work of making
> them work hands in hands.
>
> I don't have the answer now .. but we have to find it before we can
> find out the best way to do it.
>
> As a personnal comment, I think that for 2.1 we should stick to what
> we know and release a 2.5 or even a 3.0 version later if
> we decide to change the whole thing.
absolutely. I just had to make some changes to my personal checkout of
grappelli because we need a very recent django svn-checkout for one of
our projects.
so I thought I post this early in order to get as much feedback as
possible.
cheers,
patrick
patrickk
about the admin index page?
thanks for your comment,
patrick
On 2 Feb., 23:12, timg <grave...@gmail.com> wrote:
> From my point of view I would love a standalone app. This way when
> things change in the django admin it does not effect the grappelli
> version and vice versa. I have been using the grappelli version for
> quite a while and have just gone back to the django version for
> basically one app that does not behave with the current version of
> tabular data. I think the ability to group items and hide others is a
> great benefit that I pass along to users of my sites. So it would be
> nice to develop towards on admin instead of trying to straddle the
> two. Hope that helps.
Jannis Leidel
Sorry for the late reply, another discussion on django-developers (1)
reminded me again of doing that.
On Feb 1, 11:09 am, patrickk <sehmasch...@gmail.com> wrote:
> as some of you might have noticed, there are problems with grappelli
> used with the current django svn-checkout. this is due to some heavy
> changes going on with the django admin-interface. up to now, grappelli
> is developed against the latest official django-release ... sometimes
> though, the official release is not what you want (because you might
> need some stuff only available with the svn-version).
Being the one responsible for the changes upstream I'd like to mention
how much I like Grappelli and its unique style. It's always been very
much refreshing to use it when the default skin showed its age. Given
the fact that I always wanted to make the admin more versatile (e.g.
my django-mobileadmin, 2) I'd welcome any ways to override the default
-- even though we've been working on making it easier in 1.2.X, e.g.
overriding templates.
> because of the time intervals between official django-releases and the
> heavy development going on with the svn-version we thought about
> making grappelli a standalone-app.
I believe the answer to that question is about setting conventions and
introducing API which could be used from projects like Grappelli.
> what does that mean?
> # all python-files available within django.contrib.admin are also
> available with grappelli.
> # grappelli should be more stable (with either the lates official
> release and the svn-version of django).
> # it might be possible to run the original admin-interface alongside
> grappelli (although we still have to figure out how to deal with
> templatetags if both apps are installed).
>
> the drawbacks:
> # you need to change django.contrib.admin to grappelli.admin within
> your admin-definitions.
> # not every functionality implemented with the original admin-
> interface will automatically be available with grappelli (since we
> have to track these changes and there will be a time-delay).
>
> NOW, THE QUESTIONS:
> 1. what do you think about making grappelli a standalone-app? pros/
> cons?
> 2. how should we change the structure/layout of grappelli?
Personally, I'd like to reach out to you to pin down the problems that
prevent you from creating an alternative skin easily. We've just been
introducing a few jQuery based widgets in 1.2.X and hope to continue
this progress in the next version, too. It's only natural to me to see
what the community is looking for, and what might have been missed
when we were calling for feature proposals (something which will begin
shortly after the release of 1.2 again). In other words, I think the
work on the admin UI has only just begun and I love to have you guys
on board.
> notes about question nr. 2:
> # we could add a folder "admin" with all the original admin-files. we
> ´d then change these files a bit. you´d need to add "grappelli.admin"
> to your installed-apps. second, we could add a folder "extensions"
> with all grappelli-related stuff (bookmarks, navigation, ...). you´d
> need to add "grappelli.extensions" to your installed-apps as well.
> # we could stuff everything into grappelli as is. this might be a bit
> confusing, but you only need to add grappelli to your installed-apps.
> # any other suggestions are very much appreciated ...
The addition of the admin actions (somewhat a descendant of the django-
batchadmin app) is one feature which is a good example of how we could
add new or revise existing features. With your help, I think there is
no reason why we shouldn't investigate how Django could profit from
the Grappelli project. For example one item that comes to my mind that
needs seriously some love is the admin index page.
Cheers,
Jannis
1: http://groups.google.com/group/django-developers/browse_thread/thread/ca4f26d616921753
2: http://code.google.com/p/django-mobileadmin/
patrickk
On 6 Feb., 12:51, Jannis Leidel <jan...@leidel.info> wrote:
> Hi Patrick,
>
> Sorry for the late reply, another discussion on django-developers (1)
> reminded me again of doing that.
>
> On Feb 1, 11:09 am, patrickk <sehmasch...@gmail.com> wrote:
>
> > as some of you might have noticed, there are problems with grappelli
> > used with the current django svn-checkout. this is due to some heavy
> > changes going on with the django admin-interface. up to now, grappelli
> > is developed against the latest official django-release ... sometimes
> > though, the official release is not what you want (because you might
> > need some stuff only available with the svn-version).
>
> Being the one responsible for the changes upstream I'd like to mention
> how much I like Grappelli and its unique style. It's always been very
> much refreshing to use it when the default skin showed its age. Given
> the fact that I always wanted to make the admin more versatile (e.g.
> my django-mobileadmin, 2) I'd welcome any ways to override the default
> -- even though we've been working on making it easier in 1.2.X, e.g.
> overriding templates.
that´s good news. our primary goal with grappelli was to release a
"skin". first we thought modifying the CSS would do, but in the
meantime we´ve completely refactored the HTML as well (which is
something we wanted to prevent initially).
It´s good to see that the original admin-interface evolves. however,
with adding new js-functionality, the html/css needs to be adaptes as
well. and that´s something I´m missing ... currently, the HTML/CSS is
quite a mess (no offense).
(note: therefore we´ve built an admin-html/css-framework with the next
version of grappelli. by then, modifying and extending the admin-
interface should be much easier since all html-blocks and styles have
a certain structure).
>
> > because of the time intervals between official django-releases and the
> > heavy development going on with the svn-version we thought about
> > making grappelli a standalone-app.
>
> I believe the answer to that question is about setting conventions and
> introducing API which could be used from projects like Grappelli.
absolutely. and from my point of view the original admin-interface
introduces nice new feature-sets. I just have repeat myself: new
feature-sets are nice, but on top of the given html/css they´re almost
worthless (IMHO).
any (official) invitation is more than welcome (not sure if that is
one).
one more note about grappelli: our intention is not that 2 different
interfaces with almost the same functionality co-exist. we didn´t
start grappelli because we´re bored but because it´s almost impossible
to sell the current admin-interface to customers (at least with our
customers - this might be different in other countries).
in the end, it´d be nice to have different admin-skins by just
changing the CSS (and some images, of course).
>
> > notes about question nr. 2:
> > # we could add a folder "admin" with all the original admin-files. we
> > ´d then change these files a bit. you´d need to add "grappelli.admin"
> > to your installed-apps. second, we could add a folder "extensions"
> > with all grappelli-related stuff (bookmarks, navigation, ...). you´d
> > need to add "grappelli.extensions" to your installed-apps as well.
> > # we could stuff everything into grappelli as is. this might be a bit
> > confusing, but you only need to add grappelli to your installed-apps.
> > # any other suggestions are very much appreciated ...
>
> The addition of the admin actions (somewhat a descendant of the django-
> batchadmin app) is one feature which is a good example of how we could
> add new or revise existing features. With your help, I think there is
> no reason why we shouldn't investigate how Django could profit from
> the Grappelli project. For example one item that comes to my mind that
> needs seriously some love is the admin index page.
yes, the admin index page is definitely something to look at. the
current grappelli-solution in order to modify that page is not very
good though.
regards,
patrick
>
> Cheers,
> Jannis
>
> 1:http://groups.google.com/group/django-developers/browse_thread/thread...
> 2:http://code.google.com/p/django-mobileadmin/
Maxime Haineault
prevent you from creating an alternative skin easily.
in Django that makes it hard to customize (the right way at least).
But the short answer is:
When a element contains hard coded JavaScript, that's a killer. I have to disengage this JavaScript
while initializing mine. For example:
<a href="/../somewhere/" onclick="return someDjango.call">Hello</a>
Now before binding a click event to it I need to remove the attribute "onclick" (and simply unbinding does not do the trick).
Solution: you already use it ... unobstrusive JavaScript with jQuery..
Another dead end is when you serve back something like this at a request:
<script type="text/javascript">someDjango.someMethod();</script>
It forces me to keep "someDjango" object containing "someMethod" in my code or else .. well I think you can see the point.
The last wall I hit was the Javascript files, after refactoring *all* the JavaScript with cleaner (and shorter) jQuery code I realized
I couldn't remove their associated <script /> tags since they were hardcoded in Django's core. So I had to resort to a middleware
that strips those scripts tags from the output .. that's *really* hugly.
Solution: .. json ??
That's all I can recall on top of my head right now and I must leave for a meeting, but if I can remember other road blocks I'll post
them here.
Regards
--
Maxime Haineault
Consultant Web / Associé
∞ Motion Média
http://motion-m.ca
m...@motion-m.ca
(450) 374-4822
jsmullyan
like to cheer a hearty "+1" for the idea of the grappelli and core
django admin teams working more closely together and setting some
joint goals, such as:
1. Adjusting Django 1.2 admin so that grappelli can at least produce a
skin for it without resorting to insanely heroic measures or a fork;
2. Moving some appropriate subset of grappelli into Django for 1.3.
Jacob Smullyan
> 1:http://groups.google.com/group/django-developers/browse_thread/thread...
> 2:http://code.google.com/p/django-mobileadmin/
patrickk
it initially should have been: A SKIN! (or even better: not needed at
all)
regards,
patrick
Eric Holscher
A discussion about this came up over on django-dev[0] about this, and
I wrote a blog post[1] about it summing up my feelings. I would love
to know what you all think, and would love to have you all chime in on
the threads in Django dev as well.
The work you all have done is amazing, and I would love to see some of
that effort make it back into Django itself.
Thanks for taking the time to release all this code and make the
django world a better place.
[0] http://groups.google.com/group/django-developers/browse_thread/thread/18bca037f10769e9
[1] http://ericholscher.com/blog/2010/feb/6/role-designers-django-community/
Cheers,
Eric
patrickk
thanks for joining the discussion.
I´ve already posted my thoughts to the dev-list. IMO, the whole
discussion over there is a bit ... strange. for about two or three
years, almost every bug (posted to the django issue tracker) about
design or UI was considered as wontfix, invalid or not needed for some
reason. designers have been treated as not wanted for a long time
(except for wilson, jeff, nathan and some others who are almost seen
as impeccable). don´t get me wrong here. It´s not that I´m frustrated
(although I have been for quite a while), it´s that (most of the time)
I just don´t care anymore. that said, if someone asks me for my
opinion (like jannis did), I´m going to tell.
I really hope that the discussion on the dev-list leads to something
good and useful. for now, I´m actually not sure about that. from my
point of view, it´s a bit beside the point. talking about re-thinking
the whole UI for django 2.0 is not a bad idea at all, it just doesn´t
help with the current situation.
that said, there´s been quite some posts yesterday and we have to see
where the discussion (on the dev-list) goes. at least there might be
some clarification on whether or not grappelli should be a standalone-
app. the answer to this question might very well be a result of that
dicsussion.
(another quick not about grappelli: most of the time, grappelli is
being evalutated by the look and feel - which is important, of course.
more important though - from our point of view - is the refactoring of
html/css and js we´ve done and which will be released with the next
two version-steps of grappelli.)
regards,
patrick
On 6 Feb., 23:11, Eric Holscher <eric.holsc...@gmail.com> wrote:
> Hey all,
>
> A discussion about this came up over on django-dev[0] about this, and
> I wrote a blog post[1] about it summing up my feelings. I would love
> to know what you all think, and would love to have you all chime in on
> the threads in Django dev as well.
>
> The work you all have done is amazing, and I would love to see some of
> that effort make it back into Django itself.
>
> Thanks for taking the time to release all this code and make the
> django world a better place.
>
> [0]http://groups.google.com/group/django-developers/browse_thread/thread...
patrickk
about a "design czar":
http://groups.google.com/group/django-developers/browse_thread/thread/18bca037f10769e9
patrickk
the new thread on the dev-list seems much more constructive and
positive than the last one.
just wanted to mention that, so ... let´s hope the best.
On 7 Feb., 12:31, patrickk <sehmasch...@gmail.com> wrote:
> just for the records, there´s now another discussion on the dev-list
> about a "design czar":http://groups.google.com/group/django-developers/browse_thread/thread...
Eric Holscher
On Feb 7, 5:57 am, patrickk <sehmasch...@gmail.com> wrote:
> I have to put into perspective my second last comment:
> the new thread on the dev-list seems much more constructive and
> positive than the last one.
>
> just wanted to mention that, so ... let´s hope the best.
>
Agreed. I think that new thread is taking a good route.
There are really a couple of issues. There is the overarching theme of
design issues not being handled/fixed. As you said, design tickets
being wontfixed. I think that having the design czar type person there
would fix those issues. However, that is a more meta issue, with a
longer term impact.
The more interesting is the whole issue with the actual admin, and
what can be done now. I think the discussion is really good, and has
needed to happen. I am curious what exactly we can get in motion
currently, hopefully within the 1.2 time frame, to make your all's
jobs easier.
I know that you have refactored the HTML/CSS, and that is probably too
big of a change to get into 1.2. However, if there are concrete,
backwards compatible, improvements to the way that the admin handles
things (I know hard coded strings, inline styles/javascript have been
mentioned), then I think these may be able to be seen as bug fixes,
and go into 1.2.
I don't want to make any promises, or get any hopes up. However, the
fact that you don't care anymore is a serious problem. It sucks that
people have gotten to that point. You all are doing great work, and
some of that should go back into Django, and everyone should benefit.
So hopefully this discussion will lead to some fruitful
collaboration.
Thanks again for your input and all the work you all are doing. I'm
actually setting up grappelli on my server today to test it out. :)
Cheers,
Eric
patrickk
for me (personally), the fact that my enthusiasm has suffered is not a
big deal.
maybe the core-devs should be more cautious when replying to design-
related proposals/threads/tickets.
>
> So hopefully this discussion will lead to some fruitful
> collaboration.
>
> Thanks again for your input and all the work you all are doing. I'm
> actually setting up grappelli on my server today to test it out. :)
probably not the best time doing this. my advise is to use the latest
stable django-release with a grappelli svn-checkout. there are some
smaller glitches, but overall we use that combination for almost every
customer right now.
that said, the new stuff (js-refactoring, html/css-refactoring) is not
available with the current version of grappelli.
regards,
patrick
>
> Cheers,
> Eric
patrickk
grappelli a standalone-app.
what do we have (in terms of code/design):
– we´re having an html/css-framework for the admin. we´ve been working
on that one for quite a while and we´re pleased with the outcome. that
said, we still think the changelist can be improved.
– we´re having all javascripts using jquery (thanks to maxime).
what do we have (in terms of competences/people):
– axel and myself are implementing html/css changes. we´re also
thinking about the basic structure of the admin-app and it´s visual
design.
– maxime is responsible for the js-stuff. and I think other people
have already offered their support in this area.
so, what do we need:
– basically, we´re lacking a python-guru who´s dealing with the admins
python-/django-files. in order to make grappelli a standalone-app, we
need to include all python-files and changing them a bit (e.g.,
removing hardcoded stuff as a first step).
question (to the grappelli-community) now is: is there someone willing
to help with the python-files? this should be a person with lots of
python-/django-experience and the enthusiasm to improve grappelli.
please note: at this point, the question is hypothetical, since we
still have to wait for the outcome of the discussions on the django
dev-list (that said, I´m a bit sceptical we´re sharing the same
vision). however, it´s good to know whether or not we´re able to make
grappelli a standalone-app in the first place. if we don´t have the
capabilities, we don´t need to further discuss this topic.
regards,
patrick
Jannis Leidel
Non taken, I can only speak for the changes I personally made which tried to be as backwards compatible as possible to prevent breakage of already existing custom admin templates in the wild. Part of that was also result of Zain Memon's Summer of Code project last year.
> (note: therefore we´ve built an admin-html/css-framework with the next
> version of grappelli. by then, modifying and extending the admin-
> interface should be much easier since all html-blocks and styles have
> a certain structure).
The current admin html/css predates the rise of the grid frameworks, afaik. So it's only natural (to me) to have a look at that anyway.
>>> because of the time intervals between official django-releases and the
>>> heavy development going on with the svn-version we thought about
>>> making grappelli a standalone-app.
>>
>> I believe the answer to that question is about setting conventions and
>> introducing API which could be used from projects like Grappelli.
>
> absolutely. and from my point of view the original admin-interface
> introduces nice new feature-sets. I just have repeat myself: new
> feature-sets are nice, but on top of the given html/css they´re almost
> worthless (IMHO).
Exactly, and we can justify modifying existing APIs (HTML, CSS) much better when we add features.
I can't speak for the Django project itself but invite you as a core developer to share your findings with us, as tickets, bugfixes et al.
> one more note about grappelli: our intention is not that 2 different
> interfaces with almost the same functionality co-exist. we didn´t
> start grappelli because we´re bored but because it´s almost impossible
> to sell the current admin-interface to customers (at least with our
> customers - this might be different in other countries).
> in the end, it´d be nice to have different admin-skins by just
> changing the CSS (and some images, of course).
Great, we are on the same page here. I believe we are able to move some of the innovation that has happened in Grappelli upstream.
Jannis
Jannis Leidel
> On behalf of all heavily addicted Grappelli users like myself, I'd
> like to cheer a hearty "+1" for the idea of the grappelli and core
> django admin teams working more closely together and setting some
> joint goals, such as:
>
> 1. Adjusting Django 1.2 admin so that grappelli can at least produce a
> skin for it without resorting to insanely heroic measures or a fork;
> 2. Moving some appropriate subset of grappelli into Django for 1.3.
I fear that won't be as easily justifiable since we just released the 1.2 beta and are in bugfix only mode now. So there are probably only slight ajdustments possible to be made before the release. However, the 1.3 release cycle gives us the opportunity to do much more.
Jannis
patrickk
IMHO, it´s currently too complicated to add new features because of
the given HTML/CSS.
In the past, I´ve seen lots of customized admin-pages for different
reasons. they all fail in terms of design.
like this one?
http://code.djangoproject.com/ticket/11700
don´t get me wrong, but it doesn´t work that way. writing tickets
takes time and if some core-dev says that ticket is "invalid" (because
there´s no patch/code or he just doesn´t understand the ticket), I´m
thinking twice before submitting the next one.
we´ve already invested quite some work with grappelli and the issues
with the original admin-interface are more than obvious (from our
point ov view). I´m willing to summarize the most annoying issues
(actually, I´ve already done that), but I´m not able to improve
grappelli AND write bugfixes for the original admin-interface as well.
another problem with tickets:
how can I meaningful post a ticket like this "html/css needs to be
refactored"? that´s way to broad in scope.
if it comes down to super-minor changes, the current ticket-system
might be useful. when talking about design-decisions or bigger
changes, I´m not sure working that way really helps.
>
> > one more note about grappelli: our intention is not that 2 different
> > interfaces with almost the same functionality co-exist. we didn´t
> > start grappelli because we´re bored but because it´s almost impossible
> > to sell the current admin-interface to customers (at least with our
> > customers - this might be different in other countries).
> > in the end, it´d be nice to have different admin-skins by just
> > changing the CSS (and some images, of course).
>
> Great, we are on the same page here. I believe we are able to move some of the innovation that has happened in Grappelli upstream.
that´d be awesome.
regards,
patrick
>
> Jannis
Jannis Leidel
Actually, that's a good example for when discussion is needed, because it includes a design decission. Russell correctly closed the ticket and pointed to the developer list for further discussion, he didn't mean to insult you or the problem mentioned in the ticket.
> we´ve already invested quite some work with grappelli and the issues
> with the original admin-interface are more than obvious (from our
> point ov view). I´m willing to summarize the most annoying issues
> (actually, I´ve already done that), but I´m not able to improve
> grappelli AND write bugfixes for the original admin-interface as well.
To clarify, it's absolutely necessary to get specific details about problems you encountered to be able to fix them. I'm not asking you personally to write all tickets or even solve them. The ticket system is where we collect the details about bugs to be able to fix them.
> another problem with tickets:
> how can I meaningful post a ticket like this "html/css needs to be
> refactored"? that´s way to broad in scope.
> if it comes down to super-minor changes, the current ticket-system
> might be useful. when talking about design-decisions or bigger
> changes, I´m not sure working that way really helps.
Right, "html/css needs to be refactored" is too broad for a ticket, but would be an awesome title for a feature proposal for 1.3. Tickets are very good to chop the general goal into working goals.
Jannis
Danny Adair
I think you know and have given the answer to grappelli's way forward
already, in the original post.
> the drawbacks:
> # you need to change django.contrib.admin to grappelli.admin within
> your admin-definitions.
The least of anyone's problems.
> # not every functionality implemented with the original admin-
> interface will automatically be available with grappelli (since we
> have to track these changes and there will be a time-delay).
That's what I've been focussing on in this discussion.
The original admin interface has been a slow mover (not to forget the
js library-agnosticism aka corporal mortification) and I chose to use
grappelli because in a number of respects it's been _ahead_ of things.
I'm not really worried about the original admin interface having a
feature more for a few days.
The drawback of _not_ making grappelli an application is what we're
currently experiencing, and lacking Django _core_ features due to in
incompatible interface in the trunk keeping me from updating hurts way
more. Plus I believe it's what's keeping a lot of people from adopting
grappelli:
From http://www.theotherblog.com/Articles/2009/06/02/extending-the-django-admin-interface/
"All of the Django Admin application is hackable, but I am loathe to
hack it willy-nilly because I like to be able to swap in a later
version of Django and know that it’ll just work without having to
remember a whole heap of tweaks I’ve made to Django Admin files. For
this reason, I’m uncomfortable with the gorgeous Django Grappelli
project, which adds a shade more visual pzazz to the Django Admin
screens because it requires me to alter files in the Django Admin
application"
Hear, hear.
My conclusion:
+1 for app
Kia ora,
Danny
patrickk
On Feb 8, 11:11 am, Danny Adair <danny.ad...@unfold.co.nz> wrote:
> Hello Patrick,
>
> I think you know and have given the answer to grappelli's way forward
> already, in the original post.
>
> > the drawbacks:
> > # you need to change django.contrib.admin to grappelli.admin within
> > your admin-definitions.
>
> The least of anyone's problems.
>
> > # not every functionality implemented with the original admin-
> > interface will automatically be available with grappelli (since we
> > have to track these changes and there will be a time-delay).
>
> That's what I've been focussing on in this discussion.
> The original admin interface has been a slow mover (not to forget the
> js library-agnosticism aka corporal mortification) and I chose to use
> grappelli because in a number of respects it's been _ahead_ of things.
> I'm not really worried about the original admin interface having a
> feature more for a few days.
>
> The drawback of _not_ making grappelli an application is what we're
> currently experiencing, and lacking Django _core_ features due to in
> incompatible interface in the trunk keeping me from updating hurts way
> more. Plus I believe it's what's keeping a lot of people from adopting
> grappelli:
>
> Fromhttp://www.theotherblog.com/Articles/2009/06/02/extending-the-django-...
fetzig!
to keep thinkgs short: grappelli stand alone - Great!
django.admin is more a burden than a nice base to build on.
want to help as python/django (soon to become ;) "guru". but wouldn't
mind an additional helping hand there.
greets,
klemens
Tom von Schwerdtner
On Feb 1, 5:09 am, patrickk <sehmasch...@gmail.com> wrote:
>
> the drawbacks:
> # you need to change django.contrib.admin to grappelli.admin within
> your admin-definitions.
I dont' really see that as a problem, all things considered.
> # not every functionality implemented with the original admin-
> interface will automatically be available with grappelli (since we
> have to track these changes and there will be a time-delay).
I think Grappelli is far ahead of contrib.admin at this point, so I
wouldn't worry too much about that.
-Tom
jsmullyan
On Feb 8, 3:45 am, Jannis Leidel <jan...@leidel.info> wrote:
> Am 06.02.2010 um 16:50 schrieb jsmullyan:
>
> > On behalf of all heavily addicted Grappelli users like myself, I'd
> > like to cheer a hearty "+1" for the idea of the grappelli and core
> > django admin teams working more closely together and setting some
> > joint goals, such as:
>
> > 1. Adjusting Django 1.2 admin so that grappelli can at least produce a
> > skin for it without resorting to insanely heroic measures or a fork;
> > 2. Moving some appropriate subset of grappelli into Django for 1.3.
>
> I fear that won't be as easily justifiable since we just released the 1.2 beta and are in bugfix only mode now. So there are probably only slight ajdustments possible to be made before the release. However, the 1.3 release cycle gives us the opportunity to do much more.
If during that cycle, some of the changes can be merged to the 1.2.X
branch, that in itself would be very helpful if it would mean that
grappelli could be used with some post-release flavor of 1.2, as
opposed to waiting for 1.3.
yml
+1 for grappelli as a standalone app
One side effect of this could be to have a management command that
automatically serve grappelli's admin files. This command could come
in addition or replace the existing runserver. This would
significantly reduce reduce the installation/development process and
it would reduce the breakage with trunk my isolating it from django's
admin.
regards,
--yml
Maxime Haineault
> This command could come in addition or replace the existing runserver.
> This would significantly reduce reduce the installation/development process and it would reduce the breakage with trunk my isolating it from django's admin.
This is a bit confusing..
--
Maxime Haineault
Consultant Web / Associé
∞ Motion Média
http://motion-m.ca
m...@motion-m.ca
(450) 374-4822
Tom von Schwerdtner
wrote:
> > One side effect of this could be to have a management command
> that automatically serve grappelli's admin files.
>
> I'm sorry I really don't get you point .. or what you are talking
> about..
>
I think he just wants an easy way to setup admin media without having
to manually copy the files/folders.
Yann Malet
patrickk
copy the media-files to another place? that´s easy with cp -R. do we
really need a management-command for that?
use the media-files within grappelli with the django dev-server? you
only need runserver --adminmedia ... for doing that.
like maxime, I don´t get the point as well. sorry.
regards,
patrick
On 10 Feb., 16:29, Yann Malet <yann.ma...@gmail.com> wrote:
> If you create a django app that mean that you can add your own custom
> command management. Let imagine that you have add a custom command called
> "grappelli" to your application you could make sure that this command just
> does the right thing.
>
> regards,
> --yml
>
> On Wed, Feb 10, 2010 at 11:23 AM, Maxime Haineault <hainea...@gmail.com>wrote:
>
> > > One side effect of this could be to have a management command that
> > automatically serve grappelli's admin files.
>
> > I'm sorry I really don't get you point .. or what you are talking about..
>
> > > This command could come in addition or replace the existing runserver.
>
> > Hum .. What ?
>
> > > This would significantly reduce reduce the installation/development
> > process and it would reduce the breakage with trunk my isolating it from
> > django's admin.
>
> > But how ? The management command isn't part of the admin at all.. what it
> > has to do with it ??
>
> > This is a bit confusing..
>
> > --
>
> > Maxime Haineault
> > Consultant Web / Associé
>
> > ∞ Motion Média
> > http://motion-m.ca
> > m...@motion-m.ca
> > (450) 374-4822
>
> > 2010/2/9 yml <yann.ma...@gmail.com>
Yann Malet
patrickk
´s pretty easy.
in production use, you need to copy the media-files anyway.
regards,
patrick
On 10 Feb., 16:32, Yann Malet <yann.ma...@gmail.com> wrote:
> This would give a user experience / behavior similar to the one that we have
> when you use django.admin with runserver. Where the admin media are
> automatically served.
>
> Regards,
> --yml
>
> On Wed, Feb 10, 2010 at 11:27 AM, Tom von Schwerdtner <tomv...@gmail.com>wrote:
>
> > On Feb 10, 2010, at 10:23 AM, Maxime Haineault <hainea...@gmail.com>
Klemens Mantzos
#!/bin/bash
python manage.py runserver --adminmedia=grappelli/media/
--
klemens mantzos
http://fetzig.at/
Yann Malet
Maxime Haineault
--
Maxime Haineault
Consultant Web / Associé
∞ Motion Média
http://motion-m.ca
m...@motion-m.ca
(450) 374-4822
Yann Malet
Yann Malet
patrickk
understand the benefits. that being said, I do understand your last
point (about grappelli being a standalone app, serving the media-files
automatically).
regards,
patrick
On 10 Feb., 16:59, Yann Malet <yann.ma...@gmail.com> wrote:
> last message from me on this. I am not telling this is something hard or
> difficult I am just saying that django.admin does do this automatically for
> you and if the objective of grappelli is to be a drop in replacement it
> could emulate this developer friendly behavior.
>
> Thanks for grappelli anyway even without this command it brings some
> significant improvement. :-)
>
> Regards,
> --yml
>
Yann Malet
Klemens Mantzos
(without arguments) will do the trick in grappelli standalone.
--
klemens mantzos
http://fetzig.at/
Jannis Leidel
> +1 for grappelli as a standalone app
>
> One side effect of this could be to have a management command that
> automatically serve grappelli's admin files. This command could come
> in addition or replace the existing runserver. This would
> significantly reduce reduce the installation/development process and
> it would reduce the breakage with trunk my isolating it from django's
> admin.
>
<shameless plug>
I believe it would be wise to use apps that deal with collecting (and serving) static files of apps, e.g. http://pypi.python.org/pypi/django-staticfiles/.
</shameless plug>
ashwoods
"default" way of skinning,
but wouldn't a deliverance/xdv approach be interesting? in my opinion
its lifts the burden from the designer
and separates function from form very nicely. just a thought.
I'll see how fast implementing a grapelli-delivarance version takes.
cheers,
ashley