If your changes are limited to templates, there is an easy standard approach:
Set TEMPLATE_DIRS to something reasonable.
Include the file system template loader in TEMPLATE_LOADERS
*before* the app loader. (This is probably already true.)
Copy the templates you need to change to the same sub path of your
templates directory as they were to the app's templates directory, and
edit your copy. E.g.; if the foo app calls out a template as
"foo/bar.html", and the original is in
".../site-packages/foo/templates/foo/bar.html", and you put your
version in ".../templates/foo/bar.html", your version will be found
first, and thus will be the one used.
If you need to fiddle a view, you need to recreate the view (or, if
applicable, create a function that calls the view and massages the
arguments and/or the results) in a module of your own that is
available from sys.path, e.g.; ".../my_utils/extra_views.py", and fix
urls.py to call it instead. You can do this even if you are
"include()"ing the apps urls module from your urls, since you can put
an expression that matches a specific on or the app's sub paths before
the include, and the other sub paths will still be handled by the
app's urls.
Fancier changes usually lead to cloning the app into your project
directory and putting it under your revision control system, rather
than in requirements.txt (or equivalent). (Your project directory
needs to be, and typically will be, earlier on sys.path than
site-packages or (yuck) dist-packages.)
Installing upgrades to other packages CAN (but usually doesn't) break
any of these approaches, requiring you to track down the interaction
and edit your copy.
On Thu, Oct 4, 2012 at 5:53 AM, Xun Yang <[email protected]> wrote:
> Quite often I have to make small changes to the original code when I'm using
> default/3rd part apps. Take an example of setting constrains for password,
> the default SetPasswordForm in django.contrib.auth.forms and
> RegistrationForm in django-registration don't have any. So I have to
> subclass them and add in the checks. So is there a best practice of where to
> place these subclasses? As in one project I may need to define many
> subclasses from various default/3rd part apps, should I create a utility app
> and put all of them there? (From the past experience I'm a bit concerned
> about this, as it could be a source of pain when I moved stuff from test to
> WSGI/apache)
>
> Thanks for the help!
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-users/-/IOBUs2rA9UoJ.
> 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-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 [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-users?hl=en.
