cleaned_data is just a dictionary. Every time you accept a form in order to do a search, you write code to take the form data from cleaned_data, plus, perhaps, request.user and/or things you can pull from request.user, and build a queryset. That code can clearly be refactored into a separate function.
As far as serializing the function's arguments goes, if the user object is needed, you would instead serialize user.id. The function could easily test whether the user argument is an instance of User, or an int, and optionally perform the query to get the user object. Or the code that re-calls it later could fetch the user object, simplifying the function (a matter of taste, mostly, since an isinstance check is pretty cheap in the context of running a query). On Thu, Apr 29, 2010 at 10:30 AM, derek <gamesb...@gmail.com> wrote: > On Apr 28, 7:45 pm, Peter Landry <plan...@provplan.org> wrote: >> +1 to this. I had similar requirements, and initially went down the road of >> pickling a queryset. It became clear quickly that (at least in my case) a >> better solution was to have a function that translates a Form instance into >> a Queryset. Then serialize the form (or form data) and regenerate the >> Queryset that way. >> >> Peter >> >> On 4/28/10 12:28 PM, "Bill Freeman" <ke1g...@gmail.com> wrote: >> >> >> >> > The request may have references to objects that will no longer >> > exist, or may be inappropriate when rerun later. I can't promise >> > that it won't work, but I believe that pickling the request is at >> > best a fragile solution. >> >> > To save just the required parameters won't take much code, >> > especially if you refactor the code that turns the parameters into >> > a the search operation into a function (or method) that you can >> > use both initially and when you rerun the search. >> >> > Having to do some preparation again probably isn't going to be >> > as big a performance drain as unpickling enough context to >> > make it work without extra code. >> >> > On Wed, Apr 28, 2010 at 11:56 AM, Mark Jones <mark0...@gmail.com> wrote: >> >> I was thinking I could pickle/unpickle the request then run it thru >> >> with an extra flag of (send email) thru the same code that wsgi uses. >> >> If I jsonify the data, how would I get that back into a python object? >> >> >> Is it really as simple as str=json.dumps(request) and request = >> >> json.loads(str) >> >> >> I don't see how json keeps track of the object it is dumping, and not >> >> sure how to construct a request object from the json return value. >> >> >> I can see how easy that part would be in C++, but my python skills are >> >> a good deal weaker.... I guess I'm hunting for "how to do this in >> >> python" >> > > Peter > > This sounds intriguing: "a function that translates a Form instance > into a Queryset". Is this a generic solution? Even if not, would you > mind sharing the code here? > > Thanks! > Derek > > -- > 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. > > -- 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.
