Plugin models...

[jens]

Some plugins needs his own models!

Started with the new dynamic sub menu i needed a way to store some stuff for the sorting. I used the plugin preferences for this and put a dictionary as a preference item. For this small data, it's ok...

With the new flv player i have the same problem. I need a way to store meta data for _every_ existing flv file. This can be mutch more data, than a small dict.

If someone would like to create a Blog, Forum or Image Gallery Plugin, he will have also the need to store data. These plugins needs his own models.

The only existing way is, to add a Plugin as a django app in settings.INSTALLED_APPS. I made this in a PyRM proof of concept and it works. After a syncdb, the model tables created and the plugin can use this own database tables.

The bad thing with settings.INSTALLED_APPS: It hasn't been related to the PyLucid plugin administator. If the user "uninstall" a plugin, the plugin models would not removes from the database.
The good thing is: It's existing. Nothing to implement

Other Ideas:

1. Could we easy implement a "register" mechanism to the existing model stuff? And would these models works equal to normal django models?
Explain: In the plugin config class we add something like e.g. models.register("MyModels")...

2. Can the existing PyLucid models package import all plugin models?

3. Can we use MonkeyPatching here? (But i thing this is not the best way)

Any comments?

EDIT: For geman guys, i created a cross post here: http://www.python-forum.de/topic-14848.html (de)

EDIT2: Hm. Did i think too complicated? Could we create a models class somewhere and use it, if the related tables exists?
_________________

http://www.jensdiemer.de | http://www.htfx.de | http://www.python-forum.de

[rantaaho]

Currently, auth "plugin" has it's own model for passwords. So, I have been thinking these same things when I was planning how to make authentication more "plugin-like".

There seems to be two contradictory requirements, need for new django apps with their own models and on the other side one should be able to install and use PyLucid without shell access.

Modifying settings.py with PyLucid plugin administator is IMHO a bad idea from security point of view.

Could one solution be: Split PyLucid to two django apps 1) PyLucid 2) Plugins. The first one would contain only basic and all Plugins would go to the second "app". Then each plugin (Plugins/Foo/, Plugins/Bar/ etc.) would provide it's own models and views. And in Plugins/models we would do some magic to import them all? This is close to your idea #2, but IMHO little bit cleaner since PyLucid/models would not be affected.

The good thing with this would be that all plugins would also be close to normal django apps, they would just in addition to normal stuff have the PyLucid Plugin API to play with.

In my opinion #1 is too complicated, #3 a bad idea and EDIT2 maybe simpler to implement but conceptually more complicate as it is braking typical djando behaviour.

[jens]

[jens]

Great!

I made a test and it seems to work:
1. I insert a test model into a existing model file (e.g. ./models/Style.py).
2. run syncdb in the install section created the table
3. move the model class from Style.py into a plugin
4. try to play with the model

EDIT: The question now is, can i get the CREATE TABLE statement from a seperated model class? I look at this now...

EDIT2: Greater! It's all very easy! We must only import the plugin models and after this it's "appends" to the PyLucid app. So syncdb would create the tables for us.
Installing a plugin can work like this: After the current routine installed the plugin into the database, we must import the plugin or the model file and run syncdb. Thats all...

OK. The question is no more, if it will work

EDIT3: Here you can see, syncdb will recognizes the models:
http://trac.pylucid.net/browser/trunk/dev_scripts/local_tests/models_test.py?rev=1606
_________________

http://www.jensdiemer.de | http://www.htfx.de | http://www.python-forum.de

[jens]

It's a little bit tricky

There is no problem to get the CREATE TABLE statements:

[jens]

Manipulating INSTALLED_APPS at runtime works:

http://trac.pylucid.net/changeset/1607

I add a fake django app "PyLucid.system.PyLucidPlugins" and add register models at runtime to this app. After getting DROP TABLES statements, i delete the added models from the app cache...

Now i have a second idea. You wrote about adding a second plugin... We can add the fake django app "PyLucid.system.PyLucidPlugins" permanently?
We only use django.db.models.loading.register_models to add the plugin models and del(django.db.models.loading.cache.app_models["PyLucidPlugins"]) to remove the models...
We should test if we can do that in a threaded environment? On the other side, we only need this hack for getting the delete table statements...
_________________

http://www.jensdiemer.de | http://www.htfx.de | http://www.python-forum.de

[jens]

OK. It works. I added a faked plugin permanetly.

But there is a problem with unittest:

I tried to init the plugin and the models in setUP and remove them in tearDown. Than i get something like this:

[jens]

The two errors was a concept failure by me. I made two errors
1. The app_label of a plugin model must be 'PyLucidPlugins' and not "PyLucid"!
2. The test plugin would be copied to plugins_internal instead to plugins_external so this plugin would be auto installed with all other plugins and goes into the fixtures.

With http://trac.pylucid.net/changeset/1612 everything around the new "plugin models" should be run fine! I have updated the unittest for this and test many cases.

With these changes from the last days, we get a very cool features in the PyLucid plugin systems.

Everything looks great, isn't it?

So now we must create docu about all this stuff

EDIT: Add a smal Docu about this: http://www.pylucid.org/_goto/163/plugin-models/

EDIT2: A other simple example for plugin models: The new page counter: http://trac.pylucid.net/changeset/1613
_________________

http://www.jensdiemer.de | http://www.htfx.de | http://www.python-forum.de