Re: Kickstarter for Django Admin?
It looks good, Thanks for sharing. On Wed, Apr 3, 2013 at 8:41 PM, Jason Kraus wrote: > > 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. > -- 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 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Kickstarter for Django Admin?
On Sat, Mar 30, 2013 at 7:20 PM, Victor Hooi 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). 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 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Question about DecimalFields and admin widgets.
Hi,
I wonder why does't the DecimalFields implement an Admin Widget like the
other Fields?.
I am working in a application based in the Admin site and I am in trouble
trying to add some style to the decimal fields because they are rendered
like a plain input text field with no class associated. For the other
fields I have no problem because the have a class associated based in the
widget the implement.
django/contrib/admin/options.py
-
models.DateField: {'widget': widgets.AdminDateWidget},
models.TimeField: {'widget': widgets.AdminTimeWidget},
models.TextField: {'widget': widgets.AdminTextareaWidget},
models.URLField:{'widget': widgets.AdminURLFieldWidget},
models.IntegerField:{'widget': widgets.AdminIntegerFieldWidget},
models.BigIntegerField: {'widget': widgets.AdminBigIntegerFieldWidget},
models.CharField: {'widget': widgets.AdminTextInputWidget},
models.ImageField: {'widget': widgets.AdminFileWidget},
models.FileField: {'widget': widgets.AdminFileWidget},
-
Thanks
Serge
--
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.
Re: (Model)Forms localize=True violates DRY
I have opened a ticked for this same issue, it was rejected because the core team didn't liked the idea of including FormField options in ModelField. Decision i think was correct, I wasnt aware the other FormFields options in ModelFields like help_text were there for historical reasons. https://github.com/cobalys/django/blob/ticket_18471/django/db/models/fields/__init__.py If this is not the correct way to do it, we need to find another way to do it respecting the DRY principle. imao the ModelFields must localize according to settings.USE_L10N, then if it is specified in the option localize as false that field must not localize. >From the official Django Documentation: USE_L10N Default: False A boolean that specifies if localized formatting of data will be enabled by default or not. If this is set to True, e.g. Django will display numbers and dates using the format of the current locale. As I understand USE_L10N sets the default behavior application wise for the localization. Regards Serge G. Spaolonzi On Fri, Jun 22, 2012 at 9:16 AM, Karen Tracey wrote: > On Fri, Jun 22, 2012 at 7:23 AM, Klaas van Schelven < > klaasvanschel...@gmail.com> wrote: > >> I've created a ticket, but have always understood that calling >> attention to tickets should be done separately on the Django- >> developers mailinglist > > > It's not necessary nor encouraged to call attention to newly-opened > tickets on the -developers list. People are asked to post to the list in > preference to "contesting" a resolution the don't agree with (e.g. > wontfix). Newly-opened tickets on the other hand don't need to be announced > on the list, plenty of people monitor the flow of incoming tickets. > > Karen > > -- > 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. > -- 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.
Ticket #18471: Add a localization field option in Model Fields.
Hi, I have opened the ticket #18471<https://code.djangoproject.com/ticket/18471> to request the inclusion of a new option for localization to the Model Fields. Currently the localization of the Model Fields is a complex process that involves the utilization of ModelForms, it can be simplified to the inclusion of a single parameter. I have a branch in Github with this function implemented: https://github.com/cobalys/django/tree/ticket_18471 The only modified file is: django/django/db/models/fields/__init__.py I would like to know what are the next steps to request the inclusion of my code. Should I post a pull request from Github? Thanks -- Serge G. Spaolonzi Cobalys Systems - Web Development | Django | jQuery se...@cobalys.com · +(598) 96492712 · http://www.cobalys.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/o-k9mfPY2sEJ. 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.
