Jacob,
Thanks for your feedback.
> Though I see what you're trying to solve here, I can't quite see how
> this actually improves anything. That is, what's the difference
> between your proposed::
>
> objs = deserialize("xml", stream, map=some_function)
>
> and the possible-right-now::
>
> objs = map(some_function, deserialize("xml", stream))
>
> ?
Well, the difference depends on exactly where the call to the user-
defined function gets made. I agree that if it accepts an already-
created DeserializedObject (which is what I proposed, but I could see
changing) and its return value is the value that's returned by the
deserializers next() method, then those two calls are exactly
equivalent. (In fact, besides the fact that I couldn't think of a
better name, that's basically why I called the parameter "map.") So,
perhaps this simplest-case implementation doesn't really buy much and
isn't worth doing.
But if, on the other hand, the function is called earlier, accepts
some other argument and returns some other value, it becomes more
useful. For example, it could perhaps accept the "data" dictionary
that currently gets passed directly to the relevant model constructor
inside the DeserializedObject constructor, and return a similar
dictionary which will be passed to the model constructor instead. In
this case, the user-defined function has the opportunity to affect the
way DeserializedObjects are created. This is useful, for example, if
you are deserializing data from a foreign Django installation with
models which are similar to your own but may have slightly different
fields:
===================================
# The 'foreign' Title model just stores author information in
CharFields:
class Title(models.Model):
# ...
author_last_name = models.CharField(...)
author_first_name = models.CharField(...)
# The 'local' Title model stores author information in a separate
Author model/table
class Title(models.Model):
# ...
author = ForeignKey(Author)
# This user-defined function passed to deserialize() can translate
between these
# different representations of the same data
def convert_authors(data_dict):
"Converts foreign-style author fields to a local Author object"
if data_dict.has_key('author_last_name') or
data_dict.has_key('author_first_name'):
lname = data_dict.pop('author_last_name', '')
fname = data_dict.pop('author_first_name', '')
new_author = Author(first_name=fname, last_name=lname)
new_author.save()
data_dict['author'] = new_author
return data_dict
===================================
In this implementation, the call:
serializers.deserialize('xml', stream, map=convert_authors)
does something that couldn't be achieved outside the call to
deserialize(). Without the convert_authors function, the call to
deserialize() will fail with a TypeError, because the local Title
model has no fields named 'author_first_name' or 'author_last_name'.
As things are now, to correct the problem I either have to manually
edit the data or write my own custom deserializer. Inserting the call
to the convert_authors function just before the DeserializedObject
constructor avoids this error and allows the problem to be corrected
at the point where it's most efficient to do so.
This may or may not be the best place to make the call to the user-
defined function, or the best conception of its arguments and return
value. But the point remains that, depending on where during the
deserialization process it is called, it can do some work that might
otherwise be impossible or highly inconvenient to do. There might
even be a case for having multiple calls to user-defined functions:
e.g., to one that does preparation before deserialization even begins,
one that handles errors during parsing, one that checks that the
deserialized data is locally valid, etc. (This would be getting way
more complicated than I feel is necessary or useful, but maybe someone
else wants to make that argument.)
Hopefully, that makes things a little clearer.
Richard
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected]
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
-~----------~----~----~----~------~----~------~--~---
