Hey All, First off, I am a relatively new Django user, and certainly not a developer at this point, and most of this post is pure speculation. With that disclaimer, I'll share my situation and opinion:
>From DoctorMO: > Well I've seen far more normalised models that don't match how simple > data entry people's minds expect the forms to be presented. Binding > them back together using in-lines is one method of having a complex > set of models editable as one entry form. This is exactly the problem that I am running into right at the moment. My data entry people will pitch a fit if I make them use the current setup, which would require at least two levels for my site, with very awkward transitions (save this object, go add a related object, search for the first object using a raw id lookup, then finally edit the related inlines). This is painful. But... >From Adrian: > This has come up a number of times over the years, and I still haven't > wrapped my head around why somebody would need this functionality... > Surely one could just use the "standard" admin for the third-level > objects, then use two-level inlines for the first- and second-level > objects? I started writing a long email about why I want this functionality, then changed my mind. Adrian's 'just use the standard admin' response would get me *very* close to what I want, with just a few enhancements. Here's how: I just watched to 'I want a pony' session from DjangoCon, and I noticed two points that fit this discussion: 1. Raw ids are 'too raw'. Let's do some sort of search/select instead of a drop down. 2. Databrowse is cool, but outdated. Databrowse integrated into Admin would kick ass. I'll add one more: 3. With the Admin refactor, it should be easy to create *both* an inline *and* a stand-alone admin object for the same model, and register both. I'm assuming you have a layout something like this (a simplified look at my database layout): A <-- B <-- [X, Y, Z] A is your main table, B has a few entries for each A, and X, Y and Z all point B. I *think* this will generalize pretty nicely, but I haven't thought my way through any really complicated relations yet. --- My proposal is this. The cool thing databrowse does is link between related objects. To get databrowse-like functionality with only a little work, do this: 1. Implement an option to search/select in place of raw ids or drop- down/select on the stand-alone admin. While I'm not much of a UI guy, it seems to me that I can already have most of the search functionality I need set up in the Admin site for my related object. So, keep the raw id idea, but display a string representation of the object instead of its id? 2. Create an Admin object for A, and inline B. Also create a stand- alone Admin object for B, and inline X, Y and Z. 3. If both inline and stand-alone Admin objects are registered for B, add links from one to the other. Text links would be fine, or a small go-to-this-object-arrow icon. 3a. If you don't register both admin objects, the link could instead go to a typical databrowse page to let you look at the related object, and what objects are related to it. This is not critical for this discussion, but it does seem to be an easy way to start integrating databrowse functionality into the admin. --- Now my workflow looks like this: Add an A, and add a B inline, save. Now link to my newly created B, and edit X, Y and Z objects inline, and save. And if I'm creating a B in the stand-alone admin, I can easily search for my related A, then navigate to that related object by clicking a link. This is the visual equivalent of the way that Django's query API works. This would mean I could train my users to save the first object, then follow a link. That's a pretty easy thing to do, and it is significantly less painful than the first workflow I described using the current admin setup. How hard would this actually be to accomplish? Are there any glaring errors in my thinking? Complex relationships that hose the whole idea? James --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
