GSOC: Turn contrib.admin into a customizable management interface

[tyrion-mx]

Discussing on #django-dev with FunkyBob and others I concluded that 
refactoring contrib.admin to become a generic management interface (and not 
a model-centric one as it is now) could be a good thing, so I started a 
project proposal.
It still a draft and I hope to complete it in time, anyway I would like to 
know as much as possible what others think about it :)

Here is the link: https://gist.github.com/tyrion/537ab187f458ba1ae9e9

I have still not mentioned that I also plan to rewrite contrib.admin using 
class based views.

Thanks

-- 
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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
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/d1f2e18f-aa56-4f9b-9b79-681de6972ca1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSOC: Turn contrib.admin into a customizable management interface

[tyrion-mx]

On Tuesday, March 24, 2015 at 11:48:59 PM UTC+1, Curtis Maloney wrote:
>
> Let's not get bogged down in minutiae just yet :)
>

> How to implement a grid and what level of browser support is something 
> that can be threshed out in the process.
>
I agree 

I love the idea of a Dashboard with custom Widgets.
>
> Allowing the existing "App list" widgets, along with new custom non-model 
> widgets will open Admin a lot.
>
> This idea is so good, grappelli have had it for years :p
>
Infact I am now trying to look and understand the documentation and code of 
grappelli and also of django-xadmin ( 
https://github.com/sshwsfc/django-xadmin ).
I don't know yet how these projects implemented a dashboard, so I am going 
to study them a little. Anyway if you want to suggest a good architecture 
to implement this, please do it. 
 

> Does this also, then, imply the need for sub-dashboards, as Admin has 
> currently per-app?  Or would we use our new-found flexibility to, for 
> instance, accordion-out "folders" of widgets?
>
  I am not sure I understand what you mean here. If you are talking about 
the possibility to have a custom dashboard for every app in the app index 
page (i.e. /admin/$app), it is ok for me. The only constraints now are the 
little time remained to write the proposal and the time available to do the 
GSOC.

However I think that app dashboards and widgets groups could be left out 
initially and added later if we want them.
 

> And I may as well suggest allowing widgets to hint at their size [e.g. 
>  1x1, 2x1, 1x2, etc..]
>
  Yes my idea was to put these information in the html like this, probably:



where widget.size and order could come from the database or the user's 
session for example.
The only problem here is that we would have to decide what 1x1, 2x1 etc 
means (i.e. do we want a grid or do we want to leave the developers of 
widgets to define their own css)
I am not too expert with css, so it is not super-clear to me what would be 
the best way to handle this. 

-- 
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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
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/5a76eccd-650b-48a3-b3e4-a5cc520f521e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: rethinking raw_id_fields

[tyrion-mx]

I've tried implementing Autocomplete for the admin using jQuery (new)
Autocomplete,
here's the code: http://bitbucket.org/tyrion/django
and here's a live demo (without css for the autocomplete, so it looks
kinda ugly): http://djangoac.tyrion.mx/admin/ login with test/test.

Let me know what you think about it.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

Using jQuery.noConflict() instead of jQuery.noConflict(true) in contrib.admin

[tyrion-mx]

1) contrib.admin places jQuery in its own namespace `django.jQuery`.
In this way other jQuery instances should not conflict with it.
2) It also removes the dollar sign AND the `jQuery` object from the
global scope.

*I think* removing the `jQuery` object is not necessary because it
*should* not conflict with any other jQuery instance.

If an admin customization that uses jQuery is loaded, as it should,
after the contrib.admin's javascript, its `jQuery` object will
override the django's one, and django will still be able to use jQuery
with `django.jQuery`.

If an admin customization is loaded before the contrib.admin's
javascript, it *should not* work anyway even if we removed jQuery from
the global scope. That's because jQuery.noConflict(true) removes the
jQuery object from the global scope, but doesn't prevent it to be
created and attached to window (thus overwriting the user's one).

Moreover I wont' be able to use any jQuery plugin (that directly
references `jQuery`) in the admin (without hacking with
ModelAdmin._media), because the `jQuery` object does not exist. I am
forced to include jquery twice ...

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

Re: Using jQuery.noConflict() instead of jQuery.noConflict(true) in contrib.admin

[tyrion-mx]

On Oct 22, 10:37 pm, Chuck Harmston  wrote:
> Per the jQuery docs , plugins
> should *not* directly reference the jQuery object; they should do it in a
> scope-controlled closure executed at creation with jQuery passed to it as a
> parameter. This way, plugins can safely use the $ shortcut without worrying
> about whether or not noConflict mode is on, whether it is assigned to a
> separate namespace (like django.jQuery), etc; you simply need to change the
> parameter passed to the closure. In the case of django.jQuery, it should
> look like this:
>
> (function( $ ){
>     $.fn.myPlugin = function() {
>         this.each(function() {
>             this.doSomething();
>         });
>     };
>
> })( django.jQuery );
>

I know this, but that's not the point. I could change "jQuery" to
"django.jQuery" for my own jquery plugins, but then I will be forced
to duplicate the plugin file: one using "django.jQuery" for the admin
and an other using "jQuery" for the rest of the site. And that's not
good ...
In addiction, I don't want to edit jQuery UI, and to make it work
without loading an other instance of jquery I *must* load it before
jquery.init.js (that calls noConflict(true)).

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

Consider allowing customization of ModelForm's init parameters in contrib.admin

[tyrion-mx]

I'd like to be able to customize the parameters that gets passed to the 
form used in all the views of the ModelAdmin. It seems that there is 
currently no way to do it.
A very common scenario in which this could be useful is to provide a 
default value for an author/user field of a model.
For example I have a Post model which has an "author" field, and I must 
provide a default value based on the current user.

I found various ways to accomplish this, but they all seem hacks to me. So 
imho it would be great to have an official, correct way to do this.

I found one answer[1] on stackoverflow which suggests to use "get_object". 
But unfortunately that method does not called by the "add_view".
An other method[2] is to use the "formfield_for_foreignkey" method. And 
finally, reading the code of contrib.admin I came up with other 3 
solutions[3].

What do you think about this? What is your favorite way to solve this 
problem?

[1]: http://stackoverflow.com/a/8487550/641317
[2]: http://kylefuller.co.uk/posts/pre-populating-data-admin-panel/
[3]: http://pastebin.com/GVC1SKeN

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
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/6efef15c-ad42-4933-bad9-a5bcb8755aad%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.