Hi Kirby. Interesting idea. I'm not familiar with subdomains, but I will definitely try this.
Thanks for the help, Jorge On Tuesday, August 27, 2013 4:12:47 PM UTC+2, C. Kirby wrote: > > 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.
