On Tue, Jan 20, 2009 at 11:17 AM, Jorge Vargas <[email protected]> wrote: > > 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.
Although, this might eventually move to an even more common "United" core that many web frameworks extend off of: http://www.openplans.org/projects/pypefitters/ We can only hope... > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
