#71 Create some kind of "component" architecture for TG2

[Michael J. Pedersen]

Django has mini apps inside of a "project" so your website could be made up of a blog-app, a wiki app, a forum app, etc. And it has some helpers to make this nice, automtic discovery of models, etc.

Basically this is implemented as apps directories inside your django project, which you configure URL's to and they dispatch from there. Apps contain controllers, templates, and models. User modification of the apps is then easy because they are just code in your project. But syncing up to a newer version of the blog-app is difficult.

In TG2 this could be accomplished by creating a components directory, putting components in there, and having the init on the controller of a component will register the models in the app (and can take setup parameters). So if you mount a blog component in 4 different places it can be configured 4 different ways by passing in different defaults when you instantiate the component's root controller object...

---

01/12/08 10:02:43 changed by mramm

At CodeMash? there was quite a bit of discussion on this topic:

Django user contributed apps are one of the main reasons people use django (another is the django admin).

TurboGears has most of the infrastructure to make this as easy as it is in django, but there have been some reservations about doing it, and we definitely have not created project and social structures to encourage the development of reusable application components.

One thing people have been concerned about is copying these components into the project directory. This is definitely the easy way to do it, and it is the way Django works. But there are potential issues because your project becomes totally divorced from upstream fixes to the app...

We could do some kind of 3-way-merge thing to help this out. Either using code from mercurial, or mercurial itself.
Delete 02/08/08 15:08:42 changed by khorn

The "obvious" way to accomplish something like this, to me, would be to leverage setuptools (which is likely installed on most machines running TG anyway).

Couldn't we establish a "tg2app" entry point, and then have a loadTGApp() function.

So you would ideally have something like:

RootController?():

blog = loadTGApp('blog_app') wiki = loadTGApp('wiki_app')

the loadTGApp() function (or class or whatever) would search the setuptools entrypoint for apps registering that name, and then load them.

I'm sure it sounds easier than it will end up being, but I think this would be a nice way to handle the "multiple app" problem.

Also, in your "main" app, you could just require the 'blog_app', 'wiki_app', etc. packages and let setuptools get the latest ones for you.
Delete 02/27/08 10:55:01 changed by mramm

milestone changed from 2.0 to 2.0-preview-2.

Delete 04/19/08 09:40:03 changed by mramm

milestone changed from 2.0-preview-2 to 2.0.

Delete 05/25/08 16:53:36 changed by plewis

owner changed from anonymous to plewis.
status changed from new to assigned.

Delete 05/27/08 03:56:57 changed by plewis

Added a requirements document:

http://docs.turbogears.org/2.0/RoughDocs/SiteComponentRequirements

and a discussion about the requirements:

http://groups.google.com/group/turbogears-trunk/browse_frm/thread/d0eed805e8eac514
Delete 06/19/08 22:48:40 changed by mramm

milestone changed from 2.0 to 2.0-preview-2.

We should evaluate silverplate as a potential start on this problem.

Also, we should break this down into some smaller steps if possible.
Delete 07/06/08 20:49:57 changed by mramm

milestone changed from 2.0-preview-2 to 2.0.

Delete 12/12/08 15:36:33 changed by jorge.vargas

I totally agree with the "load TG app" approach. I think the "django way" of having a "installed apps" config variable is the way to go, then handle everything else to setuptools.
Delete 01/11/09 00:40:38 changed by jorge.vargas

milestone changed from 2.0 to 2.1.

as per today's discussion this has been set as a 2.1 goal.
Delete 01/23/09 22:05:26 changed by lmacken

cc set to lmacken.

Delete 02/02/09 23:40:35 changed by lszyba1

So how will tg-registration look in this scenario...what tg-registration did was to put its code under one of the folders. User then changed configuration files and we were ready to go. Rum has a nice entry points, where you load the app, add one configuration file and it takes over the master template look. I think the biggest problem for me at this point is how to create an application that can be loaded by another tgapp? I think simple tutorial on how to create tg2 app that can be called by another tg2app,and get its master template, db connection, authentication. Thanks, Lucas
Delete 02/03/09 20:50:43 changed by jorge.vargas

@Lucas, the case of tg.registration will probably be fixed in a similar way as how tgext.admin/catwalk2 work. it will piggyback on your master.html and simply provide a controller you can mount.

I think the real blocker here is when a component demands config values and/or db storage/access, because we'll have to develop some tool to handle this.
Delete 02/15/09 08:15:04 changed by jorge.vargas

summary changed from Create some kind of "component" archetecture for TG2 to Create some kind of "component" architecture for TG2.

architecture
Delete 02/24/09 00:55:35 changed by jorge.vargas

Adding two more items to the laundry list.

How to handle multiple tables/objects form different components
How to handle multiple BaseControllers?
How to handle "merged controllers" aka mount two app at the same component.

Delete (follow-up: ↓ 17 ) 03/17/09 09:11:44 changed by sevenseeker

I currently am using zope.interface and find it quite nice. I also rolled my own very similar interface that looked also like the Trac plugin architecture.

Right now, I am doing everything through interfaces but will be switching to using Abstract Base Classes as soon as I have time :)

This is because of my late and lazy binding which are not liked by pickle and thus multiprocessing. ABC has features to allow this type of binding.

I have toyed with with using entry points as well.

All in all, I like zope.interface the best since it is out of the box and I frankly was surprised I would like it at all. :)

Due to each having their place (strengths and weaknesses) perhaps instead of discussing implementation at this point, we should discuss the reasons for wanting a modular system and what the goals are. After all, the golden question is as usual, "What exactly are you trying to do?"
Delete (in reply to: ↑ 16 ) 03/17/09 23:05:18 changed by jorge.vargas

Replying to sevenseeker:

This goes a lot better if discussed in the ML, also see #2275