Sent from my iPad
On 09/06/2010, at 8:33 PM, Simon Meers <drme...@gmail.com> wrote: >> The demo screenshots you provide certainly look good to me; I haven't >> done a full teardown on the patch, but a from a quick glance it >> certainly looks promising. > > Thanks for your response Russ. > >> * Why allow edit links on a readonly field? This seems a little >> redundant to me? > > Because whilst the field on that model might be read-only, the related > object itself is not necessarily. In fact in most cases I've found > that this is the case. OK - makes sense. >> * On the edit link for ForeignKey (localhost:8000 in your example), >> I'd be inclined to stick to just "edit", not "edit <object>" -- that >> seems more consistent with the other edit links you have provided. > > But then if you select a different object, "edit" looks like it refers > to the selected one instead of the original. I could have used > JavaScript here to select the dynamically chosen object, but in the > absence of a popup link this would be pointless -- you choose a > different ForeignKey value, then leave the page to edit it thinking > you've saved the value... Hrm. So this means that if I change the FK from John Smith to Bob Jones, the link continue to be a link to John? While I can see why its implemented like this, it seems less than ideal UI to me. > >> * In the case of raw-id fields and inlines, is there any reason why >> the edit link is separate text, rather than the object name itself >> being the link? (ie., rather than "John smith <edit separately>", why >> not just "<John Smith>"? > > Yes; because you're already editing John smith, but if you want to > edit him separately you can go elsewhere to do so with a (probably > more detailed) dedicated form. I can see your point. I'd be interested to get some input from someone with some UX credentials on this one. >> * Permissions - from my initial inspection, it isn't obvious to me >> that you are honoring (and/or testing that you are honoring) >> permissions. If I don't have permission to edit an object, I shouldn't >> get an edit link. Given the addition in 1.2 of object-level >> permissions, this means permissions need to be per-object. Have I >> missed something in my hasty patch read? > > Correct; no permissions checking is performed at present. In some > places checking would be almost impossible given the current code > architecture, so I had hoped to avoid it if possible. This was one of > the main points I wanted feedback on. I'll respond to this on your follow up email. 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.
