On Tue, Dec 13, 2011 at 1:59 AM, rihad <ri...@mail.ru> wrote: > > > On Dec 13, 6:55 am, Mike Orr <sluggos...@gmail.com> 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. > 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.
This is a longstanding debate that goes back several years, whether Pyramid (and Pylons 1) is the right size or too small. You're right that many users want the framework to choose a form/javascript/ORM/CRUD/authentication/etc library for them, and that this is a major reason for the popularity of Django, TurboGears, etc. Pyramid is a new project, and its tutorials and add-ons are still being written. As Chris said, we want all those things to happen, but *outside the Pyramid core*. In autonomous packages not constrained by all of Pyramid's rules and release schedule, where multiple developers can offer different and possibly contradictory solutions. The type of form library is a good example. Two schools of thought exist: (1) automatically generate a form based on a data model, (2) allow the user to override and customize how each form element looks and where it's placed. FormAlchemy is the former; FormEncode/WebHelpers is the latter. ToscaWidgets is a larger example of the former: by adding more features and Javascript plugins it becomes significantly bigger and more complex. All of these features are a positive for some people and a negative for others. If a future Pyramid/ToscaWidgets bundle (TurboGears 3) exists someday, it would please some users. But others would be turned off, and others would find it *difficult* to express their application's requirements in that system. If Pyramid offered ToscaWidgets in the core, those users would have to painstakingly work around it, and would have to suffer several large dependencies which they're not using. But by pushing the decision to a higher level, Pyramid pleases both modular-favoring users and full-stack favoring users: everybody except those who wish the full stack were in the core. We're trying to offer a different framework *paradigm*: one where high-level frameworks are in super-distributions, and you can choose from more than one of them. By lightweight I mean a framework that has only the bare essentials for request processing: query parameters and the like, and maybe a session interface. The small frameworks I mentioned went that route. I used to use Quixote because of this: I liked the fact that I could print out the entire source and read and understand it in half an hour. But I got tired of writing and maintaining my own template interface, database interface, session persistence, and authentication. (This was before Mako, SQLAlchemy, and Beaker existed.) I wanted to use plugins written by experts and maintained by a community. That led me to Pylons, which had more of these things built in. But I also valued ultra-modularity, so I could not choose Django, and TurboGears was in too rough shape then. But TurboGears created an innovation which has benefitted all frameworks since. Originally it was a "decide-for-you" framework. Kid templates, SQLObject ORM, and I forget which Javascript library. But *ALL* of these became obsolete, out from under the framework. Even from the beginning, many users wanted to use Cheetah templates rather than Kid. (Kid was similar to Chameleon; Cheetah was similar to Mako.) So TurboGears invented a template front end called Buffet, which allowed different template engines to plug into the framework. This pleased everybody: those who wanted an official template engine, and those who wanted alternatives. Buffet was ported to Pylons 0.9.7, and a simpler version of the concept was ported to Pyramid. So you see, if TurboGears had rigidly stuck to its original decisions, it would be stuck in obsolete-land and would never have taken off. If you have specific questions about which libraries to use on top of Pyramid, such as which form library to choose, describe what kind of form API or "workflow" you expect, and we can suggest something the most similar. Do you just want a quick-and-easy form based on an object-oriented model? Do you want to control precisely how the form looks? Do you require Javascript, or do you have external Javascript you want to integrate? All these point to a different subset of form libraries. -- 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.
