proposal: decouple admin index page from INSTALLED_APPS
hi everyone, I just wanted to outline a basic idea in order to improve (at least from my point of view) the index-page of the admin-interface. I don´t have any code to share (so far), so I´m basically explaining my idea - if people agree that this is useful, I´m trying to submit a patch. here´s the idea: currently, the admin index page is strictly coupled to the settings-file of my project (the INSTALLED_APPS). to me, that doesn´t seem the best way. a while ago, the admin-definition for apps has been coupled to the model-definition ... now there is a file called admin.py, which is much better IMHO. so why don´t we have a file admin.py for every project? within that file, one could define which apps (from INSTALLED_APPS) should be visible at the admin index page. moreover, the possibility to reorder/rearrange the way these apps are shown would be great. e.g, when I´m using djangos auth-app and I´m extending the user-model with a user-profile, I´m having "auth" (with users and groups) and "user" (with user profile) on my admin index page. orderd by names, auth is very much on the top of my page while user is at the bottom. for an editor, this is probably hard to understand (because the editor doesn´t know anything about apps). for an editor, it´d more comfortable having a headline "user management" with the apps "users", "groups" and "user profiles". this re-arrangement could be defined in admin.py. I hope this is somehow understandable. it´s a bit hard to explain in a foreign language ... it´d be great to hear other opinions. thanks, patrick --~--~-~--~~~---~--~~ 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: proposal: decouple admin index page from INSTALLED_APPS
thanks for the reply. On 4 Sep., 13:02, Luke Plant wrote: > On Friday 04 September 2009 10:00:37 patrickk wrote: > > > e.g, when I´m using djangos auth-app and I´m extending the user-model > > with a user-profile, I´m having "auth" (with users and groups) and > > "user" (with user profile) on my admin index page. orderd by names, > > auth is very much on the top of my page while user is at the bottom. > > for an editor, this is probably hard to understand (because the editor > > doesn´t know anything about apps). for an editor, it´d more > > comfortable having a headline "user management" with the apps "users", > > "groups" and "user profiles". this re-arrangement could be defined in > > admin.py. > > You can also define the arrangement by overriding the admin template for the > index and hard coding in your own order. It's not ideal, but it's perhaps > preferable to adding another place for configuring the admin. If you want > this kind of flexibility for the index page, you might also want to add extra > notes etc onto the page, which makes customising the template a reasonably > good way to do it. yep. I know that that´s possible, but it leads to another problem: the app-index is missing. because (referring to my initial example) "user management" is not an app and therefore it´s not clickable. of course I could make "user management" a link and define custom templates for every section of my index-page. with my proposal, "user management" would be a section containing different apps. and either "user management" as well as every app within this section should be clickable. moreover, hardcoding the index-template doesn´t seem very clean from my point of view. > Having an admin.py for every project is a bit vague, because 'projects' don't > really exist as far as Django is concerned, only 'apps'. I´m not exactly sure, but I don´t think that´s a huge problem, right? maybe I used the wrong terms, but it can´t make a big difference whether the settings-file is used for the admin or another file is used. however, I could be mistaken. - a bit of background information: while using djangos admin-interface for about 3 years now, customers always complain about not finding stuff on the admin index page. for a bigger website with about 50 apps you get a really long list. and I just thought it would be easier if apps are combined within sections (again, don´t nail me down on the terms ...). thanks, patrick > > Luke > > -- > I teleported home one night > With Ron and Sid and Meg, > Ron stole Meggie's heart away > And I got Sidney's leg > (THHGTTG) > > Luke Plant ||http://lukeplant.me.uk/ --~--~-~--~~~---~--~~ 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: proposal: decouple admin index page from INSTALLED_APPS
fair enough.
I don´t have a problem with just seperating INSTALLED_APPS from
ADMIN_APPS within the settings-file. I just thought another admin-file
is nicer (but that´s not the key argument of my proposal).
INSTALLED_APPS = (
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.sites',
'django.contrib.admin',
'movies',
'stars',
'cinemas',
'games',
'promos',
'polls',
'festivals',
'trailer',
'user',
'registration',
'voting',
'django.contrib.comments',
'custom_tags',
'mediadata',
'stats',
'newsletter',
)
ADMIN_APPS = (
(_('User Management'), {
'apps': ('django.contrib.auth', 'registration', 'user',)
}),
(_('Main Content'), {
'apps': ('movies', 'stars', 'cinemas', 'festivals',
'trailer',)
}),
(_('Games'), {
'apps': ('games', 'promos', 'polls',)
}),
(_('Voting/Comments'), {
'classes': ('collapsed',),
'apps': ('voting', 'comments',)
}),
(_('Extras'), {
'classes': ('collapsed',),
'apps': ('mediadata', 'stats', 'newsletter',)
}),
)
if you need more details, please let me know.
thanks,
patrick
On 4 Sep., 14:23, Russell Keith-Magee wrote:
> On Fri, Sep 4, 2009 at 7:19 PM, patrickk wrote:
>
> > thanks for the reply.
>
> > On 4 Sep., 13:02, Luke Plant wrote:
> >> On Friday 04 September 2009 10:00:37 patrickk wrote:
>
> >> > e.g, when I´m using djangos auth-app and I´m extending the user-model
> >> > with a user-profile, I´m having "auth" (with users and groups) and
> >> > "user" (with user profile) on my admin index page. orderd by names,
> >> > auth is very much on the top of my page while user is at the bottom.
> >> > for an editor, this is probably hard to understand (because the editor
> >> > doesn´t know anything about apps). for an editor, it´d more
> >> > comfortable having a headline "user management" with the apps "users",
> >> > "groups" and "user profiles". this re-arrangement could be defined in
> >> > admin.py.
>
> >> You can also define the arrangement by overriding the admin template for
> >> the
> >> index and hard coding in your own order. It's not ideal, but it's perhaps
> >> preferable to adding another place for configuring the admin. If you want
> >> this kind of flexibility for the index page, you might also want to add
> >> extra
> >> notes etc onto the page, which makes customising the template a reasonably
> >> good way to do it.
>
> > yep. I know that that´s possible, but it leads to another problem: the
> > app-index is missing. because (referring to my initial example) "user
> > management" is not an app and therefore it´s not clickable. of course
> > I could make "user management" a link and define custom templates for
> > every section of my index-page.
> > with my proposal, "user management" would be a section containing
> > different apps. and either "user management" as well as every app
> > within this section should be clickable.
>
> > moreover, hardcoding the index-template doesn´t seem very clean from
> > my point of view.
>
> >> Having an admin.py for every project is a bit vague, because 'projects'
> >> don't
> >> really exist as far as Django is concerned, only 'apps'.
>
> > I´m not exactly sure, but I don´t think that´s a huge problem, right?
> > maybe I used the wrong terms, but it can´t make a big difference
> > whether the settings-file is used for the admin or another file is
> > used. however, I could be mistaken.
>
> It depends :-)
>
> It is a slight problem in that we currently require no project-level
> code. Everything besides settings and the top-level URLconf is stored
> in an application. The admin app is "just another app" - there's
> nothing specifically "project level" about it. All the current admin
> registrations, for instance, occur with app-level admin.py files, and
> you can get very creative about those
Re: proposal: decouple admin index page from INSTALLED_APPS
On 4 Sep., 15:30, Russell Keith-Magee wrote:
> On Fri, Sep 4, 2009 at 8:37 PM, patrickk wrote:
>
> > fair enough.
>
> > I don´t have a problem with just seperating INSTALLED_APPS from
> > ADMIN_APPS within the settings-file. I just thought another admin-file
> > is nicer (but that´s not the key argument of my proposal).
>
> > INSTALLED_APPS = (
> > 'django.contrib.auth',
> > 'django.contrib.contenttypes',
> > 'django.contrib.sessions',
> > 'django.contrib.sites',
> > 'django.contrib.admin',
> > 'movies',
> > 'stars',
> > 'cinemas',
> > 'games',
> > 'promos',
> > 'polls',
> > 'festivals',
> > 'trailer',
> > 'user',
> > 'registration',
> > 'voting',
> > 'django.contrib.comments',
> > 'custom_tags',
> > 'mediadata',
> > 'stats',
> > 'newsletter',
> > )
>
> > ADMIN_APPS = (
> > (_('User Management'), {
> > 'apps': ('django.contrib.auth', 'registration', 'user',)
> > }),
> > (_('Main Content'), {
> > 'apps': ('movies', 'stars', 'cinemas', 'festivals',
> > 'trailer',)
> > }),
> > (_('Games'), {
> > 'apps': ('games', 'promos', 'polls',)
> > }),
> > (_('Voting/Comments'), {
> > 'classes': ('collapsed',),
> > 'apps': ('voting', 'comments',)
> > }),
> > (_('Extras'), {
> > 'classes': ('collapsed',),
> > 'apps': ('mediadata', 'stats', 'newsletter',)
> > }),
> > )
>
> > if you need more details, please let me know.
>
> Well, for starters, some clarification would help.
>
> Are we talking about an alternate organization for models in the admin
> so you're not bound to app-based categories, or are we talking about
> some higher level organization?
>
> Your example puts django.contrib.auth into the 'User Management'
> collection - is that indicating that all the apps in auth should be
> shown in "User Management", or that there is a "User Management"
> super-group that contains the auth group that contains the auth
> applications?
I´d personally replace the group "Auth" with the group "User
Management".
the reason is that "Auth" is an application (something which is - IMHO
- irrelevant for an editor to know/see).
that said, I can also think of putting the group "Auth" within the
super-group "User Management". however, I don´t think that´s necessary
and makes the admin index page more complicated.
> Your language is particularly confusing in this regard - it isn't
> clear when you say 'apps' if you actually mean 'models'.
sorry. trying to concentrate on the right terms a bit more.
> Secondly, why would this be included in settings.py (or a top level
> admin.py for that matter)? Admin registrations are currently
> distributed across the apps in the entire project - why is there a
> need to pull this into a single location?
the only reason I can think of is to change the order of collections
(see below).
> Couldn't this be achieved by registering a model with a particular
> "app collection" (with the default being the collection formed by the
> app containing the model)?
from my point of view this leads to the problem of sorting the "app
collections". how would you achieve that? e.g., if I want "User
Management" to be shown as the first collection (independent of the
collections name)?
moreover, it´d be nice (at least from a theoretical point of view) to
assign an app (or model) to more than one collection.
regards,
patrick
> i.e., to create a "User Management" group, and put "user" in it:
>
> class UserManagement(AdminGroup):
> label = "UserManagement"
>
> class UserAdmin(ModelAdmin):
> ...
> class UserAdmin(ModelAdmin):
> ...
>
> admin.site.register(User, UserAdmin, group=UserManagement)
>
> Yours,
> Russ Magee %-)
--~--~-~--~~~---~--~~
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: proposal: decouple admin index page from INSTALLED_APPS
alright, I´ve been trying to implement the most basic functionality
and here´s what I came up with. Please note that this is just a draft
in order to explain what I´ve been talking about. It works ok, but it
probably can be done better.
thanks,
patrick
– SETTINGS.PY
ADMIN_COLLECTIONS = [
{
'name': 'Main Content',
'classes': 'highlight',
'show_apps': True,
'apps': ['movies', 'stars', 'trailer']
},
{
'name': 'User Management',
'show_apps': False,
'apps': ['auth', 'grappelli']
}
]
– SITES.PY
for collection in ADMIN_COLLECTIONS:
app_list = []
for app in collection['apps']:
app_list.append(app_dict[app])
collection['app_list'] = app_list
context = {
'title': _('Site administration'),
'app_list': app_list,
'collection_list': ADMIN_COLLECTIONS,
'root_path': self.root_path,
}
– INDEX.HTML:
{% for collection in collection_list %}
{%
blocktrans with collection.name as name %}{{ name }}{% endblocktrans %}
{% for app in collection.app_list %}
{% if collection.show_apps %}
{{ app.name }}
{% endif %}
{% for model in app.models %}
{% if model.perms.change %}
{{ model.name }}
{% else %}
{{ model.name }}
{% endif %}
{% if model.perms.add %}
{% trans 'Add' %}
{% else %}
{% endif %}
{% if model.perms.change %}
{% trans 'Change' %}
{% else %}
{% endif %}
{% endfor %}
{% endfor %}
{% endfor %}
On 4 Sep., 15:52, patrickk wrote:
> On 4 Sep., 15:30, Russell Keith-Magee wrote:
>
>
>
> > On Fri, Sep 4, 2009 at 8:37 PM, patrickk wrote:
>
> > > fair enough.
>
> > > I don´t have a problem with just seperating INSTALLED_APPS from
> > > ADMIN_APPS within the settings-file. I just thought another admin-file
> > > is nicer (but that´s not the key argument of my proposal).
>
> > > INSTALLED_APPS = (
> > > 'django.contrib.auth',
> > > 'django.contrib.contenttypes',
> > > 'django.contrib.sessions',
> > > 'django.contrib.sites',
> > > 'django.contrib.admin',
> > > 'movies',
> > > 'stars',
> > > 'cinemas',
> > > 'games',
> > > 'promos',
> > > 'polls',
> > > 'festivals',
> > > 'trailer',
> > > 'user',
> > > 'registration',
> > > 'voting',
> > > 'django.contrib.comments',
> > > 'custom_tags',
> > > 'mediadata',
> > > 'stats',
> > > 'newsletter',
> > > )
>
> > > ADMIN_APPS = (
> > > (_('User Management'), {
> > > 'apps': ('django.contrib.auth', 'registration', 'user',)
> > > }),
> > > (_('Main Content'), {
> > > 'apps': ('movies', 'stars', 'cinemas', 'festivals',
> > > 'trailer',)
> > > }),
> > > (_('Games'), {
> > > 'apps': ('games', 'promos', 'polls',)
> > > }),
> > > (_('Voting/Comments'), {
> > > 'classes': ('collapsed',),
> > > 'apps': ('voting', 'comments',)
> > > }),
> > > (_('Extras'), {
> > > 'classes': ('collapsed',),
> > > 'apps': ('mediadata', 'stats', 'newsletter',)
> > > }),
> > > )
>
> > > if you need more details, please let me know.
>
> > Well, for starters, some clarification would help.
>
> > Are we talking about an alternate organization for models in the
Re: proposal: decouple admin index page from INSTALLED_APPS
On 5 Sep., 06:02, Russell Keith-Magee wrote: > On Sat, Sep 5, 2009 at 3:32 AM, James Bennett wrote: > > > On Fri, Sep 4, 2009 at 2:21 PM, andybak wrote: > >> 1. I think worrying about projects vs. apps is a red-herring. We are > >> talking about a way to configure an admin app. There might be several > >> of these on a 'site/project/whatever' > > > Since this all seems to be specific to particular instances of > > AdminSite, AdminSite would be the logical place to do it if it's going > > to get code-level support. However... > > >> 2. Some ability to regroup and choose better names is a biggie. It > >> pains me when I try and explain to my admins what 'auth' means... > > > Practically everything being requested here is purely presentational. > > And Django has a component for doing presentational logic: the > > template system. The admin templates are deliberately easy to override > > with custom versions, and it feels like all of this is really just > > asking for things that are more cleanly done in templates. > > This isn't completely true - at least, not if you want to affect the > URL structure as well. If you're just looking be able to use: > > /admin// > > and replace that with: > > /admin// > > then you need some form of representation at the code level. This > can't be done purely with templates. > > This distinction is really only important if you want the URL > structure to reflect of logical structure, rather than code structure > (which, broadly speaking, is a good thing to be doing from the "URL as > interface" argument). However, this use case could be handled at > present with a custom site that overrides get_urls to provide the > 'group' landing page, etc. > > I can see that providing a DSL-style way to set up these groups could > be handy for a small group of users, but I can't say it's a > particularly compelling use case for me personally. > > I strongly suspect that this could (and therefore, should) be handled > as an external project in the initial phases - i.e., a > "django-extended-admin' project that provides the AdminSite and > ModelAdmin extensions that would make a DSL-for-groups approach > possible. Patrick, Joshua - if you're enthused about this idea, I > suggest you combine your efforts and try to make this external project > a reality. If this external project gains traction, then we can look > at merging it back to trunk. will do. I´m going to use grappelli (http://code.google.com/p/django- grappelli/) for this. if anybody wants to join (joshua?, andy?), please drop me an email. thanks for all the feedback & suggestions. regards, patrick > > Yours, > Russ Magee %-) --~--~-~--~~~---~--~~ 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: proposal: decouple admin index page from INSTALLED_APPS
my thoughts:
1. defining groups within admin.py of each app makes reordering groups
complicated.
2. to assign an app to a group, I have to register that app with a
group - if I want (for example) to assign django.contrib.auth to the
group "User Management", I have to change that app (which breaks
future svn-updates). this is true for almost every 3rd-party app (if I
´m using an svn-checkout).
instead of using a bottom-up structure (registering apps with groups),
why not using a top-down structure (defining groups and assigning
apps).
e.g., you could have a file admin.py within your project and this file
could define the groups:
class UserManagement(AdminGroup):
label = "User Management"
...
'apps': ('django.contrib.auth', 'user',)
regards,
patrick
On 5 Sep., 20:22, Russ Ryba wrote:
> I'm coming late to the coversation but wanted to add by thoughts on
> the admin index issue. I'm at a campground on a cell phone so
> bandwidth and typing is limited.
>
> I'll try to be specific in my comments.
>
> 1. I think that this should be handled by individual app admin.py. I
> like the idea of just modifying one line in installed_apps to turn an
> application on or off.
>
> 2. I think settings.py should only know about applications. You
> should never specify model sorting or model anything in settings.py.
>
> 3. Admin.py per app should specify grouping and sorting per model.
> First by registering a modrladmin group, then later assigning
> modeladmins to that group.
>
> I would extend the previous example as follows.
>
> class UserManagement(AdminGroup):
> label = "User Management"
> sort_order = 100
> merge_with_existing_group = True
>
> class UserAdmin(ModelAdmin):
> Meta:
> sort_order = 50
> class FooAdmin(ModelAdmin):
> Meta:
> sort_order = 60
>
> admin.site.register(User, UserAdmin, group=UserManagement)
> admin.site.register(Foo, FooAdmin, group=UserManagement)
>
> Then in the index template app groups would be sorted by sort order
> values, then alphanumeric.
>
> - This would keep grouping defined in each app admin class.
> - This would let you sort apps/groups by numerical values.
> - mergewexisting would let apps join together or not, being false by
> default so you could see when name collisions occur with app or group
> names. It could also let complimentary apps extend each other by
> adding new models.
>
> Further thoughts.
>
> - SQL tables are currents based on appname_model, as are the URL
> mappings. Changing the index grouping is essentially the same as
> merging applications.
>
> I love the sound of it if we focus on the index. However I foresee
> the next logical request would be to "fix" the SQL and URL mappings to
> match the index display. That would be practically impossible or very
> ugly.
>
> Name collisions suddenly have to be accounted for, SQL migrations to
> rename tables, as well as permission names.
>
> 4. Thinking about how to implement the URL and SQL mappings leads me
> to suggest a new file App/meta.py. This would contain application
> name override, Application sort order and model grouping would be
> defined here.
>
> The meta class would know about the applications models, and admin
> interfaces and define how to group then all together.
>
> Accessible via something like
>
> Appname.meta.property = value
>
> Since it's define at the app level the SQL and URL processors should
> have access to it.
>
> This could also be a good place to define things I use a lot like
> custom permissions specific to the application per app or per app model.
>
> Maybe I'm getting ahead of myself with URL and SQL stuff?
>
> Comments?
>
> Russ Ryba
--~--~-~--~~~---~--~~
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: proposal: decouple admin index page from INSTALLED_APPS
I´ve opened a ticket with my patches (and a screenshot):
http://code.djangoproject.com/ticket/11895
I´ve given up on changing the app-index page since this seems to break
the overall coherence of the admin-interface. therefore, my patch doesn
´t change the breadcrumbs. it only gives you the ability to group (and
reorder) the apps shown on the index-page of every admin-site.
I´ve not included a patch for index.html ... basically, one has to
loop the group-list first and then the app-list (every app which is
not part of a group is displayed at the bottom of the index-page). if
one doesn´t define a group, all apps are listed as is.
the file admin.py show how the apps can be defined for an admin-site.
thanks,
patrick
On 6 Sep., 11:38, patrickk wrote:
> my thoughts:
> 1. defining groups within admin.py of each app makes reordering groups
> complicated.
> 2. to assign an app to a group, I have to register that app with a
> group - if I want (for example) to assign django.contrib.auth to the
> group "User Management", I have to change that app (which breaks
> future svn-updates). this is true for almost every 3rd-party app (if I
> ´m using an svn-checkout).
>
> instead of using a bottom-up structure (registering apps with groups),
> why not using a top-down structure (defining groups and assigning
> apps).
> e.g., you could have a file admin.py within your project and this file
> could define the groups:
>
> class UserManagement(AdminGroup):
> label = "User Management"
> ...
> 'apps': ('django.contrib.auth', 'user',)
>
> regards,
> patrick
>
> On 5 Sep., 20:22, Russ Ryba wrote:
>
> > I'm coming late to the coversation but wanted to add by thoughts on
> > the admin index issue. I'm at a campground on a cell phone so
> > bandwidth and typing is limited.
>
> > I'll try to be specific in my comments.
>
> > 1. I think that this should be handled by individual app admin.py. I
> > like the idea of just modifying one line in installed_apps to turn an
> > application on or off.
>
> > 2. I think settings.py should only know about applications. You
> > should never specify model sorting or model anything in settings.py.
>
> > 3. Admin.py per app should specify grouping and sorting per model.
> > First by registering a modrladmin group, then later assigning
> > modeladmins to that group.
>
> > I would extend the previous example as follows.
>
> > class UserManagement(AdminGroup):
> > label = "User Management"
> > sort_order = 100
> > merge_with_existing_group = True
>
> > class UserAdmin(ModelAdmin):
> > Meta:
> > sort_order = 50
> > class FooAdmin(ModelAdmin):
> > Meta:
> > sort_order = 60
>
> > admin.site.register(User, UserAdmin, group=UserManagement)
> > admin.site.register(Foo, FooAdmin, group=UserManagement)
>
> > Then in the index template app groups would be sorted by sort order
> > values, then alphanumeric.
>
> > - This would keep grouping defined in each app admin class.
> > - This would let you sort apps/groups by numerical values.
> > - mergewexisting would let apps join together or not, being false by
> > default so you could see when name collisions occur with app or group
> > names. It could also let complimentary apps extend each other by
> > adding new models.
>
> > Further thoughts.
>
> > - SQL tables are currents based on appname_model, as are the URL
> > mappings. Changing the index grouping is essentially the same as
> > merging applications.
>
> > I love the sound of it if we focus on the index. However I foresee
> > the next logical request would be to "fix" the SQL and URL mappings to
> > match the index display. That would be practically impossible or very
> > ugly.
>
> > Name collisions suddenly have to be accounted for, SQL migrations to
> > rename tables, as well as permission names.
>
> > 4. Thinking about how to implement the URL and SQL mappings leads me
> > to suggest a new file App/meta.py. This would contain application
> > name override, Application sort order and model grouping would be
> > defined here.
>
> > The meta class would know about the applications models, and admin
> > interfaces and define how to group then all together.
>
> > Accessible via something like
>
> > Appname.meta.property = value
>
> > Since it's define at the app level the SQL and URL processors should
> > have access to it.
>
> > This could also b
Re: proposal: decouple admin index page from INSTALLED_APPS
just for the records ...
as russell commented on the ticket, this can all be done with
subclassing AdminSite.
so ... here´s how grouping and reordering app with the admin-interface
can be achieved:
http://code.google.com/p/django-grappelli/wiki/customizingindex
and here´s the code (subclassing AdminSite), just in case someone
wants to do something similar without grappelli:
http://code.google.com/p/django-grappelli/source/browse/branches/grappelli_2/sites.py
thanks for all the feedback/help,
patrick
On 17 Sep., 12:55, patrickk wrote:
> I´ve opened a ticket with my patches (and a
> screenshot):http://code.djangoproject.com/ticket/11895
>
> I´ve given up on changing the app-index page since this seems to break
> the overall coherence of the admin-interface. therefore, my patch doesn
> ´t change the breadcrumbs. it only gives you the ability to group (and
> reorder) the apps shown on the index-page of every admin-site.
>
> I´ve not included a patch for index.html ... basically, one has to
> loop the group-list first and then the app-list (every app which is
> not part of a group is displayed at the bottom of the index-page). if
> one doesn´t define a group, all apps are listed as is.
>
> the file admin.py show how the apps can be defined for an admin-site.
>
> thanks,
> patrick
>
> On 6 Sep., 11:38, patrickk wrote:
>
> > my thoughts:
> > 1. defining groups within admin.py of each app makes reordering groups
> > complicated.
> > 2. to assign an app to a group, I have to register that app with a
> > group - if I want (for example) to assign django.contrib.auth to the
> > group "User Management", I have to change that app (which breaks
> > future svn-updates). this is true for almost every 3rd-party app (if I
> > ´m using an svn-checkout).
>
> > instead of using a bottom-up structure (registering apps with groups),
> > why not using a top-down structure (defining groups and assigning
> > apps).
> > e.g., you could have a file admin.py within your project and this file
> > could define the groups:
>
> > class UserManagement(AdminGroup):
> > label = "User Management"
> > ...
> > 'apps': ('django.contrib.auth', 'user',)
>
> > regards,
> > patrick
>
> > On 5 Sep., 20:22, Russ Ryba wrote:
>
> > > I'm coming late to the coversation but wanted to add by thoughts on
> > > the admin index issue. I'm at a campground on a cell phone so
> > > bandwidth and typing is limited.
>
> > > I'll try to be specific in my comments.
>
> > > 1. I think that this should be handled by individual app admin.py. I
> > > like the idea of just modifying one line in installed_apps to turn an
> > > application on or off.
>
> > > 2. I think settings.py should only know about applications. You
> > > should never specify model sorting or model anything in settings.py.
>
> > > 3. Admin.py per app should specify grouping and sorting per model.
> > > First by registering a modrladmin group, then later assigning
> > > modeladmins to that group.
>
> > > I would extend the previous example as follows.
>
> > > class UserManagement(AdminGroup):
> > > label = "User Management"
> > > sort_order = 100
> > > merge_with_existing_group = True
>
> > > class UserAdmin(ModelAdmin):
> > > Meta:
> > > sort_order = 50
> > > class FooAdmin(ModelAdmin):
> > > Meta:
> > > sort_order = 60
>
> > > admin.site.register(User, UserAdmin, group=UserManagement)
> > > admin.site.register(Foo, FooAdmin, group=UserManagement)
>
> > > Then in the index template app groups would be sorted by sort order
> > > values, then alphanumeric.
>
> > > - This would keep grouping defined in each app admin class.
> > > - This would let you sort apps/groups by numerical values.
> > > - mergewexisting would let apps join together or not, being false by
> > > default so you could see when name collisions occur with app or group
> > > names. It could also let complimentary apps extend each other by
> > > adding new models.
>
> > > Further thoughts.
>
> > > - SQL tables are currents based on appname_model, as are the URL
> > > mappings. Changing the index grouping is essentially the same as
> > > merging applications.
>
> > > I love the sound of it if we focus on the index. However I foresee
> > > the next logical request would be to &q
Re: Manage CSS/JS files in admin views.
@jannis: no, it isn´t. I thinkg you are able to _add_ js to your admin views, but you´re not able to _remove_ javascripts. there´s still way too much hardcoded stuff with the admin-interface (IMO). I hope that including jquery with the admin-interface is not a big mistake in the long run. regards, patrick On 29 Jan., 15:53, Jannis Leidel wrote: > Hi Jedie, > > > In my own project i already have jQuery saved in my own media dir and > > i added in my own /admin/base_site.html file. So in some admin views i > > have two jQuery included. > > Isn't Django's media handling capable to help in case you want to use your > own version of a JavaScript file shipped with > Django?http://docs.djangoproject.com/en/dev/ref/contrib/admin/#modeladmin-me... > > Jannis -- 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: Refining Django admin look proposal
jannis (leidel) asked me to join this thread in order to add some
comments.
we´ve been doing grappelli (http://code.google.com/p/django-grappelli/
wiki/screenshots) for a while now. grappelli initially should be a
"skin" for the admin-interface. while working on it, we´ve had issues
skinning the interface and maybe it´s helpful to point out some of the
main problems.
currently (from what I´m seeing) there are new features planned (or
already integrated) with the admin-interface. that´s nice. but (IMHO)
the HTML/CSS needs to be refactored as well. I´m not talking about
colors are fonts, I´m talking about some kind of html-css-framework
for the admin-interface. so, here´s our proposal:
http://vonautomatisch.at/grappelli/ (sorry for the strange navigation)
PLEASE NOTE THAT THIS IS JUST A DRAFT AND SOME THINGS ARE BROKEN. we
´ve already been integrating most of this with the next version of
grappelli (the above site is about 2 months old and there´s already
been some changes). therefore, we´ve stopped developing the above
site ...
the most important change is probably the introduction of an overall
grid, see:
http://www.vonautomatisch.at/grappelli/basic-document-structures/grid-based-on-blueprint/
http://www.vonautomatisch.at/grappelli/forms-in-container-grid/basic-form-elements-in-container-grid/
moreover, we´ve tried to refactor all javascripts with jquery, see:
http://code.google.com/p/django-grappelli/source/browse/#svn/branches/haineault/media/jquery/grappelli/src
(done by maxime haineault)
as already discussed with jannis, what I´d like to see with the admin-
interface is a solid and comprehensible structure as well as coherent
styles. based on this, different "skins" are easily possible.
I don´t wanna be to detailed right now, but there´s too much hardcoded
stuff with the current admin-interface and the admin index page could
benefit from some changes as well.
here´s an (outdated) list of issues:
http://code.google.com/p/django-grappelli/wiki/djangoissues
let me add a note about the "contest": if it comes down to skinning
the admin-interface, a contest is not needed from my point of view. if
(one day), it´s easy to "skin" the admin-interface, different skins
will evolve (e.g., grappelli). I think that it´s important to create
the prerequisites for skinning first.
regards,
patrick
On 6 Feb., 13:18, Luke Plant wrote:
> On Saturday 06 February 2010 09:07:33 j...@jeffcroft.com wrote:
>
> > To expound, it seems like you guys are thinking of a re-skinning.
> > I'm not talking about a re-skinning. I'm talking about a complete
> > re- thinking of the admin interface. By 1.2? Not a chance. By 1.3?
> > Maybe. But I wouldn't count on it. I'm talking about bringing the
> > admin to 2010, just like you all brought the models API current
> > after .96. Seriously, what if the models API hadn't changed in
> > five years? Do you think it would be a small project to bring it
> > current? Of course not. It would be huge. This is a serious
> > undertaking, and the idea of doing a "contest" feels like you
> > think it's a commodity. This is a serious project for serious
> > designers, not a g'damn reality TV show.
>
> The original thread seemed to be about re-skinning at most ('refining
> Django admin look'). The choice about whether it goes in is largely
> down to a matter of taste and aesthetics, which is why our normal
> procedures with tickets and feature voting really wouldn't work - for
> an aesthetics 'bug' you can have multiple 'fixes' which are all
> 'correct'. To avoid pointless debate, a contest seems like a good
> idea. Personally, even a re-skinning brings with it potential design
> problems for existing installations, so I'd have to be convinced the
> re-skinning was a big enough improvement to make up for that - I agree
> with Russell that this definitely isn't something we should be doing
> every few months, or even every year.
>
> If it's a complete re-thinking of the admin interface, it's obviously
> a much bigger undertaking, and brings with it huge implications in
> terms of backwards compatibility. Even if just the templates were to
> be re-worked, we have to consider all the people who have custom admin
> templates that assume the current block layout etc. A bigger re-
> thinking of the admin would involve even more changes to code.
>
> The models API change that occurred after 0.96 also occurred before
> 1.0. There have been very few breaking changes to it since then (have
> there been any in that department?).
>
> Like Alex, I must have missed a lot of messages to this list if a
> major re-thinking of the admin like this has been repeatedly proposed
> and dismissed. And it's kind of difficult to assess what is currently
> an extremely vague proposal.
>
> Luke
>
> --
> "Whom have I in heaven but You?
> And there is none upon earth that I desire besides You." Psalm 73:25
>
> Luke Plant ||http://lukeplant.me.uk/
--
You received this message because you are subscribed to the
Re: Django Design Czar
let me just add one (more) point to this discussion (I´ve already stressed this issue at the other thread). IMO, when talking about the admin-interface, we´re talking about different "construction zones": – the whole structure and user experience with the admin-interface as mentioned by jeff and others (long-term) – HTML/CSS (quite short-term, this can be changed with baby-steps) – JS-refactoring (already in the making - but, unfortunately, decoupled from refactoring the HTML/CSS) – python-changes, some smaller (like removing hardcoded stuff) and some bigger (if we want to re-discuss the admin index page, for example) – look & feel (probably the least important issue since skins will evolve once skinning is easily possible) considering these zones, I guess I´m following jeffs proposal for a team (with, maybe, a team-leader), because no "design czar" I know is really good with all the mentioned topics. just my 2 cents. regards, patrick On 7 Feb., 08:17, Idan Gazit wrote: > On Feb 7, 6:06 am, Justin Lilly wrote: > > > I, for > > one, am willing to trust their judgement on someone who can lead this > > design-czar selection process, if Wilson doesn't come out and name his > > successor, as it were. > > Something that hasn't been explicitly said yet: > > I *don't* think that the design czar necessarily needs to be a > rockstar designer. Their job is not to design everything > singlehandedly. Their job is to shepherd the design process within > django core. > > Being well-versed in design is obviously a must, but I posit that > familiarity with the community, core devs, and Django's development > practices are more important for this role than being an A-list > designer. > > -I -- 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.
FileBrowseField
my apologies for cross-posting, but the thread started in the user- group ... is anyone interested in having a FileBrowseField? it could look like this: http://www.vonautomatisch.at/django/ftp/get_image.jpg when clicking on the search-image near the image-field, the file- browser should open in a pop-up window in order to search for images/ files or upload images/files. i´m currently working on a file-browser, but i´m unable to do a clean hack for that FileBrowseField. i´ve been looking at the django-code and i think that it should be quite easy for somebody who knows the code (and is a better programmer than i am ...) preview of the file-browser: http://www.vonautomatisch.at/django/ftp/ thanks, patrick --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: multi-select admin filter for RelatedFields
just a comment because noone else is answering: - i can think of using that functionality - AND would be important for me - don´t know if a ticket is appropriate (see: http:// code.djangoproject.com/changeset/2830) patrick Am 11.05.2006 um 00:23 schrieb Marc Boeren: > > Hi, > > I've hacked my way into the admin filters, changing the > RelatedFilterSpec from a single-select filter to a multi-select > filter. > > I can now filter on multiple values from the same ManyToMany or > ForeignKey relationship, i.e. if I add 'groups' to the list_filter for > Users, I can select all users that fall into the Admin or the Editor > group (or both, or more). > > Would this be a useful replacement for the current version, or > could it > become an addition to the current filter methods? > > I plan to do some more work on it (basically, a specifier to indicate > if you want OR or AND for your multiple selection, it is now OR only > (and AND will only work for ManyToMany of course)). > > Should I create a ticket for this and attach a patch? > > Ciao, Marc. > (I posted a similar message on Django users yesterday but I think > it is > more appropriate here) > > > > --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
authentication data
while playing with the authentication system, I don´t really get the pre-defined model. we have first_name, last_name and email in there - these values are optional and we don´t need them for authentication. when I extend the user-model with a user-profile I´m having (profile) values in 2 different tables. e.g., first_name is in model user and address in userprofile. questions: 1. why are these personal values (first name, last name, email) there in the first place? did I miss something? 2. when using a custom manipulator for letting the user change his personal values (first name, last name, address, zip_code ...), I have to change 2 different tables (user and userprofile). that doesn ´t seem to be clean ... ??? 3. why not let the django-user decide what he wants? when we don´t need the personal values for authentication, why does django not support a userprofile where the user/developer defines the table he needs for a specific application (not everybody needs a first name, but it´s still there ...) thanks, patrick --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: authentication data
I totally agree with what you say - and (if I understand you right) that´s exactly my point. it seems like a compromise. we don´t need first_name, last_name and email for user-authentication. it´s just there because of an assumption what users might need (or not). some notes below: Am 10.09.2006 um 22:38 schrieb James Bennett: > > On 9/10/06, patrickk <[EMAIL PROTECTED]> wrote: >> 1. why are these personal values (first name, last name, email) there >> in the first place? did I miss something? > > The User model is not meant to be an exact match for the needs of 100% > of all possible authentication use cases; instead it's meant to match > the needs of most basic authentication use cases. > > And, really, there is absolutely no possible set of fields for users > which would make 100% of developers happy; there would always be > someone saying "I don't need this field, why's it in the model" or "I > need this other field, why isn't it in the model". So Django provides > a basic model with fields for things that people commonly want to > have, and provides a means of extending the model through a related > profile model. I agree. and it´s not about making people happy (well, sometimes it is). it´s about what makes sense and what not. > >> 2. when using a custom manipulator for letting the user change his >> personal values (first name, last name, address, zip_code ...), I >> have to change 2 different tables (user and userprofile). that doesn >> ´t seem to be clean ... ??? > > What would be the alternative? Or, rather, what would be a workable > alternative? in my view, anything that´s not needed for user-authentication belongs to a user-profile. for me (and I may be wrong here) a user- profile is for personal information (like first name, last name, address and what have you). if we strip the user-model to the fields relevant for user- authentication and describe a way to extend it (I know you did that), we could almost make those 100%. there is 2 different users: 1. the one who can use the given model ... fine for them. 2. the user who wants to extend the model. right now, for user nr. 2 the given model stands in the way of extending the user-model. one has to split personal information to 2 tables (not funny). in my view, it´s much cleaner to have user nr. 1 to extend the basic user-model ... > > The problem here is that offering a built-in auth system means that > there *must* be some baseline of fields which Django apps can assume > will exist in the User model. Which means that a free-for-all "define > only the fields you want" system couldn't work; inevitably, some app > somewhere would decide, say, that it was safe to assume fields named > "username" and "password", and then someone would try to install it on > a system where they'd customized away those fields. > > So there is no single-table solution. I know and I never said there should be. > > People often suggest model subclassing as an alternative, but that > doesn't really work either; what people want from extending the User > model is "this model becomes the User model" and what they get from > subclassing is "this model becomes a User model". > >> 3. why not let the django-user decide what he wants? when we don´t >> need the personal values for authentication, why does django not >> support a userprofile where the user/developer defines the table he >> needs for a specific application (not everybody needs a first name, >> but it´s still there ...) > > It's there, but it's optional. If its existence in the database > offends you to an extreme degree, edit the model class directly and > drop that column from your DB :) problem with upgrading django ... thanks, patrick > > > -- > "May the forces of evil become confused on the way to your house." > -- George Carlin > > > --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: authentication data
sure I could do that. not DRY though. anyway, thanks for the hint. patrick Am 11.09.2006 um 17:21 schrieb Rob Hudson: > > patrickk wrote: >> 2. when using a custom manipulator for letting the user change his >> personal values (first name, last name, address, zip_code ...), I >> have to change 2 different tables (user and userprofile). that doesn >> ´t seem to be clean ... ??? > > Can you not put first name, last name, and email in your own > user_profile table and use those fields instead of the default Django > fields? Leave the Django fields blank and always work with your own > fields? > > > > --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
comment to ticket 2839
since my comment is rejected by Akismet, I´m posting it here ...
in filterspecs, line 40
{{{
t.append(_('By %s:\n\n') % self.title())
}}}
in filter.html, line 2
{{{
{% blocktrans with title|escape as filter_title %} By
{{ filter_title }} {% endblocktrans %}
}}}
in django.po, line 354:
{{{
"By %s:\n
"\n"
msgstr ""
"Nach %s:\n"
"\n"
}}}
in my view, that somehow doesn´t fit together.
in filter.html, the translated title doesn´t include "" - the
translation-file looks for though.
i´m using the latest SVN.
patrick
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---
another ticket: related-object window is missing query ...
when doing a search in the related-object window in the admin- interface and using the link "xxx total" after that search, the query is missing. because "pop=1" is in the query, the header is shown ... using 0.95 thanks, patrick (don´t know if it is appropriate to post here, but since my tickets are rejected I thought it´s better than doing nothing ...) --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Dev policy, was Re: Ticket spam
> So far as I can tell, our biggest long-term management problem right > now is not one of scaring developers away, it's one of keeping track > of all the people who want to get involved and all the things they > want to do. You haven't yet provided an example to the contrary. well, then I do. I´m scared away. why? exactly because of what james is writing here. it seems that noone except the "core developers" are allowed to criticize django - whenever something like this comes up on the list, there´s someone who fights the arguments tooth and nail. there´s no discussion culture on this list ... as iain already pointed out, it´s too much about "being right" IMHO. > >> Is it worth it in the long term? *If* one of the long term goals >> is to >> attract a growing dev community that can in the future outdo current >> productivity levels, then absolutely yes. You have *no idea* who is >> lurking on here. You could have super geniuses who don't feel >> inclined >> to comment because they see little of that type of discussion or >> because >> they don't feel their input is really wanted. > > Actually, we do have a few "super geniuses" of the web app world > lurking, and thus far when they've commented we've paid attention > worked with their suggestions. guess I have to prove being a "super genius" before > >> And here's the catch, they *won't say anything*. Most will just ... >> leave. Another extremely important sales/management truth is that >> the >> people you turn off *will not tell you* while the people who love you >> will yak their mouths off. So you absolutely can not believe that >> just >> because you only *hear* positive feedback that everything is cool. >> Developers who maybe decide they would be more welcome at RoR or >> Gears >> aren't going to say anything here when they make that decision! > > The problem here is that there is absolutely no way to quantify this. > It could be that, just within the last twenty-four hours, five million > potential genius developers have looked at the dev list archive and > immediately written it off for not having enough traffic. Or it could > be that they didn't. so, pointless. > Appealing to something that can't be quantified isn't a useful > argument; appealing to actual examples of people speaking up (and they > shouldn't be hard to find -- software developers are notoriously > opinionated and willing to share their opinions) is. from my point of view, it definitely IS hard to speak up. when dealing with an "open" project you´re having people from different cultures with a different style of communication and a lot of misunderstanding (e.g., from your point of view I probably misunderstood your posting). but it should be one of the aims of a list like this to integrate these different cultures. for example (again, very personal - it´s hard to point that out all the time but I think it´s necessary): the RoR-list seems much more open and "nice" to me. the reason is probably the style of discussion there. > >> Well I can't say I feel the need to do so as the impression I get >> from >> this reply and your blog is that you are more concerned with "being >> right" ( proving Django is doing everything right as it stands ) than >> "getting what you want" ( having Django become as good as it could >> be ). > > No, my concern is with figuring out how concerned I need to be about > this. that´s hard to believe when reading your stuff here ... probably some kind of "misunderstanding". > > Django is not perfect. Django is not always right. Django is not > all-knowing or all-seeing or all-powerful. Django has and always will > have problems of varying degrees of criticality. But right now I > cannot for the life of me figure out whether you're pointing out a > problem that it has, and if so how critical that problem is at the > given moment. IMHO, there is a more basic problem. it´s the problem of not being able to criticize. I´ve done it before and people tend to see it as a personal attack while (from my point of view) it´s suggestions and the will to help and improve the project. moreover, since english is obviously not my primary language it´s sometimes hard to explain what I really mean. if someone comes up with something really stupid which has been discussed a thousand times before, I´m not having a problem telling this person to "shut up" and re-read the discussions. that´s fine. on the other hand, there seems to be a tacit understanding on communicating how great django is. and only the "super genius" is allowed to criticize: http://www2.jeffcroft.com/2006/jul/20/top-ten-things-suck-about-django/ > And then one day, out of the blue, someone new posts to your mailing > list that your project is widely perceived as being closed to > "outsiders", and that your project has serious long-term image > problems. When asked, this person does not supply any examples of > people expressing this
off-topic: filebrowser svn setup
I finally made it to setup trac/svn for our filebrowser (http:// www.vonautomatisch.at/django/filebrowser/) my question is: where should I put the media- and template-stuff? if I use a subdirectory for media/templates, one has to copy this directory after a svn checkout. I´m not sure if there´s a way to avoid this, but I want to make it as easy as possible for people who use the filebrowser. right now the directory-structure looks like this: filebrowser/trunk/ filebrowser/trunk/ filebrowser/trunk/models.py filebrowser/trunk/urls.py filebrowser/trunk/views.py filebrowser/media/img/filebrowser/... filebrowser/templates/filebrowser/... btw: I´m a total trac/svn-newbie (therefore, sorry if this is a dumb question). thanks, patrick --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: off-topic: filebrowser svn setup
thanks. Am 05.11.2006 um 20:34 schrieb Guillermo Fernandez Castellanos: > > As I've seen in other projects, people tend to put their template and > media folders in the same directory as their application. Then people > can symlink those directories to wherever they want. > > So, like this: > filebrowser/trunk/ > filebrowser/trunk/filebrowser > filebrowser/trunk/filebrowser/models.py > filebrowser/trunk/filebrowser/urls.py > filebrowser/trunk/filebrowser/views.py > filebrowser/trunk/filebrowser/media/img/filebrowser/... > filebrowser/trunk/filebrowser/templates/filebrowser/... > > G > > On 11/5/06, patrickk <[EMAIL PROTECTED]> wrote: >> >> I finally made it to setup trac/svn for our filebrowser (http:// >> www.vonautomatisch.at/django/filebrowser/) >> >> my question is: where should I put the media- and template-stuff? >> if I use a subdirectory for media/templates, one has to copy this >> directory after a svn checkout. I´m not sure if there´s a way to >> avoid this, but I want to make it as easy as possible for people who >> use the filebrowser. >> >> right now the directory-structure looks like this: >> filebrowser/trunk/ >> filebrowser/trunk/ >> filebrowser/trunk/models.py >> filebrowser/trunk/urls.py >> filebrowser/trunk/views.py >> filebrowser/media/img/filebrowser/... >> filebrowser/templates/filebrowser/... >> >> btw: I´m a total trac/svn-newbie (therefore, sorry if this is a dumb >> question). >> >> thanks, >> patrick >>> >> > > > --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: off-topic: filebrowser svn setup
thanks - it´s been difficult enough. we´re doing the latest setup right now (permissions and stuff), then updating to the latest version. it should be done within the next 2 days or so - I´ll post the URL here ... patrick Am 06.11.2006 um 11:28 schrieb Aidas Bendoraitis: > > Congratulations about setting up the FileBrowser under svn! By the > way, if the FileBrowser project is open to public, what is the URL for > the latest and greatest revision? > > Regards, > Aidas Bendoraitis > > > > On 11/5/06, patrickk <[EMAIL PROTECTED]> wrote: >> >> thanks. >> >> Am 05.11.2006 um 20:34 schrieb Guillermo Fernandez Castellanos: >> >>> >>> As I've seen in other projects, people tend to put their template >>> and >>> media folders in the same directory as their application. Then >>> people >>> can symlink those directories to wherever they want. >>> >>> So, like this: >>> filebrowser/trunk/ >>> filebrowser/trunk/filebrowser >>> filebrowser/trunk/filebrowser/models.py >>> filebrowser/trunk/filebrowser/urls.py >>> filebrowser/trunk/filebrowser/views.py >>> filebrowser/trunk/filebrowser/media/img/filebrowser/... >>> filebrowser/trunk/filebrowser/templates/filebrowser/... >>> >>> G >>> >>> On 11/5/06, patrickk <[EMAIL PROTECTED]> wrote: >>>> >>>> I finally made it to setup trac/svn for our filebrowser (http:// >>>> www.vonautomatisch.at/django/filebrowser/) >>>> >>>> my question is: where should I put the media- and template-stuff? >>>> if I use a subdirectory for media/templates, one has to copy this >>>> directory after a svn checkout. I´m not sure if there´s a way to >>>> avoid this, but I want to make it as easy as possible for people >>>> who >>>> use the filebrowser. >>>> >>>> right now the directory-structure looks like this: >>>> filebrowser/trunk/ >>>> filebrowser/trunk/ >>>> filebrowser/trunk/models.py >>>> filebrowser/trunk/urls.py >>>> filebrowser/trunk/views.py >>>> filebrowser/media/img/filebrowser/... >>>> filebrowser/templates/filebrowser/... >>>> >>>> btw: I´m a total trac/svn-newbie (therefore, sorry if this is a >>>> dumb >>>> question). >>>> >>>> thanks, >>>> patrick >>>>> >>>> >>> >>>> >> >> >>> >> > > > --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
admin-interface issues
here are some issues concerning styles/layout and a couple of general issues. some of the mentioned problems might be more important than others - I just wanted to give a very personal list of what I´ve noticed: HTML/CSS: ### booleanfields are displayed different than any other fields - the label is on the right hand side of the formfield. ### why is not every fieldset collapsible (and only fieldsets with class=collapse are closed on invocation)? ### what´s the reason for caption and h2 not being in grid with the labels (caption is moved some pixels to the left)? GENERAL: ### related objects are not linked (referring to change-list and change-form). ### some HTML is defined in the views. is that necessary? ### objects which are edited inline are not collapsible. ### changelist: is it possible to make a visual distinction in the table-header between sortable- and non-sortable fields? e.g., when list_display refers to a custom function displaying some value from another table, it´s not possible to sort the list according to that value (still, it looks like any other table-header). ### it should be a lot easier to change the width of the labels IMHO. in german, one usually needs more space for the labels. when changing the width of the labels in the styles, the date-fields are in the wrong place (and some help-texts are wrong ...) thanks, patrick --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: inline_models as a replacement for edit_inline?
Am 16.11.2006 um 11:30 schrieb Aidas Bendoraitis: > > Not a bad change, but much more important, in my opinion, would be to > have an ability to set the fields of inline edited models according > the formatting set in fields list/tuple; with all the features as > collapsible groups of fields, placing fields next to each other > horizontally, setting HORIZONTAL style for many-to-many selection > fields and so on. > > Regards, > Aidas Bendoraitis [aka Archatas] +1 > > > > On 11/15/06, Rob Hudson <[EMAIL PROTECTED]> wrote: >> >> I stumbled across this ticket with patch a couple months ago. I >> thought of it recently and wanted to bring it to the attention of the >> developers. I like the idea and it looks like it simplifies the >> edit_line stuff a lot... >> >> http://code.djangoproject.com/ticket/2248 >> >> >>> >> > > > --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
proposal: multiple search-fields in admin
I´ve just been looking at the admin-generator in symfony and it has the possibility to add multiple search-filters. we had this problems recently: 1. it´s currently not clear which columns are searched when using the search-field in the admin-list. that´s sometimes very strange, especially when using model-methods. 2. it´s not possible to have multiple search-fields, each one searching different columns. this is very restrictive IMHO. proposal: 1. it´d be great to have multiple search-fields, with each search- field referring to one ore more columns. 2. the search-fields could be displayed above the filters on the right hand-side. since my last post concerning the admin-interface didn´t provoke any reactions, I´m not quite sure whether this issues are interesting for the django-developers. if not, a short note with something like "shut up, pal. admin- improvement is no issue." will do. thanks, patrick --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: New branch: newforms-admin
just 2 small things you may want to implement: 1. the opportunity to translate the apps - useful for the admin index-page. 2. for showing the permissions, use "app | model | Can ..." insted of "model | Can ..." - this is especially useful if one has the same model-names within different apps. thanks, patrick Adrian Holovaty schrieb: Hi all, I've created a newforms-admin branch, which will focus on integrating django.newforms with the Django admin site. A branch is necessary here because it's a big change that will span multiple changesets and undoubtedly cause temporary breakage. I considered just making a separate URLconf or views for a newforms-enabled admin site in trunk, rather than a branch, but then I realized templates will need to change as well, so it's more manageable to use a branch. I intend this to be a relatively quick branch -- nothing approaching the time length of our new-admin and magic-removal branches in the past. I'm setting a deadline of Jan. 31 for the merge. I'll be doing the primary development on this branch, but if you're interested in commit access to help out, drop me an e-mail off list. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Anyone using RazorLogix for hosting?
i´m using razorlogix. # easy one-click django-install # it seems that you are limited to the django-version they provide - so it´s currently not possible to install magic-removal (i didn´t try it, btw) # fast and stable (e.g. compared with dreamhost) # BUT: they´re still having the problem of providing a tool for gracefully restarting apache (e.g. after you changed your models). the script they provide does not work. i´ve had some discussion with the razorlogix-team and they are trying to solve the problem. # you can´t use the django development-server # nice admin-interface (plesk) patrick Am 01.04.2006 um 14:09 schrieb tonemcd: > > Hi all, > Razorlogix, http://www.razorlogix.net/?do=features, looks quite a neat > hosting service (mod_python, one slick installs for django, trac, svn, > MySQL and PostGres etc.) > > Does anyone have any opinions on them? > > Thanks a lot in advance, > Tone. > > > > --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Anyone using RazorLogix for hosting?
yes, i probably _could_ install MR (so far, i´ve been using the one- click-installer with razorlogix). but you are right, there shouldn´t be a problem. in the razorlogix help desk it says that using the development server is not possible. patrick Am 01.04.2006 um 15:03 schrieb tonemcd: > > I didn't mean to start this discussion off in this group, but on > reflection, it might be the better one of the two... > > Patrick, > Can you not install MR into your own space (mine only takes up 18 > Megs, > and the $10 plan has 500 megs of disk) and use it from there? Would > you > not get the development server as well? > > Cheers, > Tone > > > > --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Proposal: make app index optional
IMO this issue is not related to grappelli whatsoever. the question is, if the app-index makes sense to an editor? and I think that this not the case – because an editor doesn´t need know what an "app" (within a django-project) is. my experience is that editors are extremely confused about the whole "app-thing" ... esp. with the index-page which is a list of "INSTALLED APPS" which is hard to explain to someone responsible for the content of a website. if the admin-interface is for developers, the app-index does make sense. if the admin-interface is for editors, the app-index doesn´t make sense at all. best, patrick -- 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/-/OXna2sfOBfIJ. 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: Django Admin Revamp - Any updates?
I agree with Idan. We mainly did Grappelli because of the look & feel (and then added some functionality like autocompletes). However, it just doesn´t make sense to simply "beautify" the existing admin-interface. Rethinking the functionality, adding flexibility, being able to customize ... these are all necessary steps IMHO, but I´m still missing a clear approach/roadmap on how/when this should happen. I planned to give a talk on djangocon.eu about how to improve the admin-interface. Unfortunately, I had to step back from that idea because of some customer-related projects. Still, the thoughts are there and I´m happy to discuss this issue anytime. This discussion could start with defining the so-called "trusted editor" – what does he/she knows resp. needs to know when dealing with the admin-interface? What are the consequences (e.g., does an editor care about an app-list, does he even know what it is)? What working-groups do we need (python, html/css, js, ...)? How can we publish the process/discussion? And much more ... let´s start ... but how? best, patrick Am Montag, 30. April 2012 23:41:14 UTC+2 schrieb Idan Gazit: > > > > On Monday, April 30, 2012 at 10:16 AM, Brett H wrote: > > > Increasing the flexibility for development and integration is more > > important than trying to 2nd guess where we are going to be in 5 years > > time. > > Fair enough, but that sort of flexibility is available now. Nothing is > preventing you from starting your 3rd-party admin app today. > > > > The issue is Django's officially-blessed, officially-documented admin. I'm > not sure it's better to have admin in contrib (or contrib at all, but > that's a separate ball of wax). I have a feeling that this issue will > probably be addressed once again now that we're on github. > > All the same, if there's going to be an official django admin, I'd like it > to give some thought to the issues I've raised. I have no problem (read: > would love) to draw upon existing solutions for an admin revamp, but right > now I don't have a fitness function to guide my decisions, and I think that > is necessary. Not a spec, just an attempt to step back and think about what > the admin should do. > > -I > > > -- 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/-/J5836To_XtkJ. 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.
proposal/implementation for reordering inlines
hi,
the plan is to allow for reodering inlines within the admin-interface
(using drag/drop). before starting to work on patches, I´d like to
discuss some issues ...
features:
1. drag/drop (with jQuery-UI sortables).
2. in case of errors (somewhere within the form), the position of
inline-rows should be preserved. this should work for inlines prepared
for deletion as well. empty inline-rows could be moved to the end of
the formset.
the only decent implementation I´ve come up with (so far) is this one:
1. reorder inlines (based on a sortable-field) with a templatetag. it
currently looks like this:
{% for inline_admin_form in inline_admin_formset|
formsetsort:inline_admin_formset.opts.sortable_field %}
2. sortable_field is an attribute defined with your InlineAdmin. it
should be a positiveintegerfield within your model.
3. when submitting the form, the values of the position-fields are
being reindexed.
about 1: this is necessary in order to preserve the position of inline-
rows in case of errors. reordering the inlines with javascript (on
load) is not an option IMO.
about 2: this could also be achieved with order_with_respect_to, but I
think it´s better to explicitely define the sortable-field.
optinal:
using django-positions (https://github.com/jpwatts/django-positions)
could be optional: with a position-field, the reindexing (on submit)
is not necessary.
I already have well tested version of this implementation. the
templatetag is a simple 10-liner (see blow). the only thing needed is
to add the js for sortables to tabular.html and stacked.html (which is
pretty simple as well).
of course, the actual reordering (drag/drop-js) could be optional.
with adding the formsetsort-filter to django, one could implement the
drag/drop easily with a custom template. here´s the template-filter:
@register.filter
def formsetsort(value, arg):
"""
Takes a list of formset dicts, returns that list sorted by the
sortable field.
"""
sorted_list = []
for item in value:
position = item.form[arg].data
if position and position != "-1":
sorted_list.append((int(position), item))
sorted_list.sort()
sorted_list = [item[1] for item in sorted_list]
for item in value:
position = item.form[arg].data
if not position or position == "-1":
sorted_list.append(item)
return sorted_list
what do you think?
regards,
patrick
--
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: proposal/implementation for reordering inlines
On Dec 12, 12:50 am, Russell Keith-Magee wrote: > On Sat, Dec 11, 2010 at 11:28 PM, patrickk wrote: > > hi, > > > the plan is to allow for reodering inlines within the admin-interface > > (using drag/drop). before starting to work on patches, I´d like to > > discuss some issues ... > > > features: > > 1. drag/drop (with jQuery-UI sortables). > > 2. in case of errors (somewhere within the form), the position of > > inline-rows should be preserved. this should work for inlines prepared > > for deletion as well. empty inline-rows could be moved to the end of > > the formset. > > I might be missing something here, but isn't this something that was > implemented in Zain Memon's 2009 GSoC project, but wasn't sufficiently > stable and reviewed to warrant being merge to trunk? How does your > proposal compare to the work that has already been done in this area? the main difference is that with every implementation I´m aware of (including zains), the position of inline-rows are not preserved in case of errors. I´ve been talking with zain about this issue and I´m quite sure there hasn´t been a solution (I´ve just checked his code and couldn´t find anything). of course, it´s a bit easier if we decide that positions are not being preserved ... IMO, that´s not an option though. second, zain implemented two different reordering-javascripts for tabular and stacked (back then, the UI-sortable couldn´t handle table- rows). moreover, I´m not saying django should implement the drag/drop behaviour right now (although that´d be nice). with the formsetsort- filter, one could easily add drag/drop behaviour with a simple custom template. since python is not my strong point, I´m sure the filter can be optimized. with adding two lines of code, we could also add the ordering_field (can_order) to the admin. we could then still keep an eye on actual implementations. so, with two very simple changes we could lay ground for drag/drop behaviour. what exactly do you mean with "stable"? regards, patrick > > Yours, > Russ Magee %-) -- 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: proposal/implementation for reordering inlines
On 12 Dez., 13:29, Russell Keith-Magee wrote: > On Sun, Dec 12, 2010 at 6:04 PM, patrickk wrote: > > > On Dec 12, 12:50 am, Russell Keith-Magee > > wrote: > >> On Sat, Dec 11, 2010 at 11:28 PM, patrickk > >> wrote: > >> > hi, > > >> > the plan is to allow for reodering inlines within the admin-interface > >> > (using drag/drop). before starting to work on patches, I´d like to > >> > discuss some issues ... > > >> > features: > >> > 1. drag/drop (with jQuery-UI sortables). > >> > 2. in case of errors (somewhere within the form), the position of > >> > inline-rows should be preserved. this should work for inlines prepared > >> > for deletion as well. empty inline-rows could be moved to the end of > >> > the formset. > > >> I might be missing something here, but isn't this something that was > >> implemented in Zain Memon's 2009 GSoC project, but wasn't sufficiently > >> stable and reviewed to warrant being merge to trunk? How does your > >> proposal compare to the work that has already been done in this area? > > > the main difference is that with every implementation I´m aware of > > (including zains), the position of inline-rows are not preserved in > > case of errors. I´ve been talking with zain about this issue > > For future reference, this is the sort of thing that you should > mention when you start a conversation on django-dev. Demonstrating > that you know about the prior history of a feature (including any past > attempts to implement it) shows that you've done your homework. > > > > > and I´m > > quite sure there hasn´t been a solution (I´ve just checked his code > > and couldn´t find anything). of course, it´s a bit easier if we decide > > that positions are not being preserved ... IMO, that´s not an option > > though. > > second, zain implemented two different reordering-javascripts for > > tabular and stacked (back then, the UI-sortable couldn´t handle table- > > rows). > > > moreover, I´m not saying django should implement the drag/drop > > behaviour right now (although that´d be nice). with the formsetsort- > > filter, one could easily add drag/drop behaviour with a simple custom > > template. since python is not my strong point, I´m sure the filter can > > be optimized. > > with adding two lines of code, we could also add the ordering_field > > (can_order) to the admin. we could then still keep an eye on actual > > implementations. > > > so, with two very simple changes we could lay ground for drag/drop > > behaviour. > > I'm a little hesitant to lay ground work when I'm not completely > certain where the road is going. I like the idea of adding API hooks > that others outside Django's core can exploit, but I need to be > convinced that the hooks that are being proposed actually *can* be > exploited. A proof of concept would go a long way in this regard. fair enough. let me clarify and add some additional information. first, we add the can_order attribute to InlineModelAdmin (2 lines of code in django.contrib.admin.options.py). as a default, can_order=False, but when I add the attribute to my admin-definition I´m able to change that (ok, that´s another 2 lines in options.py): class MyInline(admin.TabularInline): model = MyInlineModel extra = 2 can_order = True now we´re having an additional input-field (ORDER). based on the value of this field, I can now loop through my inline- forms: class MyModel(admin.ModelAdmin): ... def save_formset(self, request, form, formset, change): if formset.can_order: for inlineform in formset.ordered_forms: # do whatever # e.g. set the value of my position-field formset.save_m2m() if we now add the formsetsort-filter, one can easily add drag/drop – one just needs to re-index the values of the ORDER-field on submit. I currently won´t care too much about hiding the ORDER-field or adding the necessary javascript for drag/drop-support. regards, patrick > > From a project management point of view, I want to point out that my > personal focus isn't on admin UI stuff at the best of times, and > especially when we're overdue for a beta feature freeze. I fully > encourage you to keep pursuing this, but please be aware that unless > you get another core developer *really* excited in the next couple of > days, this almost certainly won't make the cut for 1.3. > > > what exactly do you mean with "stable"? > > I mean that the code works, reliably, and cross-browser, and has been > tested to that end by multiple parties. > > Yours, > Russ Magee %-) -- 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.
template-caching: fragment name as variable
before adding a new ticket I just wanted to discuss this issue:
when using template-caching it´s sometimes useful to have a variable for the
"fragement name".
e.g., I want to prefix all caching-variables with "myapp_userid", because I
need to delete alle user-related caching-variables at some point where I
don´t have the necessary caching-variables (besides the user-id).
so, instead of writing:
{% cache 500 "fragment_name" request.user.id other_vars %}
I´d like to have
{% cache 500 "fragment_name_including_user_id" other_vars %}
I just hacked the templatetag "cache" and it seems to be quite easy using a
context-variable for the fragment name.
{% cache 500 "fragment_name" cache_var %}
{% cache 500 fragment_var cache_var %}
what do you think?
regards,
patrick
--
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.
initial data for inlineformset_factory
any reason, why it´s currently impossible to use "initial" with inlineformset_factory. is it planned to integreate this feature? thanks, patrick --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: initial data for inlineformset_factory
usecase: let´s say you have a "booking" (form) with a number of X "booking amounts" (formset). now the user could be able to save a pre-defined template for common bookings. these templates are saved as "template" and "template amounts". so, if the user selects a given template, the template-amounts should be the "initial date" for the booking amounts. maybe this is totally out of scope, I´m not sure. and maybe there´s another way to insert the template ... it just seemed very natural for me to use "initial" with an inline mode formset, till I figured out it ´s not possible. patrick. On Aug 19, 9:22 pm, "Brian Rosner" <[EMAIL PROTECTED]> wrote: > On Tue, Aug 19, 2008 at 12:10 PM, patrickk <[EMAIL PROTECTED]> wrote: > > > any reason, why it´s currently impossible to use "initial" with > > inlineformset_factory. is it planned to integreate this feature? > > I guess I am failing to see how this is useful? initial data in an > inline model formset is based on the queryset such as it is a subclass > of model formset. Could you provide a use case where it might be worth > it to also provide initial data for an inline model formset? It would > seem that a default value on a model field would be sufficient. Seems > a bit overkill for the general case due to the unknown size of the > queryset. > > -- > Brian Rosnerhttp://oebfare.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: initial data for inlineformset_factory
now this question is probably better posted in django-users, but: is there any way to prepopulate an unbound formset using inlineformset_factory? thanks, patrick On Aug 19, 10:05 pm, "Justin Fagnani" <[EMAIL PROTECTED]> wrote: > Uh.. disregard that. My mistake. I read the code wrong and > BaseInlineFormSet does not take **kwargs and pass them to > BaseModelFormSet.__init__(), so no you can't specify 'initial'. Which > is good. > > -Justin > > On Tue, Aug 19, 2008 at 12:54 PM, Justin Fagnani > > <[EMAIL PROTECTED]> wrote: > > On Tue, Aug 19, 2008 at 12:22 PM, Brian Rosner <[EMAIL PROTECTED]> wrote: > >>Seems > >> a bit overkill for the general case due to the unknown size of the > >> queryset. > > > It is possible to specify both a queryset and initial data with a > > ModelFormSet or InlineModelFormSet, and initial will override the > > queryset, but the queryset is still kept around. Looks like that could > > cause some problems in save_existing_objects(), especially if initial > > and queryset aren't the same size. > > > -Justin > > --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
limit_choices_to has no effect on list_filter?
I found this patch (http://code.djangoproject.com/ticket/3096), but it ´s not working. is anybody working on this issue? thanks, patrick --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Proposal: ordering edit-inlines with order_with_respect_to (admin-interface)
IMHO, when using "order_with_respect_to", one should be able to order the inlines (stacked & tabular). what´s necessary: 1. can_order should be set to true when using "order_with_respect_to". e.g., if you currently subclass a formset and use can_order=true, there ´s an error in the admin-interface (key "ORDER" not found). 2. ordered_forms should be available independently from is_valid() - even if there´s an error somewhere in your form, the ordering should be retained. note: this proposal is not about integrating some drag/drop- functionality within the templates (using javascript). although that would be nice, it´s just about having the _possibility_ to reorder stuff. thanks, patrick --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Proposal: ordering edit-inlines with order_with_respect_to (admin-interface)
if someome points me to the right direction, I might be able to provide a patch for this issue. yesterday, I tried to sketch the relations between the different formset-classes, -methods and - helpers, but (to be honest) I´m a bit lost here. furthermore, it´be interesting if the dev-team wants this to be solved or if this behaviour is intentional (for whatever reason). thanks, patrick On 22 Okt., 18:06, patrickk <[EMAIL PROTECTED]> wrote: > IMHO, when using "order_with_respect_to", one should be able to order > the inlines (stacked & tabular). > > what´s necessary: > 1. can_order should be set to true when using "order_with_respect_to". > e.g., if you currently subclass a formset and use can_order=true, there > ´s an error in the admin-interface (key "ORDER" not found). > 2. ordered_forms should be available independently from is_valid() - > even if there´s an error somewhere in your form, the ordering should > be retained. > > note: this proposal is not about integrating some drag/drop- > functionality within the templates (using javascript). although that > would be nice, it´s just about having the _possibility_ to reorder > stuff. > > thanks, > patrick --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Proposal: ordering edit-inlines with order_with_respect_to (admin-interface)
thanks, jacob. doing the OrderingField doesn´t seem too much or a problem (and I do like the idea of getting rid of order_with_respect_to). where I´m really struggeling is the admin-interface: let´s say I have changed the order of my inline-related forms, I´ve made an error (e.g. a required field is not given somewhere within the whole form) and then I click "submit". of course, the inline-related forms should be displayed in the new order - but that order is not saved yet. so, I´m not quite sure how this OrderingField has to be connected with the admin-functionality. the only solution I can think of right now is reordering the inline- related forms via javascript onload. but that´s already possible and doesn´t require an OrderingField. it gets even more complicated when thinking of empty extra forms, ordered between forms with an "original". these empty forms should be removed from the list (in case of an error) from my point of view. any ideas on how to reorder inline-related forms in case of an error? I ´d definitely prefer a non-javascript-solution ... thanks, patrick On 28 Okt., 16:31, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]> wrote: > On Wed, Oct 22, 2008 at 10:06 AM, patrickk <[EMAIL PROTECTED]> wrote: > > IMHO, when using "order_with_respect_to", one should be able to order > > the inlines (stacked & tabular). > > Yup, this has been on the todo list for quite some time. We even > discussed it at PyCon a couple years ago as we kicked off > newforms-admin. A few things that I recall from that discussion: > > * We decided that we'd like to remove ``order_with_respect_to`` — > particularly the way it adds a magical ``_order`` field — in favor of > an explicit ``OrderingField``. > > * This would work with related objects:: > > class Poll(Model): > ... > > class Choice(Model): > poll = ForeignKey(Poll, related_name="choices") > order = OrderingField(with_respect_to="poll") > > * This would give you an API that provided things like > ``poll.choices.in_order()`` and ``poll.choices.set_order()``. > > * ``OrderingField``s would also work without a related object:: > > class Person(Model): > order = OrderingField() > > * That'd allow APIs like ``Person.objects.in_order()`` and > ``Person.objects.set_order()``. > > I can't recall more of this discussion, but perhaps this'll be enough > to get you (or someone) started? > > Jacob --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Focusing on inlines this week
if you like to implement reordering inlines (as outlined in wilsons graphic for stacked inlines), you might wanna consider this: in case of an error, the reordering should be preserved (of course). as far as I know, this is currently not possible with the way django handles formsets. it´d be absolutely awesome to have this feature though ... we´ve done something similar with grappelli (using jquery): http://code.google.com/p/django-grappelli/wiki/inlinemodeladminoptions thanks, patrick On 9 Jun., 14:16, Renato Garcia Pedigoni wrote: > Great! > I agree with you that selector inline should not replace stacked > inlines. Keep up the good work! > > On Tue, Jun 9, 2009 at 8:51 AM, Philip Roberts > wrote: > > > Hi Zain, > > > Great project you've got there, looking forward to seeing more of what you > > get up to. > > > Phil > > -- > Atenciosamente, > Renato Garcia Pedigoni --~--~-~--~~~---~--~~ 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: Focusing on inlines this week
@zain: awesome ... definitely looking forward to that. On 15 Jun., 09:44, Zain Memon wrote: > Yeah, I've been keeping a close eye on grappelli -- you guys have done some > really cool stuff. I plan on refactoring the ordering APIs to make it > possible to preserve reordering on errors. That's my next task :) > Zain > > On Fri, Jun 12, 2009 at 1:34 AM, patrickk wrote: > > > if you like to implement reordering inlines (as outlined in wilsons > > graphic for stacked inlines), you might wanna consider this: > > in case of an error, the reordering should be preserved (of course). > > as far as I know, this is currently not possible with the way django > > handles formsets. > > > it´d be absolutely awesome to have this feature though ... > > > we´ve done something similar with grappelli (using jquery): > >http://code.google.com/p/django-grappelli/wiki/inlinemodeladminoptions > > > thanks, > > patrick > > > On 9 Jun., 14:16, Renato Garcia Pedigoni > > wrote: > > > Great! > > > I agree with you that selector inline should not replace stacked > > > inlines. Keep up the good work! > > > > On Tue, Jun 9, 2009 at 8:51 AM, Philip Roberts < > > latentf...@googlemail.com>wrote: > > > > > Hi Zain, > > > > > Great project you've got there, looking forward to seeing more of what > > you > > > > get up to. > > > > > Phil > > > > -- > > > Atenciosamente, > > > Renato Garcia Pedigoni > > --~--~-~--~~~---~--~~ 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: Try out new inline features [GSoC admin-ui]
very nice ... some things I´ve came across: - the ordering is not preserved in case of errors. - with stacked inlines, an error should be indicated on the left-hand side (with comment-selectors). otherwise one has to click through all selectors. - with stacked inlines, there´s something wrong with the numbers when clicking on "add comment". sometimes the numbers are right, sometimes not. hope this will find its way to the trunk very soon. thanks, patrick On 6 Jul., 11:20, Zain Memon wrote: > Hi everyone, > In the last couple of weeks, I've implemented a bunch of inline features. > > Pictures speak louder than words, so I wrote up a quick blog post describing > what's done:http://inzain.net/blog/2009/07/new-features-for-inlines/ > > Also, I set up a server running my Django branch if you want to try them > out:http://inzain.net:8000/admin/ > > Play around and let me know what you think -- especially if you run into any > bugs :) > > Until next week...ish, > Zain > > --- > My GSoC > proposal:http://inzain.net/blog/2009/05/django-gsoc-09-admin-ui-improvements/ --~--~-~--~~~---~--~~ 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: Try out new inline features [GSoC admin-ui]
@aniybak: yes, we´re doing usability-tests very frequently. that´s one reason why we came up with django-grappelli ... btw, I absolutely agree with the "cancel-button". about the delete-button: IMHO, one needs the possibility to undo the deletion - that´s why it´s almost impossible to let items disappear. regards, patrick On 6 Jul., 16:26, andybak wrote: > Nice! > > Are you planning to do anything to finesse the behaviour of the > 'delete' button? It would be nice (especially on selector inlines) if > it looked like items disappeared immediately. > > I also feel the admin change pages needs a 'cancel' button. It's quite > counter-intuitive that the way to leave the page without saving > changes is to simply navigate away without clicking save. This has > come up in a couple of quick usability tests. (Incidentally - is > anyone else doing usability tests on the Django Admin? It would be > nice to pool findings) --~--~-~--~~~---~--~~ 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: Try out new inline features [GSoC admin-ui]
hi zain, I´m not sure if this is the right place to start a discussion about usability testing, but I still post the main issues here ... see http://code.google.com/p/django-grappelli/wiki/djangoissues for further details. the main problem for our clients is the admin index page and how "installed apps" are listed there. I know that it´s possible to customize this page, but that´s not the point (because it leads to unwanted behaviour). when I have to explain to my customers why apps are listed the way they are, it´s always getting complicated. customers are not interested in something like "installed apps" - they don´t even know what apps are (and they don´t have to). a simple example: you´re having an app "auth" with "groups" and "users". and you´re also having an app "user" with a "user profile". of course, you want to list "groups", "users" and "user profiles" on ONE place on the admin index page. my clients always call me for something like "I can´t find the users profile" (because there are 124 models listed between the app "auth" and the app "user"). IMHO, that´s currently the biggest weakness of the admin-interface when it comes to "usability". there´s a lot more to say here, but I´m not sure if this is somehow related to your work - not sure if you only work on the inline-stuff or the admin-interface overall. besides the index-page, someone should take a look at the html/css. the programming is a mess in certain places (e.g., every input-field on the change-form has a class, but decimalfield and floatfield don ´t). moreover, the naming of the css-classes doesn´t seem to be well thought out. something which is related to inlines: currently, with stacked-inlines you´re having "comment #1 ...", "comment #2 ..." and so on on the left- hand side. IMHO, you should display __unicode__ there (I hope you know what I mean). because with 20 comments listed there, one has to click through all items to actually see what´s in there ... one more thing: it currently says "Add a choice" - I´m not sure if this should be "Add a Choice" in order to be translated correctly. thanks, patrick On 7 Jul., 08:21, Zain Memon wrote: > Thanks for the feedback, everyone. I'll focus on improving error handling > and styles to make reordering more intuitive. > patrickk and andybak: I'd love to hear your findings from usability tests. I > will be in a pretty good position to implement fixes you suggest (barring > community approval) once GSoC is over. > > Zain > > On Mon, Jul 6, 2009 at 10:25 AM, patrickk wrote: > > > @aniybak: yes, we´re doing usability-tests very frequently. that´s one > > reason why we came up with django-grappelli ... > > > btw, I absolutely agree with the "cancel-button". > > > about the delete-button: IMHO, one needs the possibility to undo the > > deletion - that´s why it´s almost impossible to let items disappear. > > > regards, > > patrick > > > On 6 Jul., 16:26, andybak wrote: > > > Nice! > > > > Are you planning to do anything to finesse the behaviour of the > > > 'delete' button? It would be nice (especially on selector inlines) if > > > it looked like items disappeared immediately. > > > > I also feel the admin change pages needs a 'cancel' button. It's quite > > > counter-intuitive that the way to leave the page without saving > > > changes is to simply navigate away without clicking save. This has > > > come up in a couple of quick usability tests. (Incidentally - is > > > anyone else doing usability tests on the Django Admin? It would be > > > nice to pool findings) > > --~--~-~--~~~---~--~~ 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: Try out new inline features [GSoC admin-ui]
more feedback to your inline-solution: ### if you use a draghandler for stacked-inlines, there should be a draghandler for tabular-inlines as well (instead of dragging the whole row). ### deleting stacked-inlines: not sure if the delete-button should be displayed with the selectors (near the draghandler). if not, there should at least be an indication on the left-hand side if (or if not) something has been marked for deletion. ### from my point of view, the representation of an original object with tabuar-inlines is redundant. within the paragraph can be removed. css-stuff: ### the comma seperated integer field has the class "vTextField". not nice. ### why has URLField the class "vURLField" and EmailField has the class "vTextField". very inconsistent here. ### IPAddressField again misses the class, the same for filepathfield and so on ... I´m not going to list everyhing here since you probably know what I mean. it´s currently very messy (sometimes there is a class, sometimes not, sometimes the class doesn´t relate to the field ...). ### I´d use a different class for _every_ field. most of the time, it ´s the same as vTextField, but it makes customization so much easier. and it´s clean and coherent. ### at the change-list, the save-button (if you have forms on the list) is within the paginator. shouldn´t be there, from my point of view. regards, patrick On 7 Jul., 11:16, Zain Memon wrote: > Hey Patrick -- > > On Tue, Jul 7, 2009 at 1:04 AM, patrickk wrote: > > > [snip] > > > there´s a lot more to say here, but I´m not sure if this is somehow > > related to your work - not sure if you only work on the inline-stuff > > or the admin-interface overall. > > Both my GSoC project and future interests lie in improving the overall > usability of the admin interface, so feel free to pitch away. > > > besides the index-page, someone should take a look at the html/css. > > the programming is a mess in certain places (e.g., every input-field > > on the change-form has a class, but decimalfield and floatfield don > > ´t). moreover, the naming of the css-classes doesn´t seem to be well > > thought out. > > I'll take a look at the decimalfield and floatfield classes. If there are > other major inconsistencies, let me know and/or file a bug. > > > something which is related to inlines: currently, with stacked-inlines > > you´re having "comment #1 ...", "comment #2 ..." and so on on the left- > > hand side. IMHO, you should display __unicode__ there (I hope you know > > what I mean). because with 20 comments listed there, one has to click > > through all items to actually see what´s in there ... > > one more thing: it currently says "Add a choice" - I´m not sure if > > this should be "Add a Choice" in order to be translated correctly. > > It actually *is* the __unicode__ of the model -- I just happened to specify > __unicode__ for comments as "Comment #%(id) @ %(time)". > > All good stuff. Thanks! > > Zain --~--~-~--~~~---~--~~ 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: Try out new inline features [GSoC admin-ui]
another more severe problem ... I´m going to stop writing after this one ;-) when adding items with stacked-inlines, every comment automatically gets a value for the order-field. this means, when I´m adding a comment (without entering anything) and click on "save" I´m getting an error. this obviously shouldn´t be the case ... thanks, patrick On 7 Jul., 13:12, patrickk wrote: > more feedback to your inline-solution: > ### if you use a draghandler for stacked-inlines, there should be a > draghandler for tabular-inlines as well (instead of dragging the whole > row). > ### deleting stacked-inlines: not sure if the delete-button should be > displayed with the selectors (near the draghandler). if not, there > should at least be an indication on the left-hand side if (or if not) > something has been marked for deletion. > ### from my point of view, the representation of an original object > with tabuar-inlines is redundant. within the > paragraph can be removed. > > css-stuff: > ### the comma seperated integer field has the class "vTextField". not > nice. > ### why has URLField the class "vURLField" and EmailField has the > class "vTextField". very inconsistent here. > ### IPAddressField again misses the class, the same for filepathfield > and so on ... I´m not going to list everyhing here since you probably > know what I mean. it´s currently very messy (sometimes there is a > class, sometimes not, sometimes the class doesn´t relate to the > field ...). > > ### I´d use a different class for _every_ field. most of the time, it > ´s the same as vTextField, but it makes customization so much easier. > and it´s clean and coherent. > > ### at the change-list, the save-button (if you have forms on the > list) is within the paginator. shouldn´t be there, from my point of > view. > > regards, > patrick > > On 7 Jul., 11:16, Zain Memon wrote: > > > Hey Patrick -- > > > On Tue, Jul 7, 2009 at 1:04 AM, patrickk wrote: > > > > [snip] > > > > there´s a lot more to say here, but I´m not sure if this is somehow > > > related to your work - not sure if you only work on the inline-stuff > > > or the admin-interface overall. > > > Both my GSoC project and future interests lie in improving the overall > > usability of the admin interface, so feel free to pitch away. > > > > besides the index-page, someone should take a look at the html/css. > > > the programming is a mess in certain places (e.g., every input-field > > > on the change-form has a class, but decimalfield and floatfield don > > > ´t). moreover, the naming of the css-classes doesn´t seem to be well > > > thought out. > > > I'll take a look at the decimalfield and floatfield classes. If there are > > other major inconsistencies, let me know and/or file a bug. > > > > something which is related to inlines: currently, with stacked-inlines > > > you´re having "comment #1 ...", "comment #2 ..." and so on on the left- > > > hand side. IMHO, you should display __unicode__ there (I hope you know > > > what I mean). because with 20 comments listed there, one has to click > > > through all items to actually see what´s in there ... > > > one more thing: it currently says "Add a choice" - I´m not sure if > > > this should be "Add a Choice" in order to be translated correctly. > > > It actually *is* the __unicode__ of the model -- I just happened to specify > > __unicode__ for comments as "Comment #%(id) @ %(time)". > > > All good stuff. Thanks! > > > Zain > > --~--~-~--~~~---~--~~ 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: Try out new inline features [GSoC admin-ui]
more notes: currently, the comments with selector-inlines are quite simple (basically, just textfields). does it also work with m2m-fields, rich-text-editors, foreignkeys and so on? I´m especially interested if the re-setting of each field works if you add a comment. regards, patrick On 9 Jul., 00:55, Margie wrote: > Hey Zain, > > Just tried out your new stuff. Very cool! A couple comments: > > ## I agree that a checkbox as a drag handle is confusing - I kept > trying to "check" it and didn't even realize it was a drag handle till > later > > ## I find the numbering that shows up on the comments in your sandbox > site to be confusing. For example, I go to one of the pages and I see > one comment there, it says "Comment: #7". ThenI add a new comment and > it says "Comment: #2". Then after I save my new comment (#2), the > redisplayed page now shows #7 and #9. It seems to me that the number > you are creating when one adds a new comment is just the number of > current comments + 1, and the number you are showing after it's been > saved is it's actual id. I think that either __unicode__ or perhaps > some other thing like that should be used so that the user can specify > a name for it. And for new comments (or whatever object is being > added), there should just be no name, because an arbitrary number > seems confusing. > > ## When I add a comment and then save, if there is an error in my > comment, I have to click through all the selectors to find the one > that has an error. I think there should be an indicator on the > selector that there is an error in the entry. > > Nice work, I like it! > > Margie > > On Jul 6, 2:20 am, Zain Memon wrote: > > > Hi everyone, > > In the last couple of weeks, I've implemented a bunch of inline features. > > > Pictures speak louder than words, so I wrote up a quick blog post describing > > what's done:http://inzain.net/blog/2009/07/new-features-for-inlines/ > > > Also, I set up a server running my Django branch if you want to try them > > out:http://inzain.net:8000/admin/ > > > Play around and let me know what you think -- especially if you run into any > > bugs :) > > > Until next week...ish, > > Zain > > > --- > > My GSoC > > proposal:http://inzain.net/blog/2009/05/django-gsoc-09-admin-ui-improvements/ > > --~--~-~--~~~---~--~~ 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: on type-specific input fields
I'm not so sure "novalidate" is a viable solution. If you have a DecimalField and you enter "xxx" this is what happens ... a) With "novalidate" added to the form: The value is being removed from the field and the form is being saved (tested with Firefox and Safari). b) Without "novalidate": The value is being removed with Safari. There is an error message with Firefox. c) Expected behaviour: The form ist not being saved and I get an error message with the field. Best, Patrick Am Mittwoch, 23. Juli 2014 12:15:12 UTC+2 schrieb Aymeric Augustin: > > “novalidate” would solve the problem as far as the admin is concerned. > > I wasn’t very enthusiastic about switching to the HTML5 input types so > early; now that we have them, I’d rather live with them than remove them, > probably to reintroduce them in a later release. > > -- > Aymeric. > > > > On 23 juil. 2014, at 11:47, Bruno Renié > > wrote: > > > Hi Erik, > > > > I think a more elegant solution than rolling back to TextInput would > > be to promote/document the use of the "novalidate" attribute. In a > > nutshell, '' disables client-side > > validation, letting users submit forms regardless of the client > > validation logic while still taking advantage of the HTML5 input > > types. > > > > Browsers support doesn't seem to be an issue as browsers which don't > > support that attribute (iOS, Android browsers) don't prevent form > > submission at all so they already have a "" behavior. > > > > Cheers, > > Bruno > > > > On Wed, Jul 23, 2014 at 11:34 AM, Erik Romijn > wrote: > >> Hello all, > >> > >> Since Django 1.6, the Django form fields for URLs, numbers and email > addresses make use of widgets that use type-specific input fields in their > HTML rendering. So instead of rendering them as , they > now have type="url", type="number" and type="email". This has upsides: for > example, an email field will cause an iPhone to display the email-optimized > keyboard. > >> > >> However, in #23075[1] sehmaschine raised an important issue: this also > causes browsers to apply their own validation to these fields. This causes > a number of issues: > >> > >> * The validation code used by the browser may not match that used in > Django. For example, URLField will accept "example.com", but Chrome's > validation for type="url" will reject it. Safari on the other hand, does > accept it. So there are two validation steps, which may not be equal, and > which may differ per browser. > >> > >> * Error behaviour of browsers is inconsistent. Chrome renders it's own > unstylable error message. Safari, according to comment 3, will simply > remove invalid values, which is a usability disaster in itself, but > avoidable if the field was type="text" as then the form validation would > detect the invalid value, reject it, and provide a proper error message. > >> > >> * Validation timing becomes inconsistent. In the traditional form > validation flow, the user would submit the form, see any errors, and submit > again. With these fields, some of the validation happens before submit, but > some does not. This can be confusing for users. > >> > >> The workaround is to override the widget in ModelForms or admin forms, > and force it to forms.TextInput(). > >> > >> > >> If we leave the situation as is, developers may unexpectedly find that > their users may get validation errors which are different from all others > in content, style and timing (and possibly language), whose criteria do not > match other validation steps for the same data, and all this will work > differently in different browsers. With the Safari behaviour of simply > ignoring invalid values, mentioned by sehmaschine in the ticket, this > becomes even more serious. > >> > >> Therefore, as much as I like using the correct field types, I think > their issues outweigh the current benefits. I propose that we change all > relevant fields to use forms.TextInput() as their default widget, still > allowing a developer to override this with a specific widget if they do > want to use type="number". Ideally, considering the potential impact, I'd > still like to see this changed in 1.7, although I realise it's very very > late for that. > >> > >> In any case, I thought this might be controversial enough to first > bring it up on this list. > >> > >> cheers, > >> Erik > >> > >> > >> [1] https://code.djangoproject.com/ticket/23075 > >> > >> -- > >> 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-develop...@googlegroups.com . > >> To post to this group, send email to django-d...@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/6E0F05BE-D767-44B
m2m ordering compared with foreign key & edit_inline
this is a proposal in order to add something like "order_by" to m2m- fields. with using an m2m-field, there´s no possibility to enter (or output) something with a different order than the one provided by the related model. with using a foreign key & edit_inline, it IS possible. so, one could say now: why not use FK then? well, first edit_inline is always at the end of the change-form in the admin-interface. that´s ok most of the time, but sometimes it´s just not handy. second, and more important: the m2m-field could already be edited inline. i´ve already answered this question two times in the django-user group, but I didn´t get an answer there. see http://groups.google.com/group/django-users/browse_frm/thread/1b764de78c51c32a/ thanks, patrick --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
