Re: Kickstarter for Django Admin?

2013-04-08 Thread Serge G. Spaolonzi
It looks good, Thanks for sharing.

On Wed, Apr 3, 2013 at 8:41 PM, Jason Kraus <zbyt...@gmail.com> 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?

2013-03-31 Thread Serge G. Spaolonzi
On Sat, Mar 30, 2013 at 7:20 PM, Victor Hooi <victorh...@gmail.com> 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.

2012-06-28 Thread Serge G. Spaolonzi
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

2012-06-22 Thread Serge G. Spaolonzi
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 <kmtra...@gmail.com> 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.

2012-06-13 Thread Serge G. Spaolonzi
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.