On Wed, 2007-06-27 at 15:23 -0700, Cliff Wells wrote: > On Fri, 2007-06-01 at 09:57 +0100, James Gardner wrote: > > Ben and I have started thinking again about what really makes Pylons > > different from other web frameworks and how we can best highlight those > > differences in the Pylons marketing to help attract people to the > > community and see Pylons gain further recognition and adoption. >
Something that touches on both the organization and fast information aspect that I think Pylons currently lacks has to do with the fact that Pylons explicitly avoids "one true way to do it". This is fine as a general philosophy (and I appreciate it) but it presents new users with too many decisions to make before they can write a line of code (and often before they know enough to be able to make such a choice). When a new user comes to Django, there's very little question about what database adapter to use, how to use *that* particular adapter (something that is a big hurdle for SQLAlchemy, given the myriad ways to interact with it), what template engine, middleware, etc. This is undoubtedly why GvR endorsed that particular framework (it fits with his overall philosophy). It's also one of the driving philosophies behind RoR (frameworks should be opinionated). I'm not suggesting that choices or flexibility be removed, only that the secondary choices be presented as such. Make it abundantly clear to the new user which set of choices is preferred or most widely used. The best way to do this is by omitting the alternates from the main text and presenting them as addendum. I think a reorganization should start with a recommended set of components (SA [with or without ActiveMapper], Mako, AuthKit, etc) and provide complete documentation and examples for *just* those components. Choices don't have to be presented every step of the way, nor should examples using different components be presented together. Once this main section is done, extra sections can be added elsewhere covering the alternatives. I think enforcing "one true way" would be a detriment to Pylons, but not having an opinion about one is just as bad. As far as SQLAlchemy goes, there is obviously extensive documentation on their site. However all of it is presented outside the context of Pylons and much of it is presented in a way that makes it difficult to understand how to use their examples with what is presented to the user in Pylons. That being the case, I think the Pylons site needs at least a short section devoted to SA and how to use it effectively within the framework. AuthKit suffers the same issues (too many choices too early in the game), so if it's to become the default auth/access control layer for Pylons, then some work should be done to present how it's to be used for the general case (something like TG's Identity) within Pylons. Regards, Cliff --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
