On Sunday, March 31, 2013 9:46:59 AM UTC-7, Serge G. Spaolonzi wrote: > > > On Sat, Mar 30, 2013 at 7:20 PM, Victor Hooi <[email protected]<javascript:> > > wrote: > >> >> From the existing projects, we can draw two clear requirements that >> people want: >> >> - Changing the look and feel - I'm not sure what Django core's >> feelings on it, but there seems to be a feeling from the community that >> the >> look of the current Django Admin is somewhat dated? Also, any new admin >> should probably be responsive, and work on mobile or non-desktop devices, >> if that's possible. >> >> Personally I dont see the default design a problem because it can be > customized with external CSS, although the design shipped with django can > be changed, I support the idea of having the admin templates clean, > non-coupled to the design and javascript independent. > > I think the HTML in the templates should be coded independently from the > design, there are some structural mistakes more important than the design, > I have sent a ticket related to this here: Ticket #18511 ( > https://github.com/django/django/pull/180) > > >> - More customisations - a lot of people want to create dashboards >> around the admin, add new sections/tabs, or move things around - the >> current Admin doesn't have much scope for that, or it's not easily >> accessible. >> >> I would like to see a RESTful api to the admin methods and bigger > separation between the views and the templates, in a way that the admin > could be operated from anywhere (android for example). > Currently the admin app is website interface to CRUD operations, I think > the admin app could be improved and turned into a CRUD engine independent > of the presentation that exposes a interface that could be implemented or > extended from any presentation form (android, html, rest calls). >
A RESTful api with a separate template client is exactly what hyperadmin aims to do: https://github.com/zbyte64/django-hyperadmin I've played around with bolting on an emberjs client or having an admin powered by django templates and both options can and do work. It pretty much works as you describe, a CRUD engine operates independently of the presentation layer but for this to work reasonably links themselves must be communicated so that filtering, sorting, etc can easily be represented by a variety of clients. If you don't like the client you can choose or build another one without having to re-implement the admin operations and logic. The focus on HATEOAS also allows for No-SQL storages ( https://github.com/zbyte64/django-hyperadmin-dockitresource) to be used by the same clients because the functionality emitted by the document store is described as links. If you want more functionality exposed then it is a matter of getting your resource to emit the proper links. > Regards > > -- > Serge G. Spaolonzi > Cobalys Systems > http://www.cobalys.com > -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
