On Tue, 2011-12-13 at 01:59 -0800, rihad wrote: > > On Dec 13, 6:55 am, Mike Orr <[email protected]> wrote: > > Pyramid is a mid-level framework like Pylons. For a > > lightweight framework, see web.py, Aspen, Quixote, Flask, Werkzeug, or > > several others. Pyramid's focus is on being scalable, both down and > > up. You can make a Pyramid application and launcher in a single script > > file. Or you can build an elaborate full-stack framework on top of > > Pyramid, or use an off-the-shelf one. With Pyramid there are multiple > > ways to do it, but they are all interoperable. Our goal is not to > > force everyone to a mid-level framework, but to provide such good > > building blocks that future high-level frameworks choose Pyramid as a > > foundation. > > > > -- > So it's a perfect tool for writing a framework :) > Lightweight in my understanding means few features, mostly glue code. > Just like Pyramid. All other meaty, but nonetheless important > features, are meant to be chosen by a developer using that framework, > and plugged in. For example, AFAIK Pyramid has no Form/validation > subsystem in its core, or even an "official" plug-in that it endorses.
You are presuming that there is a one true form library that does everything well that is completely satisfactory in all cases. I can tell you from pretty hard experience that this is not true. To the extent that I recommend a single form library, I tend to recommend Deform because a) I wrote it and b) it's a Pylons project. But I always qualify my recommendation of it with "it's great for autogenerating forms, but it's not so great if you want pixel-control over the layout". For that, I tend to recommend pyramid_simpleform (also a Pylons project). These choices are not canonized in Pyramid or in its core narrative documentation. That's because both Deform and pyramid_simpleform are written for particular purposes, and neither is good for all use cases. That may change in the future and there are lots of other form libraries that might be better in any given scenario too. If you ask here or in IRC people will help guide you in the right direction. There should likely be more info in the Cookbook about how to make this particular choice, and we could definitely guide people towards it better without having to ask, but Pyramid itself won't ever make it for you. > Through trial and error, you have to just pick the missing part from > the plethora of what's available, that would suit you functionally and > esthetically. Maybe in the long run this would make you a more savvy, > professional developer. But you'll have to agree with me, that if our > goal is to build bigger, less buggy programs, we're gonna have to > abstract from smaller details, use bigger bricks, so to speak. You want direction; folks who use Pyramid are happy to give it to you if you ask. I spend lots of time trying to contextualize integrations for people both on IRC and in documentation, and others do the same. As far as building things using bigger blocks, I understand that people want this very badly. Although Pyramid is not in the big-block-selling business, someone else is always willing to sell you bigger blocks. And that's great. The blocks don't always line up evenly with your expectations or even sometimes with reality. And sometimes that's OK because, let's be honest, your expectations and reality kinda sucked anyway, and at least you can have some fun bitching about how much building this system out of these blocks that don't fit into the holes in your application with other folks that were also sold the same blocks. And your application kinda sorta works and that's often good enough. But sometimes smaller blocks are just what the doctor ordered if you really need it to work well, you actually know what you want to do, and you're willing to seek consultation from trusted colleagues about how to do it. > That's > why people have chosen C, not assembly to write most parts of a larger > OS; PHP, Perl or Python over C for web work, Frameworks over plain > PHP, Perl or Python to facilitate building even larger programs. And > that's because a human, however smart he or she is, cannot hold all > the miniscule details in his head. People can see the bigger picture > more clearly. Whew, I'm glad you're not describing something obvious in the most condescending way possible. > as it is now the learning curve of getting the needed tools > and do some CRUD/DB/auth/form edit/add, lists/pagination with some > custom functionality - is pretty slow. And so be it. Instant gratification "look ma wow I made a Wiki without even trying this is so cool" is not a goal of Pyramid itself. But it's your right to believe it should be, and nobody can take that away from you. ;-) - 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.
