On 4/19/07, Ben Bangert <[EMAIL PROTECTED]> wrote: > On Apr 18, 2007, at 12:03 PM, Mike Orr wrote: > > Great idea. Pylons definitely needs a database administration tool. > > My main concern is about basing it on the ORM layer rather than > > accessing tables directly. The application I'm working on now uses > > SQLAlchemy for its auto-retry connections and SQL builder, but I found > > the ORM to be unnecessary complexity for it. Could AdminPylon support > > both ORM and non-ORM interfaces? > I believe that would add a significant amount of redundant complexity > to this, as SA has already abstracted and done a ton of introspection > work that would need to be done yet again. Adding stuff like this > will bring necessary requirements on other tools, which is why its > place is not in Pylons itself, but in additional tools, and I think > that's just fine. ;) >
Ben is right, I don't want to reinvent the abstraction wheel that is already done by SQLAlchemy. Also, working with lower level DB tables will require developers to define table relationships in the controller, when it should be done (and is done by SA mapper) in the model. AdminPylon is a simple problem-oriented controller (really, a mini-application) for Pylons and I want it to stay like it is. About Pylons and AdminPylon. Really, Pylons should stay the full-featured, but _generic_ framework for developing web applications. The AdminPylon is a "plug in" thing, that adds a dependency on the ORM and really is not needed by all. It's more a CMS thing. -- WBR, Dan Korostelev --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
