On Dec 13, 2011 8:45 PM, "Mike Orr" <[email protected]> wrote: > > On Tue, Dec 13, 2011 at 1:59 AM, rihad <[email protected]> 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. > > 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.
Another thing from Pyramid that's frequently forgotten are its scaffolds. You can get some instant full stack framework gratification with scaffolds like Akhet or Khufu. However, for a newcomer the brand he's heard the most is Pyramid. I don't know if giving more prominence to these sccafolds wherever potential users start reading, and encouraging to quickstart magically with them, will make Pyramid less intimidating. > > -- > Mike Orr <[email protected]> > > -- > 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. > -- 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.
