> The problem is though, that the "it" in "one obvious way to do it" is not > well defined. We want to be able to do many things with TurboGears, not only > one thing. Many different kinds of applications, clients, deployments etc. > require different ways to do them. For some developers or apps, NoSQL seems > more appropriate, others want SQL. So yes, there should be one recommended > and well documented way to develop standard web apps, but it should be easy > to switch components. After all that's one of the big advantages of TG over > Django.
One thing which I would like to see is something like DataMapper in ruby, where there's a standard way to map data returned by some persistence layer into objects. We've been talking about this as SAL your friendly Storage Abstraction Layer. If we can do a good job with building some kind of SAL, you'll be able to plug sessions, and other "framework" features into that abstraction layer, and still use higher level tools even when you swap out lower level components. This kind of dream was just impossible to imagine tackling on our own, but seems like it is something we can do together, and that's what excites me about the possibilities of pyramid. -- 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.
