On 25/03/2012, at 4:41 PM, Roy McElmurry IV wrote:
> Okay, I have created a Google Doc of my proposal. I have greatly
> elaborated on the idea. I have enabled commenting for anyone with the
> link. Please take a look and let me know either in this forum or in
> the Google Doc if there is anything I can add or change to make this a
> more appealing proposal.
>
> https://docs.google.com/document/d/1zzqcW-OGHGydmJ-S-OLRVTiAMZMvdrRcGviAzcHdPcM/edit
Thanks for the elaboration. Unfortunately, I'm now even less convinced that
this is an appropriate project for GSoC.
First off -- some comments on the proposal itself.
* Your proposal starts by providing a Database and Model definition. What
purpose does the Database definition serve? Given that database representations
are automatically generated by Django isn't this completely redundant?
* Your proposal provides a simple model as an example -- but by the third
paragraph, that isn't the example you're using to explain your idea... you're
talking about models A, B and J. Why bother introducing the simple model if
you're not going to use it? And if the bulk of your proposal is about models A,
B and J, why don't you present *those* as an example?
* You talk a lot about your proposed solution, but don't ever provide a clear
example of what the solution would look like in practice (i.e., show us an
example of using your proposed API).
However, the bigger problem with this proposal is what I flagged last time --
that I'm not convinced that what you're describing is something that Django
needs. In fact, I'm reasonably certain that what you're proposing:
* is grounded on a fairly fundamental flaw in your data model when taken in
conjunction with your proposed UI, and/or
* is already possible with the existing facilities in Django
Consider the data that's in your database right now. At the time I write,
there's one recipe. One of the ingredients on that recipe is "Butter, 3tsp".
Let's say I add my own recipe. One of the ingredients is 1 tsp of butter. I
type "butter, 1tsp" into my new recipe.
This is the point at which your decision to leave out a clear model example
becomes critical. The best denormalization of this problem (with some
simplified details) would be:
class Recipe(Model):
name = CharField()
class Ingredient(Model):
name = CharField()
class RecipeItem(Model):
recipe = ForeignKey(Recipe)
ingredient = ForeignKey(Ingredient)
quantity = IntegerField()
but the way the UI works, it looks like your data model is more like:
class Recipe(Model):
name = CharField()
class Ingredient(Model):
name = CharField()
quantity = IntegerField()
class RecipeItem(Model):
recipe = ForeignKey(Recipe)
ingredient = ForeignKey(Ingredient)
Now, if I add "butter" to my recipe, ideally the "butter" entry from the
existing recipe would be reused. However, your UI has no way to identify an
existing ingredient, so I can only presume that you're creating a new
ingredient for every type Butter is added to a recipe.
If you're not intending to reuse ingredients between recipes, and the second
model is what you actually mean, then a better data model would be:
class Recipe(Model):
name = CharField()
class Ingredient():
name = CharField()
quantity = IntegerField()
which is something you can generate in Django with a simple InlineFormset.
If the first data model is what you want, then you need a much more
sophisticated widget to select ingredients, because you need to be able to
either:
* select an existing ingredient, or
* create a new ingredient inline.
Even then, this is still something that could be done right now in Django.
Define a ModelForm for RecipeItem, modify the field for ingredient to be
non-required, and add some extra fields and a custom clean method to allow for
the definition new ingredients. Then override the save() method to instantiate
new a ingredient if the ingredient field is not provided but extra detail has
been. On the front end, you will probably need some Javascript to allow for a
clean switch between the "create a new ingredient" and "use an existing
ingredient" mode, but the form should still work without that.
Alternatively, define a ModelForm for RecipeItem; this time, exclude the
ingredient from the form, add the extra fields for the ingredient, and override
the save method to do a get_or_create on the Ingredient instance from the extra
data fields. This will be slightly prone to error, because it relies on users
correctly typing the name of ingredients ("Butter" and "Buter" would be
different ingredients, with no particular feedback that they're actually the
same thing), but it would achieve the same end goal.
Or, you could be using first data model, but you're using the semantics from
the second. Leaving aside for the moment the fact that this isn't a good
denormalization of the problem, it's still possible to do this in Django.
Again, define a ModelForm for RecipeItem; this time, exclude the ingredient
from the form, add the extra fields for the ingredient, and override the save
method to instantiates the Ingredient instance from extra fields (i.e., same as
the last implementation, but always create, not get_or_create).
So - the only way I can see this being a project at all is to wrap up the
"create a child model" as some sort of extension to ModelForm. However:
* I'm not convinced that this is something that Django actually needs -- it
doesn't take much code to do it manually.
* Even if it were, I don't think it's anywhere near 12 weeks work. I'd be
surprised if it took more than a week.
As I said last time, this is one of the risks of picking a project that isn't
on the Django suggested projects list. If you're going to propose your own
project, you need to be pretty certain that what you're proposing isn't already
possible, or is well aligned with the core team's goals.
If you're keen to be a GSoC student for the Django project, I'd strongly
suggest that you take a look at the problems on Django's GSoC wiki. These are
problems that the Django core team have vetted as things that actually need
fixing, and have solutions that have been at discussed.
Yours,
Russ Magee %-)
--
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.
