Russ,
Thanks so much for the thorough response and explanation.
As you can probably tell, I am a bit new to Django. :) You're right,
I have been interpreting django as "some monolithic block that needs
to be installed." Your insight certainly grants me a whole new
perspective and gives me a lo
On Thu, Feb 5, 2009 at 8:39 AM, bbeaudreault 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 han
Sorry to spam, but in re-reading my post I realized that I assumed
people know what I mean by "Shared Code."
Basically I would have one main code-base that will contain code that
all clients inherit from.
By default a client would just be running straight off that "shared"
code-base, so 2 new cl
Note: I could just make one big app, and deploy it separately for all
my clients. But I want to be able to easily roll out big changes to
all my clients, without having to replicate code a manually across
them. That's why a Shared -> Client inheritance handler type of thing
would work perfectly
Ok, yea. Sorry for the title, it is hard to generalize this question
enough to be short like that.
Anyway, at the company I work at we use mod_perl, and we have
clients. Our code-base is set up like this:
Shared Code -> Client Code
The client code inherits and overrides shared code. So if in
5 matches
Mail list logo
