I think there may be some tension between the desires of people building things with Pyramid (like a theoretical TurboGears 3).
There's one camp of people who just want different defaults (a different traverser, a different templating language, a different source code layout, etc). But they don't really want to build an *application*, they want to configure Pyramid as a slightly different framework more to their tastes. There's another camp that wants higher-level application features, something that, when you run it, shows something useful in a browser. Such a thing might require dependencies on SQLAlchemy, or Mongo, a dependency on a particular form framework. It might create a default "admin" interface, or a small content management system, or whatever. But it'd have an *application* component, not just different frameworky defaults. It'd be a good idea for the folks in each of these camps (to the extent that you're not in both) to try to work out exactly what it is they want, and perhaps split into two teams. One might build on the others' work, or might not. Personally, I'm in the "application features" camp. I don't really want different defaults, or more frameworky bits for the sake of distinction That's easy for me to say, because the defaults already suit me, I understand why you might want others though. But I'd rather have a higher level thing built directly on Pyramid that "puts pixels on the screen" out of the box. Such a goal might require the creation of a bunch of related frameworks, but the frameworks would be developed with the goal in mind of creating a "pixels on the screen" end user application that someone could run and get benefit from without doing any heavy development. (By the way, it's "Pyramid", not sure how the pluralization crept in.) - C On Tue, 2010-11-09 at 14:26 -0600, Tim Black wrote: > On 11/09/2010 12:32 PM, Christoph Zwerschke wrote: > > Am 08.11.2010 21:18 schrieb Tim Black: > >> Get Pyramids | Need more? Get TurboGears > > > > The "more/less" dichotomy may be somewhat misleading, though. The top > > layers will certainly add features and functionality, but on the other > > hand they will also hide some of the lower-level features and > > complexity, e.g. by providing object tree dispatch so you don't need > > to deal with manual dispatch rules and contexts. In this sense, people > > want to choose the higher-level layer because they actually want less > > (of the lower-level complexity), not more. Letting the top layer > > provide reasonable opinonated defaults is also because people normally > > want to have less (decisions to make), not more. > I agree fully on this, and I can see that if someone new to Pyramid > comes along and sees the word "more," they might think, well, I don't > want more work, I want the easiest set of defaults to start with, and > they would end up picking Pyramid when they probably really wanted > TurboGears. So the words "more" and "less" probably aren't the clearest > way to give people initial advice about which framework to pick. But I > think some simple presentation of two recommended options would be a > good idea. > > Maybe we can find some other simple terminology that will express the > difference clearly. Iif the terminology went into the frameworks' > names, maybe they could be "Pyramid Core" and "Pyramid Full-Stack." > "Pyramid Core" is fairly clear, but "Pyramid Full-Stack" might not be > clear to someone who doesn't know web frameworks, and maybe isn't even > accurate, if "Pyramid Core" qualifies as a full-stack of sorts. > "Pyramid with Batteries" might work, but fails to indicate that it > provides recommended defaults that simplify your work. "Turbo" > expresses the latter idea well, and "Gears" expresses the "batteries > included" idea, so maybe "TurboGears" is a good name to retain. Or > maybe there's an architectural term that would be suitable--"Pyramid > Base" and "Pyramid Peak." Um...Pyramids on Rails? But the pyramids are > from the ancient world, and from Egypt, and trains are from the > industrialized 1800's. Some other ideas: "Pyramid Focal," "Point," > "Keystone," "Apex." "Hyper Pyramid?" > > Or the distinction could be kept out of the name (who wants to change > their favorite framework's name?) and just expressed in adjectives or > comparatives: "more/less," "basic/extended," etc. But then, I suppose > it's wise to consider that comparisons are the stuff of flame wars. But > I think there's some hope that presenting a well-conceived and > well-expressed distinction up front could head off some of those flame > wars from the outset. > > Tim > > -- 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.
