Hello everyone, I have already (though infrequently) posted to this mailing list, but just to give a short overview of myself: I have been developing in Python for nearly 10 years now, have written big and small web applications using Myghty and Pylons. In Pylons, I have made the upwards transition from 0.9.6 upwards, though we (my company) are still supporting 0.9.6.2 applications, we have also 0.9.7 and 1.0 Pylons applications running, and are actively developing in most of those.
Just to give a short background where I'm coming from, and where my pyramid impressions come from. Tonight, I had time to look a pyramid for the first time, and I wanted to share my first impression, to help improve the project. I have started by reading the pyramid documentation first. I haven't read all of it, I skipped the more advanced topics towards the end, but at least scanned them, and have read most of the beginning chapters. The first impression was, that the whole documentation is very complete, but quite abstract. I'm coming from a Pylons background, so I tried mapping my experiences onto pyramid, and a lot of things look similar, but 'feel' different. For me, something was lacking like, "if you are starting a new project, you might want to look at the topics a) d) e) and f)". Even after reading most of the documentation, I was still lacking a clear picture what was required for starting a new project, so I decided to 'get my hands dirty' and start something simple: I needed a simple site which would just store the results of a form into a database, either creating a new db object, or updating an old one, using some sort of simple authentication in the form itself. Nothing fancy. We are using FormAlchemy for the more modern projects, so I decided to use that as well, and of course SQLAlchemy as an ORM, so I decided to put my knowledge to good use, and dove in. At first, I created a new project using the pyramid_alchemy template, because the traversal approach from the documentation sounded interesting. I took a look at the models.py, and the __init__.py, started the paster.....and had no clue how the different pages were addressed, when which of the views was called, and how the distinction was made. After a bit more of digging, I understood that it was all related to the MyApp() and get_root() statements in the model, but I still don't understand how the distinction is made when the MyApp view is called, and when the MyModel view is called, and how the routing there works. It may look nice that something is mapped under /1 in the project url, but most probably that is something a bit bigger projects wouldn't use. So I deleted the project, and started again with the pyramid_routesalchemy template, as it might be more familiar. And it was, I haven't used the SQLAlchemy declarative layer yet, but that was easy enough to understand. That the project did initialize the database with some values on initial startup is really unnecessary in that template, IMHO, as there is no way to view the data written in the database anywhere, and I'm not going to write an example view, just to view the example data anywhere. That was one of the first things I deleted in the project ;) It might be okay with an sqlite db, but once I start using a more advanced sql engine, that will definitely get in the way. So, I created my model, configured my forms, did some basic HTML layouting for the page, and the next hurdle was that only the HTML source code of the form was printed, instead of the proper rendered form. Luckily, I knew that from my more recent Pylons experiences, and I knew I had to use webhelpers.html.literal() for that. But how to get the webhelpers into the template (I was using the default Chameleon templates here)? In the normal Pylons Mako templates I have always h and c available, where c isn't necessary in pyramid anymore, as I have the returned values from the view there. After quite a bit of digging around in the pyramid (which has 0 on that topic), and chameleon docs (which has mostly BNF as a documentation, as far as I saw), I found out that I could use something like this inside the template: <div id="main" tal:define="h import:choosecourse.helpers"> I added a helpers.py, where I imported all my usual webhelpers into it, and then had literal available in the template. The next problem was: How to generate the URL for the form action? Again, the pyramid docs weren't very helpful in that regard, until I found route_url in the API docs. I'm still not too sure how to add all the parameters to the URl, and always having to pass the request into the function will get a bit annoying quite soon. But maybe I am missing something there. Another thing I noticed: Syntax errors are a lot harder to debug in pyramid than in Pylons. In Pylons, the controllers are only imported at request time, so a meaningful error message can be generated by the debugging tool. In pyramid, the paster refuses to start, and I have to take a look in the logs to find the cause of the error. Which will get annoying soon as well, as I normally have my editor on one screen, and the webbrowser on the second one. If I have to switch frequently to the log, it will be quite a nuisance. Something I missed as well were some examples how to structure a bigger project. We have projects running which have a dozen Pylons controllers, with maybe 100 actions throughout all of them. The basic Pylons package offered at least some sort of basic structure which you can build upon. This is something I miss in both the documentation, and the example packages. So much about the experiences, now my personal, biased opinion: At the moment, after playing around with pyramid for a couple of hours, pyramid feels like another step back for the application developer. It might be better designed from a framework developers POV, and it might add more flexibility for all sorts of extensions. But the path which I have already described in this thread http://groups.google.com/group/pylons-discuss/browse_thread/thread/9197756173fd552/a4e63727c14a2e1a seems to continue, with removing more and more of the core features, either deprecating them, putting them in extensions, or changing the way how to use them around more. I know that it has benefits if you are not fixed on something (like use this ORM, use Routes, use jquery for your webhelpers), whatever, but it really creates a big hurdle in starting out a new project. Pylons/Pyramid was always more 'talkative' than the Rails DRY (in how much code you have to write for some sort of things), a couple of things have been mitigated by things like FormAlchemy, but the general impression is that is is getting worse, with how much code you have to write to achieve certain functionality. I'm really not sure about my conclusion about pyramid yet, I still think that Pylons 1.0 is pretty much complete for us....IF the big memory consumption in a production environment wasn't a problem, as well as sometimes the performance is much worse than in other systems. I will evaluate this further, but I wanted to at least give feedback and share my impressions with the developer community. Regards, Jens -- 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.
