On Mon, Jan 19, 2009 at 4:03 PM, Mike Orr <[email protected]> wrote: > > On Mon, Jan 19, 2009 at 1:29 PM, Wyatt Baldwin > <[email protected]> wrote: >> >> On Jan 19, 9:20 am, Colin Flanagan <[email protected]> wrote: >>> The SQLAlchemy argument is a very compelling one. I have an application >>> that, while being a CMS, has heavily relational data. I was urged by >>> different people to do it either in Django or Plone, but went with Pylons. >>> My domain objects are far easier to work with, though I did suffer from the >>> authentication layer and a few other things I had to build from scratch. >>> >>> Django can use SQLAlchemy, but by doing so you pretty much nullify a lot of >>> the things that are unique to that framework like their "automatic admin >>> interfaces." Django's object generation came nowhere near understanding >>> my moderately-complicated data model and would have been much more >>> difficult to develop with, as compared to Pylons with SQLAlchemy. >>> >>> On another note: >>> I find it interesting that a lot of people recommend Django for CMS-type >>> applications. I would think that Plone might be more far more suitable >>> given that: >>> 1. your data fits well with the hierarchical structure of the ZODB >>> 2. your content is comparable to the content types already established in >>> Plone >>> 3. you don't have any legacy data or need to integrate with other systems >>> 4. you don't need to do lots of custom UI/presentation layer work >> >> I'm no Plone expert, but I don't think #4 is a problem for Plone. I >> think there are actually quite a few Plone sites with custom UIs (my >> company's new Intranet being one of them). > > Plone is certainly very complete. Its main problem is its Zope 2 > legacy, which many people see as baggage. But if you ignore that, > it's got many many things a content-based site needs. Pylons is > clearly better for a calculation-based site with a lot of little > pieces of data, although of course you can build any site in either. > Django is in between, with some CMS-handy features built in, yet also > capable of running a calculation-based site, but is perhaps not as > attuned to it as Pylons is. > >> PS If anyone needs an SA type def for PostGIS geometry columns, give >> me a shout. I have one version based on PCL and another on Shapely. > > I don't know this, but there are open-source GIS groups who probably do. > http://groups.google.com/group/cugos
sorry for more TG propaganda, but one of our gsoc projects from last year was exactly this. I know the author and even though I haven't used the code for anything real, it looks very nice. His gsoc was really nice as it was mainly to "try to get as much gis stuff working with tg as possible" overview docs http://turbogears.org/2.0/docs/main/Extensions/Geo/ here is a demo app http://geo.turbogears.org/ and the project page http://code.google.com/p/tgtools/ Now keep in mind this was one of the goals for TG2, let pylons concentrate on the details of the framework while TG explored the extensions. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" 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/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
