Re: Implementation and maintainability of an app deployed multiple times in the same website

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. 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+unsubscribe@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.