On Sun, Dec 12, 2010 at 6:04 PM, patrickk <[email protected]> wrote: > > > On Dec 12, 12:50 am, Russell Keith-Magee <[email protected]> > wrote: >> On Sat, Dec 11, 2010 at 11:28 PM, patrickk <[email protected]> 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. >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 [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.
