I have a design approach I've been kicking around and thought the group might have some opinions on the subject.
Here's the scenario. You're on a web page and you're filling in data for a new Widget to add to your inventory. In the middle of the form you see that you need to create a new Type for this Widget. You click on the 'Add Type' link/button and one of the following happens, depending on the design of the application: 1. An AJAXy div pops up, you fill in the Type information, click save, and the new Type is selected on your form. 2. You leave your Create Widget page, go to the Create Type page, enter the data, click save, and you are returned to the Create Widget page with new Type selected on your form. The first scenario is straight-forward, whiz-bangy, and doesn't work without javascript. It's definitely an option, but not what I want to discuss. The second scenario is what I'm curious about. The problem to solve in that scenario is where does the Create Widget form data get stored while you're off creating a Type? You can put it in the session, or you can put it in private data on the Create Type form. Once the Type is created or canceled, you need to redirect back to the Create Widget form with the form data, with the data possibly modified to indicate the new Type is selected. The solution I tried with this was to create a closure at the jumping off point, that is when the user decides they need to go off and create a new Type. The closure contains the form data and, when executed, returns a response rendering the Create Widget page. This allows me to write my Create Type view with very little knowledge about how it was called. In it, after a post or cancel, I check to see if there is a closure (callback) available (red flag here, discussed below), and execute it with the current request and the selected type, if available. I like the way this works, but there's certainly nothing novel about the approach. Paul Graham describes this approach in how they did things at ViaWeb way back in the day, which was my inspiration for trying this. The aforementioned red flag (as pointed out to me by an expert Python user I'm working with) is that the closure/callback is not serializable, and thus the approach falls apart when you start load balancing your application (I store the closures in a stack for each session key as a 'global' variable). I really like the intent of the approach, in that a view doesn't have to know how it's being used, it can simply forward off to whatever might be in the stack, or take it's own action if nothing is there. But how do you get around the serialization problem? Or can you? Or do you end up hacking it up so much that there's a better way to do it, like just storing the form data and a function name in a 'stack' on the user session? Long winded, dry, and quite possibly moot and uninteresting. But hey, I thought I'd throw it out there... If you have any thoughts on the subject or are willing to share how you approached this (common?) problem I'd be happy to read them! doug. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~----------~----~----~----~------~----~------~--~---
