On Thu, Feb 5, 2009 at 8:39 AM, bbeaudreault <compbr...@gmail.com> wrote: > > Sorry to spam, but in re-reading my post I realized that I assumed > people know what I mean by "Shared Code."
That's not the unclear bit. The unclear bit is your terminology and how your are interpreting it. What, exactly, is a "Django handler"? For that matter, what is a "Django instance"? Neither of these terms make much sense in a Django context. The general problem you are describing is fairly clear though. You have a basic library of code. Some customers will be using that code verbatim, in various configurations. Different customers will be using slightly modified configurations; some customers will require customized versions of various components. You want to make sure that if a common component is updated, all users get the benefits. To answer this question, you need to get comfortable with the idea that Django is just a Python library, and your Django _applications_ are just Python libraries that use the Django library. When you deploy a Django _project_, it's just a configuration of a number of Django _applications_. Although the Django tutorial deploys applications as subdirectories of the project, there is no requirement that you follow this directory structure - Django applications can be installed as part of the Python site-packages, or in some other local store. All you need to ensure is that PYTHONPATH is configured to find those pacakges. In this way, you isolate your common code as reusable applications, and just include those common applications into any project that requires them. If a specific customer requires customizations, then you write a customized application, or you put customization hooks into the base project and exploit those hooks in the customized project. Ideally, you won't need to fork or duplicate any code - you just exploit interfaces that exist in the base application. Exactly how to manage customizations of this sort is the subject for a master course, not an email on a mailing list. If you want to see how it can be done by example, I would suggest looking into the reusable applications that form the Pinax project. Pinax is growing a good body of 'best practices' for extensible, reusable applications. Hopefully, these best practices will be clearly documented so that everyone can follow the same conventions. Once you have your reusable applications, in various project configurations, your web server can then deploy multiple Django projects, each independent of the other. You can have multiple deployments of the same project within a given web server, and/or you can deploy multiple different projects and configurations. At the end of the day, it all comes down to being comfortable with the tools you are using, and not thinking of Django as some monolithic block that needs to be installed. It's a library, like any other Python library. Good reusable Django applications are just Python libraries too, albeit libraries with a Django dependency. Write small pieces of glue code that configure those libraries, and deploy as required. Yours, Russ Magee %-) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
