Don't forget that an ORM is already a compatibility later between RDMS and an object system. We already have high-level cross-platform compatibility with ORM's that support multiple databases. Having tg be so "high-level" that it is ORM-agnostic would be tantamount to writing another ORM just for pluggability.
tg is a "best of breed" web stack. Not a framework for web frameworks. Personally, that's how I see Pylons, and is why I'm so excited about tg on Pylons. Pylons is about interoperability and component swappability. tg is about cherry-picking, and building helpers (like the quickstart templates) around these defaults. How better to combine these efforts than to have one be a proper subset of the other? In other words: let this ORM-pluggability be left to the framework for frameworks (Pylons) and have a clear, dictated default stack for the tg community to use, polish, and document. ~jon > I personally think it would be cool if the Turbogears API was high > enough that it "expected" drastic innovation at say a 6 month cycle > like Linux. When a distruptive technology appears, then it just > accepts it. That seems like the best approach for Turbogears. As > soon as anyone thinks "this is the best and only way", then innovation > stops. There is no best way, there is not one way. The way forward is > to accept change and disruption....otherwise we prove we are getting > too old :) > > > > --http://www.blog.noahgift.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" 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?hl=en -~----------~----~----~----~------~----~------~--~---
