> 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. > * 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... > * I take it that the widget edit links carry through to inlines? > i.e., if i have a foreign key pulldown in an inline, I will get the > edit link? Yes. > * How does performance degrade when JavaScript is not available? Do > the links exist at all, or do they become dangling links to the wrong > object? Solid as a rock; does not use JavaScript. > * 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. > * 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. Simon -- 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.
