I have in fact been developing "components" for TG for some time now.
DBMechanic could be seen as the first of said components, and probably one of the more complex systems. I am now working on tg.ext.silverplate, which is another component, intended to handle registration and user administration. Now, my components do not modify the database schema in anyway, and this is not an easy problem to solve really. The only thing i could suggest is that components should not be allowed to modify the schema in any way, but can utilize the general TG2 database session. The reason modifying the database schema is a hard problem is that you end up with a mis-match between your model code and your database schema, which may be ok in some cases. Personally I don't like that kind of mismatch, which leads us to the idea of generating your model code, which seems like a great solution. You may find that developers will be reluctant to release control of their model/__init__.py in favor of automatically created schema (I am one of those). This is why I have not pushed hard to make dbmech create and delete columns/ tables/etc. I'm still trying to figure out the best way to handle this. Personally, I am not a big fan of generated code (with the exception of true assemblers). Also, I tend to break my model out into separate files, and the idea of finding which file things are defined in and modifying them is ludicrous. In fact, the database schema may be defined in a completely different package which your component does not have write access to. All of this boils down to the simplest approach: components requiring their own database tables/rows/etc should create their own separate database schema and database. This also frees the developer of said components to use whatever ORM or other database techniques they choose. This schema should be configurable, so should the developer choose to share the database with the general TG database he can do so. Here are the kinds of things I have been trying to figure out how to do, and they are slowly coming out with the wash as silverplate is being developed. 1) Identity schema information must be shared across the pylons config object. This gives the extension (im calling them extensions not components) some ability to use alternative database schema to access the identity information. One example of this is using makeForm and makeTable primitives form dbsprockets to generate registration forms and user tables for management. 2) In order for extensions to maintain the look-and-feel of the overall application, we have to figure out a way of mapping the templates to the extensions and making them swappable. I am not sure on how to do this, but I think I will figure it out eventually. If anyone has ideas on this subject, please let me know. Hope some of this helps. cheers. -chris On May 28, 5:02 am, Dean Landolt <[EMAIL PROTECTED]> wrote: > This is something I've been hoping for for quite a while. Most of this > seems pretty well suited for setuptools, particularly upgrades and > dependencies, and customizations would be as easy as extracting and > modding the installed egg, but obviously that would make rolling in > the latest component changes untenable. It would pretty much force the > solution Mark suggested and just use mercurial to let the user > untangle the mess. > > Of course, model changes would still require some sort of migration, > so no matter what there would have to be some sort of update script > provided by the component author anyway -- perhaps this is a decent > place to hook in for updates... > > So I guess my question is, should these components be _customized_ or > _extended_? Breaking changes (like an ALTER on the model) will have to > be dealt with no matter how you slice it, but in most cases (template > customization) it would be trivial to override the default. I guess > this would be considered monkeypatching, but it doesn't seem like it > to me. > > On May 27, 4:53 am, Patrick Lewis <[EMAIL PROTECTED]> wrote: > > > Hello, > > > In starting work on ticket 1655 [1] (which is about a component > > architecture for TG apps) , I've drafted up a requirements document > > for discussion [2]. If you have some time and interest, I'd appreciate > > any feedback or input that you might have. Thanks. > > > [1]http://trac.turbogears.org/ticket/1655 > > [2]http://docs.turbogears.org/2.0/RoughDocs/SiteComponentRequirements --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears Trunk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~----------~----~----~----~------~----~------~--~---
