Hi ke1g! Thanks a lot for the explanation! I'm currently using both the second and third approach for the problem, a utility app for a few things and embedding "registration" app in my project (Seeing it hasn't updated for years, I suppose it's safe to have it here and modify as I want). At certain point I may need to break utility app into new apps as the project goes. I'm also getting curious about the "requirements.txt" you talked about, seems like I need some good knowledge about version control.
I hope the Django community has a plan of moving the support group out of Google Groups, which feels like a last century product and is hard to both keep track and read... On Friday, October 5, 2012 10:25:27 PM UTC+2, ke1g wrote: > > 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] <javascript:>> > 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]<javascript:>. > > > To unsubscribe from this group, send email to > > [email protected] <javascript:>. > > 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 view this discussion on the web visit https://groups.google.com/d/msg/django-users/-/mR0mzEPyGeMJ. 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.
