On 12 Dez., 13:29, Russell Keith-Magee <russ...@keith-magee.com>
wrote:
> On Sun, Dec 12, 2010 at 6:04 PM, patrickk <patr...@vonautomatisch.at> wrote:
>
> > On Dec 12, 12:50 am, Russell Keith-Magee <russ...@keith-magee.com>
> > wrote:
> >> On Sat, Dec 11, 2010 at 11:28 PM, patrickk <patr...@vonautomatisch.at>
> >> 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.
fair enough. let me clarify and add some additional information.
first, we add the can_order attribute to InlineModelAdmin (2 lines of
code in django.contrib.admin.options.py).
as a default, can_order=False, but when I add the attribute to my
admin-definition I´m able to change that (ok, that´s another 2 lines
in options.py):
class MyInline(admin.TabularInline):
model = MyInlineModel
extra = 2
can_order = True
now we´re having an additional input-field (ORDER).
based on the value of this field, I can now loop through my inline-
forms:
class MyModel(admin.ModelAdmin):
...
def save_formset(self, request, form, formset, change):
if formset.can_order:
for inlineform in formset.ordered_forms:
# do whatever
# e.g. set the value of my position-field
formset.save_m2m()
if we now add the formsetsort-filter, one can easily add drag/drop –
one just needs to re-index the values of the ORDER-field on submit.
I currently won´t care too much about hiding the ORDER-field or adding
the necessary javascript for drag/drop-support.
regards,
patrick
>
> 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 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.
