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 django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. For more options, visit https://groups.google.com/groups/opt_out.
