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
-~----------~----~----~----~------~----~------~--~---

Reply via email to