StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
10889806
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
0
CommunityOwnedDate
CreationDate
2012-06-04T23:37:06.627
FavoriteCount
0
LastActivityDate
2012-06-04T23:37:06.627
LastEditDate
LastEditorUserId
0
OwnerUserId
190823
ParentId
7514659
PostTypeId
2
Score
0
ViewCount
0
LastEditorDisplayName
text
Body
It looks like you want to replicate features of other popular languages and frameworks in Django. Reading your post OSGi springs to mind. The problem is that 99,9% of all Django applications are not "dynamic" in the sense that apps can be installed, loaded, unloaded and uninstalled at runtime. That's not how Django applications work. You install an app before the application is started. To uninstall an app you shutdown your application and remove it from the <code>INSTALLED_APPS</code> (settings.py) list. Since this does not happen at runtime there won't be any signals, callbacks or other things to the Django application. But there are certain things you can do to at least meet some of your needs. From the top of my head I think you could do something like a <code>before_install</code> and <code>after_install</code> "signal" (not in the Django signal sense). To do so you could write some sort of "controller" or "registry" app. One for the <code>before_install</code> and one for <code>after_install</code> code. Those apps would sit before and after the rest of your apps in <code>INSTALLED_APPS</code>. e.g. <pre><code>INSTALLED_APPS = ( # all the Django apps and other third party apps 'before_install_controller_app', # all your in-house apps 'after_install_controller_app', ) </code></pre> These two apps iterate all the apps listed under <code>INSTALLED_APPS</code>. They try to import a specific python file from each of the apps. If the file is not in the app (because it's a Django or third-party app) nothing happens. But if there is a file, let's call it <code>before_install.py</code> and <code>after_install.py</code> it is loaded and the code inside is run. The same would apply for the <code>after_install_controller_app</code> app, but it would look for <code>after_install.py</code>. It's basically the same mechanism Django uses for it's admin. The admin app iterates all the apps and tries to import <code>admin.py</code>. That's why you should at first have a look at the corresponding <a href="http://code.djangoproject.com/svn/django/trunk/django/contrib/admin/__init__.py" rel="nofollow">Django source</a>. It's pretty straight forward and easy to understand. I did something similar and it worked like a charm. There are of course some limitations. For instance: <ul> <li>The before_install.py code would not have access to database models of the underlying app because they may be a) not have been created yet (see order of the apps) or b) out of date.</li> <li>I am sure there are many more, but at the moment I don't find any more.</li> </ul> On last thing: Don't try to hard to map/port features/paradigms of one programming language/frameworks to another. There might be fundamental differences that render good approaches in one language/framework useless in another. That certainly seems the case here. If you have further questions I'd be glad to help if I can.
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POHow to create Django Apps with life cycle?
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. This table or related slice is empty.
UserOwnerUserId
1. USJens
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. This table or related slice is empty.
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. This table or related slice is empty.
CommentsPostId
1. This table or related slice is empty.

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.