Can each of the different requirements websites be on a different third-level or subdomain? (If your site is foo.com either bar.foo.com, baz.foo.com or foo.com/bar, foo.com/baz_ If so, I would deploy multiple Apache VirtualHosts, each serving an instance of your project. That way the projects can be identical, you have a single codebase to work from, and your different requirements can be handled in each projects settings.py.
Would this work? On Tuesday, August 27, 2013 4:20:29 AM UTC-5, J. C. Leitão wrote: > > Hi. > > I'm using Django in a website and I need to use a given app in the website > more than one time. I know this is kind of tricky to do in Django since > there can be no name collisions. > > *What I'm searching* is more or less equivalent to what stack exchange > network does: a "framework" applied on specific topics. In my case I want > this to be on the same website, for instance for *different topics*, or > *different > languages/communities* (in the sense that the app is translated > differently *and* the users also add content in different > languages/tables that *are not meant* to be translated/shared between > communities). However, like in stack, I want most of the the server-side > code and logic to be preserved (what I here call the framework). > > Notice that each specific instance of the framework must be a Django's app > since it needs specific tables. > > *The problem* I'm already able to implement this, but the way I'm doing > is not easily maintainable. > > *The question:* I'm asking for help and general suggestions on the > approach. Ultimately, I would like to know: is this because I'm having some > bad design choice on web development in general, am I doing a bad design > choice in Django in particular, or is this because Django was not prepared > for this situation? > > Next I explain how I did this, in the bottom I explain the maintainability > issue. > > Implementation > > The idea is: I have a main app for controlling the website and its > authentication (with a MainUser model with a one-to-one to the default > user) and I attach apps. > > The app I want to repeat on the website has a specific name appname(something > that cannot possibly collide with any string), and a specific > user (appname.User), a subclass of main.MainUser. > > What I learn during this whole process: > > One requirement for repeating an app is that every connection of itself to > other app requires a custom related_name, as explained in django docs > be-careful-with-related-name<https://docs.djangoproject.com/en/dev/topics/db/models/#be-careful-with-related-name>. > > In my case, *so far* there is only one connection, the appname.User, that > has a field of the form: > > # this is because a copy of this app would make mainuser.user to clash > mainuser_ptr = models.OneToOneField(MainUser, > related_name="%(app_label)s_%(class)s", parent_link=True) > > The next requirement is avoiding url collisions: I use names for every url > and I prefixed them with appname_. > > The next requirement is static and templates. They are set to be of the > form static/appname/<appname_static> and equivalent to templates. > > Given these requirements, I can repeat the app by doing the following > magic: > > 1. I make a copy of the app's directory. > 2. Change its name to the new app's name, newappname, and every directory > herein from appname to newappname (e.g. static,templates). > 3. For every string in the app's directory, I substitute the appname with > newappname. > 4. I run ./manage.py syncdb (if it was the first time the app was created, > or use south to migrate the tables, since the migrations are already made). > > I can then change templates, static and translations for the new app (in > templates/, static/, locale/ respectively). > > Maintainability > > If I want to implement a new feature in the framework (a feature that is > new to all apps), I have to implement it on one app and then re-deploy it > on every app. That or code the implementation on each app. As you might > understand, this is not efficient: by design this is code difficult to > maintain (e.g. the version control will have lots of changes that are only > due to copy/paste). > > So, bottom line, I have a copy of the same framework with different names. > I made this choice because I needed the same logic with different databases > and static content (static, translations). It seems to me that I'm > searching for an Abstract app, in the same spirit of an Abstract model. > However, I'm not sure this even makes sense, either in Django or in Web > development in general. > > Thank you for your time, > Jorge > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-users. For more options, visit https://groups.google.com/groups/opt_out.
