On Mon, 2011-02-14 at 18:02 -0800, Jonathan Vanasco wrote: > I spent some time today with Pyramid. It was a bit of a rollercoaster > -- at times I was very excited, at others very stressed. i figured > i'd share my thoughts here for the maintainers.
Thanks. > 1. on setting up an app, there were no instructions on how to setup > for a postgres 'url' in sqlalchemy ; in fact - there was nothing in > there regarding this setup. i pulled it out of an existing project; > one could probably look at pylons 1.0 (not pyramid) docs. > > 2. i assume this is part of the template designed to show how to do > stuff... however creating the initial 'models' table, with a sample > entry, is misleading and not clear. i'd suggest changing it to > "sample_model" or something that is very clearly not needed for the > application. I assume you did not find the SQLAlchemy-based tutorial here: http://docs.pylonsproject.org/projects/pyramid/1.0/tutorials/wiki2/index.html > 3. i haven't figured out yet if its possible to handle multiple db > connections in pyramid. in pylons i have "sqlalchemy.write.url" and > "sqlalchemy.read.url" and handle multiple databases due to master/ > slave clustering. in order to get widespread appeal, something like > this needs to be very apparent and easy to do - Rails accomplishes > this in a few lines of configs. It's possible I'm sure. Pyramid doesn't care really. It's ignorant of SQLAlchemy. There should indeed be documentation that describes how to do this though. > 4. i'm not sold on the MV design. personally, I think it was risky > departing from MVC, which has become the de facto standard and super > familiar for developers across the web. django has had issues selling > people on their MVT , and its just an uphill battle. i'm sure it has > many advantages, i'm just speaking from a 'marketing ' view. We didn't depart from the design, just the acronym. > 5. the default application template should really generate a multiple > views & models structure. most people i've worked with strive very > hard to keep the entirety of their models/views from being a single > file. We chose to do that and document how to turn these into a package here: http://docs.pylonsproject.org/projects/pyramid/1.0/narr/project.html#modifying-package-structure . We could have done it in reverse too but did not. > 6. also on the migration point, it would be good to discuss sqlalchemy > reflection. Integration documentation is important, yes. We don't have enough of it. > The code looks solid, and I understand the rationale behind a lot of > design choices... but from an adoption view, i think there's a lot of > work to be done. There always is. Thanks for the thoughts, - 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.
