On Mon, 2011-03-07 at 23:27 +0100, Jens Hoffrichter wrote: > 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.
Out of curiosity, did you find http://docs.pylonsproject.org/projects/pyramid/1.0/#tutorials ? If so, were they helpful? > 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. Do you have any suggestions about how to make it more clear that traversal is not the "right path" for ex-Pylons folks? They should almost certainly ignore traversal entirely, as their brain is more likely to be hardwired for url dispatch. We do write this in the docs but it appears to be largely ignored. > 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. We're still anxiously awaiting the release of "ahket" ( https://bitbucket.org/sluggo/akhet/overview ) which brings much more fidelity with Pylons-style apps to Pyramid, including Mako templating by default and "handlers" (which are basically Pylons controllers). > 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. Ahket has the "h" global already defined, although how to inject "h" is documented here: http://docs.pylonsproject.org/projects/pyramid_cookbook/dev/templates.html > 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. You'd be happier with request.route_url likely. I think it's used by the tutorials. > 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. We do more work at startup time to avoid work at runtime, so this is unlikely to change soon. > 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. http://docs.pylonsproject.org/projects/pyramid/1.0/narr/project.html#modifying-package-structure > > > 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. I think mostly what you're experiencing is "normal" for some definition thereof. Some of it is already solved by Akhet, which I hope we can get released soon. Your foray into traversal probably couldn't have been helped (I assume it's less interesting than you thought it would be) without removing it, but folks do rely on it. > 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. Thanks, your feedback is appreciated! You're not alone in expressing these types of opinions, and we'll work to make the docs better as a result. - C -- 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.
