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 -~----------~----~----~----~------~----~------~--~---
