Re: Django or Pylons - comparison details
Being a pylons newb myself, the first thing I did was write auth and registration. It took a day.Granted I wasn't trying to support every auth method I could think of like authkit does,but I learned lots.If you want auth (and other things) rolled in use use turbogears. But getting basic authentication and registration working is not that big of a deal. On Dec 8 2008, 8:50 am, Jorge Vargas jorge.var...@gmail.com wrote: that is because a) the author or authkit is never around b) authkit is way over complicated c) autukit sucks in other ways d) all of the above. that said, I do think that a default auth should be added to pylons, as it's a pretty common feeture but that's another discussion. if you hate your tool then change it. Now don't come back complaining that django wants you to do things in X,Y and Z way, and even if that's bad/dumb/not-the-best you will expend way way more time trying to get around it. --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Django or Pylons - comparison details
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 curious if Django's CMS reputation comes from the fact that it's used by a lot of newspapers and content providers, or if there really is something that makes it advantageous over other frameworks. - Original Message From: chris.mol...@gmail.com chris.mol...@gmail.com To: pylons-discuss pylons-discuss@googlegroups.com Sent: Monday, January 19, 2009 11:17:23 AM Subject: Re: Django or Pylons - comparison details That's it.. that's the reason to use Pylons: SQLAlchemy. If you need to actually use a database correctly (which I'm guessing that you do), then you need to use Pylons. The db framework that ships with Django tries to be functionally compatible with RoR-style development... which is ok, as long you don't use your DB for anything more than 'select.. '. Totally brain-dead, IMO...and frankly targeted for people w/o DB experience. On Dec 6 2008, 4:42 pm, Noah Gift noah.g...@gmail.com wrote: On Sun, Dec 7, 2008 at 7:39 AM, Ben Bangert b...@groovie.org wrote: On Dec 6, 2008, at 9:31 AM, zunzun wrote: Comparison before starting a project, used to decide which framework to use. Django: according tohttp://groups.google.com/group/django-users/about Members 12,016 Group Activity is High Pylons: according tohttp://groups.google.com/group/pylons-discuss/about Members: 1,748 Group Activity is Low Really? That's how you decide? Then I believe you *must* choose PHP. It completely dwarfs Django and Python altogether, its the only choice really if you want to determine framework based on user-base (popularity). :) Also, Django just made a major release. The last (non-security fix) Pylons release is over a year old. Guido van Rossum has blessed Django here: http://www.djangoproject.com/weblog/2006/aug/07/guidointerview/ Before that release, they hadn't made a release in almost 2 years, and actually told everyone to run production websites on the development branch... Pylons 0.9.7 RC4 came out about 2 weeks ago. Guido is not a veteran web developer, nor does he actually use any of Django beyond Django templates, his apps have been generally built with pure WSGI and Django templates, the recent port of his Mondrian to a Django app was prolly his first actual Django project. Seems like I should use Django? Or should it be Pylons instead? Is a long-planned major release immediately forthcoming? What kind of app/site are you building? What tools matter to you? Do you think you'll need to scale heavily? Are you talking to a legacy database? etc. Those questions are the ones you should be asking yourself, then seeing which framework has the tools you need to accomplish your task. Otherwise, merely posting some mail list numbers and that Guido likes Django seems to be awfully trollish as it doesn't seem to be a serious attempt to evaluate the frameworks benefits for the task you're actually trying to complete. I'd highly suggest searching the mail list for some previous threads on the subject, as this doesn't really need rehashing again. http://markmail.org/search/?q=list%3Apylons+django+pylons I wouldn't necessarily agree that it doesn't need rehashing, at least from a marketing and documentation perspective. I just talked with some co-workers last week, that are very experienced Python programmers and they asked me why they hadn't heard about Pylon's much. One person mentioned he looked at it about a year and half ago, and decided to go with Django. Now he ran into a problem that only SQLAlchemy can solve, and after he went through the new pylons book online he was quite impressed. In my opinion Pylons and Django solve two different problems, although there is some overlap, but even still many people don't know
Re: Django or Pylons - comparison details
On Tue, Jan 20, 2009 at 5:28 AM, Jonathan Vanasco jonat...@findmeon.com wrote: Django is like Rails -- it forces you into building certain types of apps with certain styles. If you build a Django app , you're pretty much married to it -- and can expect it to work much like other apps. That's not necessarily a bad thing. Pylons SqlAlchemy offer a lot more control. One of my websites is 90% ModPerl with 10% pylons offloaded ; we use the same tables db seamlessly. I don't know if its possible in django - but it was too hard to get done. Another one of my projects is 60% Pylons, 20% PHP and 20% MovableType (Perl). Again, Pylons power and flexibility let me seamlessly get all of them working together. ( btw , we're *finally* about to release a web framework toolkit based on Pylons that lets people do all this . huge product launches in the next 6 weeks after 1yr of development and testing ). Jonathan, This seems like a very interesting set of projects. I wonder if there is somewhere people could here, customer stories like this in one spot. I had no idea people where doing this with Django. --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Django or Pylons - comparison details
On Mon, Jan 19, 2009 at 6:20 PM, Colin Flanagan quadvill...@yahoo.com wrote: I'm curious if Django's CMS reputation comes from the fact that it's used by a lot of newspapers and content providers, or if there really is something that makes it advantageous over other frameworks. Django's admin is very handy for content based sites. We're developing the Italian PyCon website with Django. While we develop the webiste some people can upload and review documents, rollback and stuff like that. Very nice. Nothing you can't code in Pylons or CGI with C, but it's nice to have it for free. -- Lawrence, http://oluyede.org - http://twitter.com/lawrenceoluyede It is difficult to get a man to understand something when his salary depends on not understanding it - Upton Sinclair --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Django or Pylons - comparison details
On Jan 19, 9:20 am, Colin Flanagan quadvill...@yahoo.com 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). And just to add another voice to this SQLAlchemy hurrah, like Colin, I'm also doing (complex) GIS stuff with PostGIS ( Shapely GeoJSON PyProj). Having a bit of experience with both Django and Rails, I don't know how I'd accomplish with their ORMs what I can with SA. I'm not saying it's not possible, but it seems nowhere near as straightforward or flexible. I'm also using Pylons/SA with a big, ugly, legacy Oracle schema. Fun, fun, fun. 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. --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Django or Pylons - comparison details
On Jan 19, 1:29 pm, Wyatt Baldwin wyatt.lee.bald...@gmail.com wrote: On Jan 19, 9:20 am, Colin Flanagan quadvill...@yahoo.com 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). And just to add another voice to this SQLAlchemy hurrah, like Colin, I'm also doing (complex) GIS stuff with PostGIS ( Shapely GeoJSON PyProj). Having a bit of experience with both Django and Rails, I don't know how I'd accomplish with their ORMs what I can with SA. I'm not saying it's not possible, but it seems nowhere near as straightforward or flexible. s/Colin/Chris --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Django or Pylons - comparison details
On Jan 19, 12:26 pm, Noah Gift noah.g...@gmail.com wrote: On Tue, Jan 20, 2009 at 5:28 AM, Jonathan Vanasco jonat...@findmeon.com wrote: Django is like Rails -- it forces you into building certain types of apps with certain styles. If you build a Django app , you're pretty much married to it -- and can expect it to work much like other apps. That's not necessarily a bad thing. Pylons SqlAlchemy offer a lot more control. One of my websites is 90% ModPerl with 10% pylons offloaded ; we use the same tables db seamlessly. I don't know if its possible in django - but it was too hard to get done. Another one of my projects is 60% Pylons, 20% PHP and 20% MovableType (Perl). Again, Pylons power and flexibility let me seamlessly get all of them working together. ( btw , we're *finally* about to release a web framework toolkit based on Pylons that lets people do all this . huge product launches in the next 6 weeks after 1yr of development and testing ). Jonathan, This seems like a very interesting set of projects. I wonder if there is somewhere people could here, customer stories like this in one spot. I had no idea people where doing this with Django. With Django or with Pylons? --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Django or Pylons - comparison details
On Mon, Jan 19, 2009 at 10:29 PM, Wyatt Baldwin wyatt.lee.bald...@gmail.com wrote: On Jan 19, 9:20 am, Colin Flanagan quadvill...@yahoo.com 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). And just to add another voice to this SQLAlchemy hurrah, like Colin, I'm also doing (complex) GIS stuff with PostGIS ( Shapely GeoJSON PyProj). Having a bit of experience with both Django and Rails, I don't know how I'd accomplish with their ORMs what I can with SA. I'm not saying it's not possible, but it seems nowhere near as straightforward or flexible. I'm also using Pylons/SA with a big, ugly, legacy Oracle schema. Fun, fun, fun. 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. Hi, We also have this in MapFish. https://trac.mapfish.org/trac/mapfish/browser/trunk/MapFish/server/python/mapfish/sqlalchemygeom.py -- Eric --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Django or Pylons - comparison details
On Tue, Jan 20, 2009 at 10:40 AM, Wyatt Baldwin wyatt.lee.bald...@gmail.com wrote: On Jan 19, 12:26 pm, Noah Gift noah.g...@gmail.com wrote: On Tue, Jan 20, 2009 at 5:28 AM, Jonathan Vanasco jonat...@findmeon.com wrote: Django is like Rails -- it forces you into building certain types of apps with certain styles. If you build a Django app , you're pretty much married to it -- and can expect it to work much like other apps. That's not necessarily a bad thing. Pylons SqlAlchemy offer a lot more control. One of my websites is 90% ModPerl with 10% pylons offloaded ; we use the same tables db seamlessly. I don't know if its possible in django - but it was too hard to get done. Another one of my projects is 60% Pylons, 20% PHP and 20% MovableType (Perl). Again, Pylons power and flexibility let me seamlessly get all of them working together. ( btw , we're *finally* about to release a web framework toolkit based on Pylons that lets people do all this . huge product launches in the next 6 weeks after 1yr of development and testing ). Jonathan, This seems like a very interesting set of projects. I wonder if there is somewhere people could here, customer stories like this in one spot. I had no idea people where doing this with Django. With Django or with Pylons? Ah, I meant Pylons :) Maybe this could be done officially or unofficially. --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Django or Pylons - comparison details
On Mon, Jan 19, 2009 at 3:15 PM, Lawrence Oluyede l.oluy...@gmail.com wrote: On Mon, Jan 19, 2009 at 6:20 PM, Colin Flanagan quadvill...@yahoo.com wrote: I'm curious if Django's CMS reputation comes from the fact that it's used by a lot of newspapers and content providers, or if there really is something that makes it advantageous over other frameworks. Django's admin is very handy for content based sites. We're developing the Italian PyCon website with Django. While we develop the webiste some people can upload and review documents, rollback and stuff like that. Very nice. Nothing you can't code in Pylons or CGI with C, but it's nice to have it for free. you should try out Catwalk2, tgext.admin and/or Rum. They are currently the competitors in TurboGears2 regarding this playing field. Catwalk2 and tgext.admin are build on top of Turbogears so you will need that dependency (totally worth it) or if you don't want that then Rum is a wsgi app http://pypi.python.org/pypi/Catwalk http://pypi.python.org/pypi/tgext.admin/ http://docs.python-rum.org/user/install.html Note: the author is catwalk and tgext.admin is the same guy, he is currently considering of folding one of the projects into the other as at this moment their only difference is that Catwalk2 is equivalent to django's autodiscovery while tgext.admin is the customizable by code type of thing Note2: I haven't used any of the 3 outside a turbogears project, but they will work in parallel --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Django or Pylons - comparison details
On Mon, Jan 19, 2009 at 1:29 PM, Wyatt Baldwin wyatt.lee.bald...@gmail.com wrote: On Jan 19, 9:20 am, Colin Flanagan quadvill...@yahoo.com 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 -- Mike Orr sluggos...@gmail.com --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Django or Pylons - comparison details
On Mon, Jan 19, 2009 at 4:03 PM, Mike Orr sluggos...@gmail.com wrote: On Mon, Jan 19, 2009 at 1:29 PM, Wyatt Baldwin wyatt.lee.bald...@gmail.com wrote: On Jan 19, 9:20 am, Colin Flanagan quadvill...@yahoo.com 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 pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Django or Pylons - comparison details
On Tue, Jan 20, 2009 at 11:17 AM, Jorge Vargas jorge.var...@gmail.com wrote: On Mon, Jan 19, 2009 at 4:03 PM, Mike Orr sluggos...@gmail.com wrote: On Mon, Jan 19, 2009 at 1:29 PM, Wyatt Baldwin wyatt.lee.bald...@gmail.com wrote: On Jan 19, 9:20 am, Colin Flanagan quadvill...@yahoo.com 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 pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Django or Pylons - comparison details
On Mon, Jan 19, 2009 at 4:54 PM, Colin Flanagan quadvill...@yahoo.com wrote: - Original Message From: Jorge Vargas jorge.var...@gmail.com To: pylons-discuss@googlegroups.com Sent: Monday, January 19, 2009 4:45:35 PM Subject: Re: Django or Pylons - comparison details On Mon, Jan 19, 2009 at 3:15 PM, Lawrence Oluyede l.oluy...@gmail.com wrote: On Mon, Jan 19, 2009 at 6:20 PM, Colin Flanagan quadvill...@yahoo.com wrote: I'm curious if Django's CMS reputation comes from the fact that it's used by a lot of newspapers and content providers, or if there really is something that makes it advantageous over other frameworks. Django's admin is very handy for content based sites. We're developing the Italian PyCon website with Django. While we develop the webiste some people can upload and review documents, rollback and stuff like that. Very nice. Nothing you can't code in Pylons or CGI with C, but it's nice to have it for free. you should try out Catwalk2, tgext.admin and/or Rum. They are currently the competitors in TurboGears2 regarding this playing field. Catwalk2 and tgext.admin are build on top of Turbogears so you will need that dependency (totally worth it) or if you don't want that then Rum is a wsgi app http://pypi.python.org/pypi/Catwalk http://pypi.python.org/pypi/tgext.admin/ http://docs.python-rum.org/user/install.html Note: the author is catwalk and tgext.admin is the same guy, he is currently considering of folding one of the projects into the other as at this moment their only difference is that Catwalk2 is equivalent to django's autodiscovery while tgext.admin is the customizable by code type of thing Note2: I haven't used any of the 3 outside a turbogears project, but they will work in parallel These are really interesting. I'm especially curious to hear anyone's experience using Rum with Pylons. I'm getting ready to build something really similar but am now thinking otherwise. as I said rum is a wsgi app, so it runs standalone, rumAlchemy your dburi is enough. to try it out. As for the integration (running in the same process, theme sharing, etc.) that's another story, you could base yourself on the tg2 sample app. My impression of Django's admin was that, once you've replaced the native ORM, you no longer get it for free. That still holds true, no? yes, django admin is tied into django ORM. On the contrary rum has interfaces to use other ORMs, but so far it only has a SQLAlchemy backend. The same hold s true for catwalk2. Just to be clear, all 3 of these tools provide some how the same feature set of django admin. they are NOT django they are 100% TG/pylons code. Both use as base ToscaWidgets which ones was TruboGears widgets, catwalk2 and tgext.admin build on top of a second framework call sprox (which is somehow like formalchemy), The difference between the three is really set in internal components and some design issue, but to the end use they all should be quite alike. --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Django or Pylons - comparison details
On 20/01/2009, at 3:30 AM, Thomas G. Willis wrote: Being a pylons newb myself, the first thing I did was write auth and registration. It took a day.Granted I wasn't trying to support every auth method I could think of like authkit does,but I learned lots.If you want auth (and other things) rolled in use use turbogears. But getting basic authentication and registration working is not that big of a deal. Similar story, but I used repoze.who for authentication and am very happy with it. It is very customisable, which is what I needed; the app supports both form/cookie auth and HTTP basic auth simultaneously. repoze.who made this easy to configure in exactly the way I wanted. Cheers, Chris Miles --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Django or Pylons - comparison details
I don't use FormEncode. It is based on a very common design mistake made by a lot of programmers, who think one can better generate html from code. I think you are maybe mixing up Formencode and some projects that use formencode. Formencode's core is for validating and converting to and from python and raising errors. That's it. What you're talking about is the context in which formencode is often used, not formencode itself. Formencode does one job very well and cleanly, it makes no assumptions about whether you are generating html from code or not. Iain --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Django or Pylons - comparison details
Cropr's point seems to be that programmers should not design forms because graphic designers do a much better job. That is true only if a complex visual design for the form page is paramount. In most cases the complex design occurs on the home page and content pages, and the form is merely an add-on and can be simple. It must also mean that their css guys are not very good. ;-) If they are using front end css people, it should be no problem for the coders to produce clean forms and the designers to be able to make those look as fancy as they want with css only. A good css person should be able to do whatever they need with nothing more than a clean list form and some sensible id tags in there. I do both backend and front end coding for some very picky graphic designers, and have never had problems making toscawidget generated forms look exactly as I need them to. Iain --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Django or Pylons - comparison details
I choose Pylons and not Django for 2 specific reasons - Mako SQLAlchemy are far superior than the templating engine and ORM of Django. - Pylons is full WSGi from the ground up. It Django WSGI smells like Object Orientation is pasted into Perl One item I really liked about Django that is not in Pylons, is the admin section to do simple database operations. One can argue that this is very easy to develop (which is true), but in Django I don't have the waste my time in writing it. I don't use FormEncode. It is based on a very common design mistake made by a lot of programmers, who think one can better generate html from code. When a graphical artist designs the layout of a web page, he uses tools who speak html, css and javascript, but no python (or Perl, Java, C++, ...). I tried to AuthKit in my last project (http://www.kosk.be), but I could not bend it in the way I wanted. I want to have a login applet open all the time (in the bottem left on www.kosk.be). I did not manage to do this with AuthKit, but I used the methods described in the PylonsBook, to write my own authorization layer. This was a piece of cake and demonstrates the flexibility of Pylons Ruben --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Django or Pylons - comparison details
On Tue, Dec 9, 2008 at 11:33 PM, Wichert Akkerman [EMAIL PROTECTED] wrote: Previously cropr wrote: I don't use FormEncode. It is based on a very common design mistake made by a lot of programmers, who think one can better generate html from code. When a graphical artist designs the layout of a web page, he uses tools who speak html, css and javascript, but no python (or Perl, Java, C++, ...). While I agree FormEncode is very far from ideal, your argument does not make sense to me. FormEncode does not generate markup at all unless you explicitly tell it to. I do exactly what you describe: hand-written markup written by a designer, with FormEncode on the backend only doing decoding and validation. I think this is a case where the unified documentation that Django presents is much clearer: http://docs.djangoproject.com/en/dev/topics/forms/ It took me 3 seconds to find how Django does form validation. And most people aren't confused about what it exactly does. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Django or Pylons - comparison details
Previously cropr wrote: I don't use FormEncode. It is based on a very common design mistake made by a lot of programmers, who think one can better generate html from code. When a graphical artist designs the layout of a web page, he uses tools who speak html, css and javascript, but no python (or Perl, Java, C++, ...). While I agree FormEncode is very far from ideal, your argument does not make sense to me. FormEncode does not generate markup at all unless you explicitly tell it to. I do exactly what you describe: hand-written markup written by a designer, with FormEncode on the backend only doing decoding and validation. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Django or Pylons - comparison details
Wichert Akkerman wrote: Previously cropr wrote: I don't use FormEncode. It is based on a very common design mistake made by a lot of programmers, who think one can better generate html from code. When a graphical artist designs the layout of a web page, he uses tools who speak html, css and javascript, but no python (or Perl, Java, C++, ...). While I agree FormEncode is very far from ideal, your argument does not make sense to me. FormEncode does not generate markup at all unless you explicitly tell it to. I do exactly what you describe: hand-written markup written by a designer, with FormEncode on the backend only doing decoding and validation. Not only doesn't it generate markup unless you tell it to, it won't even generate markup if you *do* tell it to ;) -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Django or Pylons - comparison details
On Tue, Dec 9, 2008 at 2:36 AM, Noah Gift [EMAIL PROTECTED] wrote:
On Tue, Dec 9, 2008 at 11:33 PM, Wichert Akkerman [EMAIL PROTECTED] wrote:
Previously cropr wrote:
I don't use FormEncode. It is based on a very common design mistake
made by a lot of programmers, who think one can better generate html
from code. When a graphical artist designs the layout of a web page,
he uses tools who speak html, css and javascript, but no python (or
Perl, Java, C++, ...).
While I agree FormEncode is very far from ideal, your argument does not
make sense to me. FormEncode does not generate markup at all unless
you explicitly tell it to. I do exactly what you describe: hand-written
markup written by a designer, with FormEncode on the backend only
doing decoding and validation.
I think this is a case where the unified documentation that Django presents
is much clearer:
http://docs.djangoproject.com/en/dev/topics/forms/
It took me 3 seconds to find how Django does form validation. And most
people aren't confused about what it exactly does.
Cropr's point seems to be that programmers should not design forms
because graphic designers do a much better job. That is true only if
a complex visual design for the form page is paramount. In most cases
the complex design occurs on the home page and content pages, and the
form is merely an add-on and can be simple. In some cases the form is
for technical users who will tolerate a lack of bells and whistles.
And some organizations do not have graphic designers for things like
form pages. In any case, the programmer can put CSS IDs in the form
as instructed by the graphic designer, or the graphic designer can be
taught the simple syntax of input-tag helpers.
Or you can use Genshi, which allows you to place dummy tags in the
template source, which will be replaced by the actual input tags which
can be calculated using WebHelpers. It's something like this:
input type=text name=name class=my-class
py:replace=h.text('name', value=None, class_='my-class') /
If you're setting tag attributes, it's much more convenient to call a
helper than to interpolate the value into a static tag.
${h.text(name, id=my_name, class_=c.my_class)
input type=text name=name, id=my_name, class=${c.my_class} /
The helper also takes care of issues like attributes in a dictionary.
${h.text(name, **attrs)}
input type=text name=name
${FUNCTION_TO_CONVERT_A_DICT_TO_A_TAG_FRAGMENT(attrs)}
Making links and the form tag is also more convenient with a helper.
${link_to(c.title, url(bla, anchor=bla-bla), class_=C)}
a href=${url('bla', anchor='bla-bla')} class=C${c.title}/a
${h.form(c.action, c,method, multipart=True, class_=search)}
form action=${c.action} method=${c.method}
enctype=multipart/form-data class=search
I haven't used Django forms but it seems to generate HTML based on a
Python field specification, akin to ToscaWidgets or Quixote forms. So
that would not meet Cropr's standards either. Especially since the
kinds of forms that require graphic designers have arbitrary and
changing requirements like Put this field exactly here, to the right
of this other field. And could we add two paragraphs of help text
below this field? And oh, this field needs a little green message
below the title. It takes a lot of time to program this into an HTML
generator and write unit tests for it, about the same amount of time
as it does to lay out the form manually. But laying out the form
manually is made more convenient with WebHelpers.
In any case, in Pylons the programmer is free to let the graphic
designer handle all templates, or design the form with WebHelpers, or
design the form without WebHelpers, or use ToscaWidgets or Django
forms or FormAlchemy. WebHelpers is just there to provide a basic
alternative, and doesn't get much in the way if you don't use it.
--
Mike Orr [EMAIL PROTECTED]
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Django or Pylons - comparison details
If your questions needs to be answered quickly, Django may be right choice. I think, you could have known why not to use PHP when you ask question on Django vs Pylons :-) . I NEVER worked on Python at jobs. I wanted to create a website. I have chosen Pylons over Django due to its customization feature luxuries. I have gathered small small frustration while working due to lack of documentation community support. I am very thankful for people who helped me in some cases. I spend more time on Pylons. Now I don't have time interest to learn another framework. I have to go with Pylons. All I would ask seniors/library developers of pylons to respond to the questions asked by newbies like me. Let the newcomers to feel good about using Pylons by heart. I REALLY don't understand what do you people mean by marketing Pylons. I tried to use authkit in my project, which is evil in my project life. I asked many questions here but got no reply. I do not expect such a thing from a matured community. Things are changing but very slowly. Sorry about my English. On Dec 7, 5:30 am, Mike Orr [EMAIL PROTECTED] wrote: On Sat, Dec 6, 2008 at 10:39 AM, Ben Bangert [EMAIL PROTECTED] wrote: On Dec 6, 2008, at 9:31 AM, zunzun wrote: Comparison before starting a project, used to decide which framework to use. Django: according tohttp://groups.google.com/group/django-users/about Members 12,016 Group Activity is High Pylons: according tohttp://groups.google.com/group/pylons-discuss/about Members: 1,748 Group Activity is Low Really? That's how you decide? Then I believe you *must* choose PHP. It completely dwarfs Django and Python altogether, its the only choice really if you want to determine framework based on user-base (popularity). :) Excellent answer. Pylons 0.9.7 is almost released, the main issue being finishing the documentation. In the meantime, the Pylons Book is pretty complete and covers the RC version. It's an axiom of open-source programming that the last 10% of a release takes N months longer than anticipated. N = 5 and counting for Pylons, and it has been 12 for both Django and Cheetah in the past. Django's popularity is mainly due to superior marketing and documentation. They have a corporate backer and thus more people with those skills. Pylons' developers are mainly hackers/web programmers, who would rather build software than do marketing. So many people have not heard about Pylons or its voice gets drowned out. But Pylons has particular favor among those who like extremely modular tools, and those people have been coming to us. An interesting question is, why did [any framework's] users choose it? Django: - technical capability: same as Pylons/TurboGears. Not a reason to choose one over another. - design philosophy: build our own tools so it's well integrated. Some number of people like this. - completeness of toolset: if you need CMS tools, there may be some that are only available in Django and Plone currently. - tutorials: I read Django's docs and they were easy to understand. A lot of people cite this. - marketing: It seems everybody's using Django. or I didn't know there were any other viable Python frameworks.: A lot of people say this. Pylons: - technical capability: the same. - design philosophy: use 3rd-party tools when feasable, WSGI to the core: many Pylons' enthusiasts come from this mindset. - completeness of toolset: the basic stuff is all there and then some. - tutorials: it takes a bit of work to find the relevant documentation. For 0.9.7, the Pylons Book is your best bet right now. For 0.9.6, the official docs are good. - marketing: there will be a stronger marketing push after 0.9.7 is released and the new website is finished. Guido van Rossum has blessed Django here: http://www.djangoproject.com/weblog/2006/aug/07/guidointerview/ That was written two years ago. At the time Guido also hoped Django and Pylons would merge. I don't think he understood the situation very well at that point, because Django and Pylons can't merge without one of them giving up its fundamental philosophy. And the ascent of WSGI makes a merger less necessary: what's needed is interoperability. Django has had a weakness on that point, but it's gradually getting better as it moves closer to WSGI. In any case, Guido now understands that multiple frameworks are here to stay (like multiple GUI libraries), and each has its unique strengths. -- Mike Orr [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Django or Pylons - comparison details
On Mon, Dec 8, 2008 at 3:54 AM, Krishgy [EMAIL PROTECTED] wrote: If your questions needs to be answered quickly, Django may be right choice. I think, you could have known why not to use PHP when you ask question on Django vs Pylons :-) . I NEVER worked on Python at jobs. I wanted to create a website. I have chosen Pylons over Django due to its customization feature luxuries. I have gathered small small frustration while working due to lack of documentation community support. I am very thankful for people who helped me in some cases. I spend more time on Pylons. Now I don't have time interest to learn another framework. I have to go with Pylons. All I would ask seniors/library developers of pylons to respond to the questions asked by newbies like me. Let the newcomers to feel good about using Pylons by heart. I REALLY don't understand what do you people mean by marketing Pylons. I tried to use authkit in my project, which is evil in my project life. I asked many questions here but got no reply. I do not expect such a thing from a matured community. that is because a) the author or authkit is never around b) authkit is way over complicated c) autukit sucks in other ways d) all of the above. that said, I do think that a default auth should be added to pylons, as it's a pretty common feeture but that's another discussion. if you hate your tool then change it. Now don't come back complaining that django wants you to do things in X,Y and Z way, and even if that's bad/dumb/not-the-best you will expend way way more time trying to get around it. Things are changing but very slowly. Sorry about my English. On Dec 7, 5:30 am, Mike Orr [EMAIL PROTECTED] wrote: On Sat, Dec 6, 2008 at 10:39 AM, Ben Bangert [EMAIL PROTECTED] wrote: On Dec 6, 2008, at 9:31 AM, zunzun wrote: Comparison before starting a project, used to decide which framework to use. Django: according tohttp://groups.google.com/group/django-users/about Members 12,016 Group Activity is High Pylons: according tohttp://groups.google.com/group/pylons-discuss/about Members: 1,748 Group Activity is Low Really? That's how you decide? Then I believe you *must* choose PHP. It completely dwarfs Django and Python altogether, its the only choice really if you want to determine framework based on user-base (popularity). :) Excellent answer. Pylons 0.9.7 is almost released, the main issue being finishing the documentation. In the meantime, the Pylons Book is pretty complete and covers the RC version. It's an axiom of open-source programming that the last 10% of a release takes N months longer than anticipated. N = 5 and counting for Pylons, and it has been 12 for both Django and Cheetah in the past. Django's popularity is mainly due to superior marketing and documentation. They have a corporate backer and thus more people with those skills. Pylons' developers are mainly hackers/web programmers, who would rather build software than do marketing. So many people have not heard about Pylons or its voice gets drowned out. But Pylons has particular favor among those who like extremely modular tools, and those people have been coming to us. An interesting question is, why did [any framework's] users choose it? Django: - technical capability: same as Pylons/TurboGears. Not a reason to choose one over another. - design philosophy: build our own tools so it's well integrated. Some number of people like this. - completeness of toolset: if you need CMS tools, there may be some that are only available in Django and Plone currently. - tutorials: I read Django's docs and they were easy to understand. A lot of people cite this. - marketing: It seems everybody's using Django. or I didn't know there were any other viable Python frameworks.: A lot of people say this. Pylons: - technical capability: the same. - design philosophy: use 3rd-party tools when feasable, WSGI to the core: many Pylons' enthusiasts come from this mindset. - completeness of toolset: the basic stuff is all there and then some. - tutorials: it takes a bit of work to find the relevant documentation. For 0.9.7, the Pylons Book is your best bet right now. For 0.9.6, the official docs are good. - marketing: there will be a stronger marketing push after 0.9.7 is released and the new website is finished. Guido van Rossum has blessed Django here: http://www.djangoproject.com/weblog/2006/aug/07/guidointerview/ That was written two years ago. At the time Guido also hoped Django and Pylons would merge. I don't think he understood the situation very well at that point, because Django and Pylons can't merge without one of them giving up its fundamental philosophy. And the ascent of WSGI makes a merger less necessary: what's needed is interoperability. Django has had a weakness on that point, but it's gradually getting better as it moves closer to WSGI. In any case, Guido now
Re: Django or Pylons - comparison details
2008/12/6 zunzun [EMAIL PROTECTED]: Seems like I should use Django? Or should it be Pylons instead? Here is the advice of an average programmer with no emotional involvement in any of these projects. I think it depends on your background. The Pylons ecosystem is very powerful but it's quite complex and not really suitable for beginners. If it's going to be the first web framework you use, you should probably stick with Django or even better Rails. If you're a seasoned web developer used to get acquainted quickly with new APIs and want a maximum of flexibility, then Pylons is for you. Don't let the size of the community fool you, when it comes to technical advice quality matters more than quantity. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Django or Pylons - comparison details
Previously Alex Marandon wrote: 2008/12/6 zunzun [EMAIL PROTECTED]: Seems like I should use Django? Or should it be Pylons instead? Here is the advice of an average programmer with no emotional involvement in any of these projects. I think it depends on your background. The Pylons ecosystem is very powerful but it's quite complex and not really suitable for beginners. If it's going to be the first web framework you use, you should probably stick with Django or even better Rails. grok might also be a good choice. I'm not quite sure of repoze.bfg is quite there yet, but it is shaping up to be another excellent candidate as well. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Django or Pylons - comparison details
Alex Marandon wrote: 2008/12/6 zunzun [EMAIL PROTECTED]: Seems like I should use Django? Or should it be Pylons instead? Here is the advice of an average programmer with no emotional involvement in any of these projects. I think it depends on your background. The Pylons ecosystem is very powerful but it's quite complex and not really suitable for beginners. I'm not sure there is a good framework for beginners. If your a beginner to python, then starting with web design will only make it harder. If you a beginner to python web frameworks then pylons might not be your first choice only because it is complex and lets you do almost anything you want (even if its wrong). Starting with Django or TG might be a good idea. I stated with Webware (it made a lot of scene especially coming from a php background), but now I do most everything in pylons because of the power. With Pylons the simple stuff is pretty simple (once you get beyond setting up your first application) and the complex stuff is possible. I really think its the same with any web framework, the better ones are complex by their very nature, after all we're building applications where we often have to user multiple languages to get the desired effects, serverside code for logic and data modeling, template code to generate a view and javascript to add ajax or just make the application look the way you want it to. Frameworks like pylons do their best to help you separate the three, other frameworks (Webware, php) let you mash it all together. So the long answer what is better, it all depends on what you want to do, how you want to do it, and where you are in the beginner-expert range (me I'm in the middle, not an expert yet, but I do ok). I don't like Django because I deal with lots of legacy data, an administrative staff that is constantly changing the system requirements, so even though sometimes things might be simpler to do in something like Django, in the long run I find Pylons easier to deal with and modify. If it's going to be the first web framework you use, you should probably stick with Django or even better Rails. If you're a seasoned web developer used to get acquainted quickly with new APIs and want a maximum of flexibility, then Pylons is for you. Don't let the size of the community fool you, when it comes to technical advice quality matters more than quantity. I agree, this group although not huge, is usually very helpful and committed to helping folks use pylons. the problem is not that people don't always get an answer, its that they get multiple answers, different ways of doing the same thing, and to a noob I could see how that would be confusing. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Django or Pylons - comparison details
Previously Ian Bicking wrote: Wichert Akkerman wrote: Previously Alex Marandon wrote: 2008/12/6 zunzun [EMAIL PROTECTED]: Seems like I should use Django? Or should it be Pylons instead? Here is the advice of an average programmer with no emotional involvement in any of these projects. I think it depends on your background. The Pylons ecosystem is very powerful but it's quite complex and not really suitable for beginners. If it's going to be the first web framework you use, you should probably stick with Django or even better Rails. grok might also be a good choice. I'm not quite sure of repoze.bfg is quite there yet, but it is shaping up to be another excellent candidate as well. Grok over Pylons? I don't think Grok is really any less complex. Doing basic stuff isn't particularly hard in Pylons, is it? There's no reason you have to use FormEncode, AuthKit, or any of those other pieces unless you want to, and if you are beginner to Python or web development you might off avoiding those pieces and just writing your own ad hoc code. grok is much more pluggable than pylons and has more documentation available (especially if you also consider all zope documentation that works for grok apps as well). In terms of complexity for simple apps I don't think grok and pylons differ much. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Django or Pylons - comparison details
Wichert Akkerman wrote: Previously Alex Marandon wrote: 2008/12/6 zunzun [EMAIL PROTECTED]: Seems like I should use Django? Or should it be Pylons instead? Here is the advice of an average programmer with no emotional involvement in any of these projects. I think it depends on your background. The Pylons ecosystem is very powerful but it's quite complex and not really suitable for beginners. If it's going to be the first web framework you use, you should probably stick with Django or even better Rails. grok might also be a good choice. I'm not quite sure of repoze.bfg is quite there yet, but it is shaping up to be another excellent candidate as well. Grok over Pylons? I don't think Grok is really any less complex. Doing basic stuff isn't particularly hard in Pylons, is it? There's no reason you have to use FormEncode, AuthKit, or any of those other pieces unless you want to, and if you are beginner to Python or web development you might off avoiding those pieces and just writing your own ad hoc code. Understanding Pylons will be a lot easier for you if you've spent time understanding a framework in any language. If you've written your own ad hoc PHP framework, for instance, or spent time spelunking in Rails code... that experience should help you recognize some of what's going on in Pylons. -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Django or Pylons - comparison details
On Mon, Dec 8, 2008 at 5:50 AM, Jorge Vargas [EMAIL PROTECTED] wrote: On Mon, Dec 8, 2008 at 3:54 AM, Krishgy [EMAIL PROTECTED] wrote: If your questions needs to be answered quickly, Django may be right choice. I think, you could have known why not to use PHP when you ask question on Django vs Pylons :-) . I NEVER worked on Python at jobs. I wanted to create a website. I have chosen Pylons over Django due to its customization feature luxuries. I have gathered small small frustration while working due to lack of documentation community support. I am very thankful for people who helped me in some cases. I spend more time on Pylons. Now I don't have time interest to learn another framework. I have to go with Pylons. All I would ask seniors/library developers of pylons to respond to the questions asked by newbies like me. Let the newcomers to feel good about using Pylons by heart. I REALLY don't understand what do you people mean by marketing Pylons. I tried to use authkit in my project, which is evil in my project life. I asked many questions here but got no reply. I do not expect such a thing from a matured community. that is because a) the author or authkit is never around b) authkit is way over complicated c) autukit sucks in other ways d) all of the above. So, we've established that AuthKit is not officially part of Pylons. AuthKit is supported by James, and I don't think any of the other Pylons developers have used AuthKit enough to be able to answer questions about it. At least that's why I personally am silent whenever an AuthKit question is raised. James was devoting all his time to his book so he wasn't able to follow the list. Now that he's finished that, I think AuthKit will be better supported. So there's one issue about AuthKit questions not being answered and another issue about other Pylons questions not being answered. My impression is that Pylons questions remain unanswered only if nobody knows the answer, or if the question is so application-specific that the answerers don't understand the question. Because the Pylons documentation is in a bit of a disarray, I think people are more willing to answer questions here than they would be in other places. One of Pylons' goals is to be the framework for newbies, but everybody realizes it's not there yet. Pylons' hybrid structure makes it more of a challenge to explain: not impossible, just more difficult. Django and TurboGears have done a better job at supporting newbies, and the Pylons developers routinely recommend those frameworks to anybody who finds Pylons' current state too difficult to understand. But I disagree that Django is 100% easier to use across the board. It depends more in the individual than the framework. Some people are really comfortable with Django's approach; others are not. Some find Pylons to be the framework they've been waiting for; others find aspects of it annoying. The best thing is to choose two or more frameworks, browse through the documentation and try one or two little programs. It should then become apparent which one is more suited to you. Also think about your long-term goals. The framework that's easiest to write Hello, world in is not necessarily the one you want to be using when complex issues such as internationalization, authorization, AJAX, or database migration come up. I choose software based partly on its structure, partly on how responsive the mailing list is, and partly on whether the developers have expertise in areas I'm likely to need in the future. that said, I do think that a default auth should be added to pylons, as it's a pretty common feeture but that's another discussion. It's one thing to want an auth system in the abstract. It's another to choose a particular implementation and have to support it, and then possibly change your mind if a better one comes along. Pylons has already had enough trouble with blessing things that turned out to be less than ideal in the long run (Buffet, Rails helpers, old SQLAlchemy AssignMapper, pre-webob request/response). If we had chosen an auth system at the beginning it would have been AuthKit because it was written first, and then the people who say AuthKit sucks! would have been howling even louder. As with SQLAlchemy, after one of the auth systems proves itself sufficiently popular, it will become semi-supported in the docs, and then *maybe* become a part of Pylons at a later date. -- Mike Orr [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Django or Pylons - comparison details
On Sat, Dec 6, 2008 at 10:39 AM, Ben Bangert [EMAIL PROTECTED] wrote: On Dec 6, 2008, at 9:31 AM, zunzun wrote: Comparison before starting a project, used to decide which framework to use. Django: according to http://groups.google.com/group/django-users/about Members 12,016 Group Activity is High Pylons: according to http://groups.google.com/group/pylons-discuss/about Members: 1,748 Group Activity is Low Really? That's how you decide? Then I believe you *must* choose PHP. It completely dwarfs Django and Python altogether, its the only choice really if you want to determine framework based on user-base (popularity). :) Excellent answer. Pylons 0.9.7 is almost released, the main issue being finishing the documentation. In the meantime, the Pylons Book is pretty complete and covers the RC version. It's an axiom of open-source programming that the last 10% of a release takes N months longer than anticipated. N = 5 and counting for Pylons, and it has been 12 for both Django and Cheetah in the past. Django's popularity is mainly due to superior marketing and documentation. They have a corporate backer and thus more people with those skills. Pylons' developers are mainly hackers/web programmers, who would rather build software than do marketing. So many people have not heard about Pylons or its voice gets drowned out. But Pylons has particular favor among those who like extremely modular tools, and those people have been coming to us. An interesting question is, why did [any framework's] users choose it? Django: - technical capability: same as Pylons/TurboGears. Not a reason to choose one over another. - design philosophy: build our own tools so it's well integrated. Some number of people like this. - completeness of toolset: if you need CMS tools, there may be some that are only available in Django and Plone currently. - tutorials: I read Django's docs and they were easy to understand. A lot of people cite this. - marketing: It seems everybody's using Django. or I didn't know there were any other viable Python frameworks.: A lot of people say this. Pylons: - technical capability: the same. - design philosophy: use 3rd-party tools when feasable, WSGI to the core: many Pylons' enthusiasts come from this mindset. - completeness of toolset: the basic stuff is all there and then some. - tutorials: it takes a bit of work to find the relevant documentation. For 0.9.7, the Pylons Book is your best bet right now. For 0.9.6, the official docs are good. - marketing: there will be a stronger marketing push after 0.9.7 is released and the new website is finished. Guido van Rossum has blessed Django here: http://www.djangoproject.com/weblog/2006/aug/07/guidointerview/ That was written two years ago. At the time Guido also hoped Django and Pylons would merge. I don't think he understood the situation very well at that point, because Django and Pylons can't merge without one of them giving up its fundamental philosophy. And the ascent of WSGI makes a merger less necessary: what's needed is interoperability. Django has had a weakness on that point, but it's gradually getting better as it moves closer to WSGI. In any case, Guido now understands that multiple frameworks are here to stay (like multiple GUI libraries), and each has its unique strengths. -- Mike Orr [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
