Baurzhan If you are serious about doing this, you may want to look at what has been "invented" elsewhere. The one example I know of (and have used) is Apache Cocoon's flow model: http://cocoon.apache.org/2.1/userdocs/flow/continuations.html
Worth reading around ideas/concepts. Derek On Dec 14, 11:04 pm, Baurzhan Ismagulov <i...@radix50.net> wrote: > On Mon, Dec 14, 2009 at 12:17:31PM -0800, Almost George wrote: > > An Attendee, being added to an Event, must already exist in the > > system. If the given Attendee doesn't exist, the user should be > > prompted to create it/them (validly) before continuing further. > > > Likewise when selecting the Event Venue - if it doesn't exist, it must > > be created. > > > Of particular note, Venues have some required meta-information that > > must be filled out before it can be considered valid. > > > That's quite a bit of "add and/or create+validate", and I'm not sure > > how to implement that. I'm assuming I'll be using the Form Wizards, > > but at this point I'm just not sure where to start. > > This is implemented in admin using popups, your easiest way would be to > copy / reuse that. > > I'll have to work on a solution without popups in order to have: > > 1. A single browser window, to avoid user confusion if you have nested > ForeignKeys (admin opens a popup for each). > > 2. Pagination / filtering, since admin's <select> controls don't scale > if you have anything more than a dozen of Attendees. > > I've looked into form wizards for that, but I don't think they are > flexible enough. First, if you already have an Attendee, I couldn't find > a way to skip that form. Second, the state is held in the POST requests. > The advantage is that a user may open several browser windows and use > different forms with complex workflows. The disadvantage is POST -- if > you want POST-redirect-GET to avoid some of the issues with back / > refresh (I'm using 1.0; you might want to look > athttp://code.djangoproject.com/ticket/9200). > > So, ATM I think we need a "workflow engine", which would display forms > with PRG and hold intermediate data and "return stack" in sessions. I've > scribbled together a couple of lines (not general, and nothing working > yet); the problem with my design is, it will always have its > limitations. For instance, if the user opens two browser windows and > would add two new Events, continuing in another window at an > "unfavorable" moment may result in a mess, although one may always > customize that for one's needs. Another hurdle was pickling the form > data into the session; I've skimmed through #9200 for that, but couldn't > find how it does that yet. > > If anyone has code or ideas, I'd like to hear about that, too. > > With kind regards, > -- > Baurzhan Ismagulovhttp://www.kz-easy.com/ -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
