#14969: To have a way to modify third part model classes
---------------------------------------------------+------------------------
Reporter: marinho | Owner: nobody
Status: reopened | Milestone:
Component: Database layer (models, ORM) | Version: SVN
Resolution: | Keywords:
Stage: Unreviewed | Has_patch: 0
Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 0 |
---------------------------------------------------+------------------------
Changes (by marinho):
* status: closed => reopened
* resolution: wontfix =>
Comment:
Replying to [comment:2 russellm]:
Russel, I disagree to you. It would be a monkey patch if it was just a
work around to fix something and just that.
'''I reopen the ticket just to ask for your attention, but I will give up
if you close it again.'''
So, my code is more to an implementation of pattern '''Helper Classes'''
than to a monkey patch.
Let's think on '''django-tagging''', just for illustration. It is a good
application, but let's consider that for a specific project I'd like to
add a new field for model class '''Tag''': "icon" (an ImageField).
Well, with actual state, I should to do one of the following:
1. ask the author to add the field (of course would be insane to ask him
to add a field just because I need for a specific project);
2. fork it as my own '''my-project-django-tagging''' and modify it. Well,
this would be the opposite of "'''DRY'''";
But let's consider that the app's author made your "right" way, so I would
use something like the setting AUTH_PROFILE_MODULE, so, let's name it
"TAGGING_TAG_PROFILE" to add a field.
Well, this could happen with any model class of any application (contribs,
pluggable, public, privates, etc.), so to implement the "right" way as you
said, would be to have a setting for each model class, so, IMO would be
practically impossible or a totally mess.
But, let's consider I would create a model class '''"TagProfile"''' and
attach to that setting, so I would have a new model class with one field.
So every code I write using tags I have to use a
"my_tag.get_profile().icon" so we have the double of database requests for
just one field.
Another consequence is that I have two Admin modules: one for tagging.Tag
and another one for my TagProfile (I could change
'''admin.site._registry[Tag]''' but would be a classic monkey patch).
And we must consider many times would be complicated to write
aggregations, to use tag clouds, or even to use the applications features
and going on...
So, my ticket is about to implement a way to make single changes on third
part (or contrib) applications without to make hard code.
Actually, '''IMO''', User profiles never was a great solution, because it
makes me to do the double of database requests and to have two places in
Admin for the same reason, sometimes just to have a field like "website",
so this is not really smart, actually users never understand why to change
"website" is different to change "email". I use it because is a better way
than inherit or make my own, but not really happy :)
--
Ticket URL: <http://code.djangoproject.com/ticket/14969#comment:3>
Django <http://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en.
