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 <[email protected]> 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 <td class="original"> 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 <[email protected]> wrote: > > > Hey Patrick -- > > > On Tue, Jul 7, 2009 at 1:04 AM, patrickk <[email protected]> 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 [email protected] 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 -~----------~----~----~----~------~----~------~--~---
