On Sun, Aug 30, 2009 at 2:32 PM, cd34<[email protected]> wrote: > > I've developed code on the web since the 90s from cgi to mod_perl to
Thanks for your detailed user report; this is exactly the kind of thing we need to identify deficiencies in the documentation and marketing. > The documentation for almost every open source project leaves a lot to > be desired. Pylons is no different. Certain examples are well > documented, but some documentation is clearly written by a programmer > and is almost a dump of the API with a comment thrown in. There are clearly holes in the Pylons documentation. I'm working on beefing up the Routes and WebHelpers docs. It's been slowed by the switch to Sphinx: it takes an inordinate amount of time to decide how to organize things in a new structure, especially when you want consistency across projects. The other time-consuming part is documenting the soft-deprecated portions: it takes more time to explain route memory and minimimization clearly than to write the entire new portions, even though we're trying to phase those out. (One option would be to not document them, but this would be unfair to those maintaining existing applications.) So I'm hoping to fill these two holes in the next month or two. > Even the > authentication as mentioned in the pylons book and the wiki contains > multiple comments showing some of that frustration. The problem here is that Pylons has drawn a line in the sand, putting some aspects like auth outside its official responsibility. This has become less and less tenable as users see it as a basic feature of a framework. I think the solution here is some good third-party application templates, such as the one posted yesterday. > Documentation of deployment in various situations and recommended > deployment strategies is difficult to find for Pylons. A plain > vanilla example is linked from the first page, but, not everyone wants > to use Apache. There are people with certain hosting situations where > Apache won't work as well for them. I don't follow this closely but I know people have been putting them in the wiki. Perhaps users aren't finding them and they need more prominence. Also, the new Pylons website has a "Snippets" section (http://pylonshq.com/snippets) that's meant to be a collection of small recipies -- it just doesn't have the recipes yet. I suspect most would-be writers don't know it's there. I personally get most of my information from the mailing list, by reading it over time. It's also easier to answer a question on the list than to make a wiki page. I realize this doesn't help the long-term documentation situation as much, but that's the way it goes. Fortunately the Google Group is more searchable than, ahem, SourceForge or Mailman lists. > The quickwiki example is a stroke of genius. Credit goes to TurboGears for this. They were the ones who first came up with a "20 minute wiki tutorial". > Frankly, the 'Why use Pylons' text is so generic and regurgitates the > same text that almost every project uses to say why you should use > them. And improving that text is precisely what this thread is about. > From what I've seen, Pylons stories barely hit the radar and Django > stories are more frequent. Hopefully this will be addressed in the medium term when Pylons 1.0 is released. > While I don't believe it should be a huge factor, the fact that Django > runs on the app engine and Pylons doesn't is probably adding to > Django's appeal among many. The App Engine team initially endorsed Django and did a lot of work porting a subset of it to App Engine, while incorrectly saying it was "easy" to run any WSGI framework on App Engine. This all worked to Django's favor. Anecdotally I've heard it took a lot of work to get the full Django to work on App Engine; similar to the problems Pylons has. Django just has enough people motivated to work on this particular aspect to finish it. Pylons apparently does not at this moment, and the Pylons devs certainly don't have time to do it themselves. > To me, Pylons isn't always going to be > the right answer for a project. If I were writing a blog application, > I would be much more inclined to write that using Django than Pylons. > If I were writing a forum application, I would probably choose > Pylons. While I prefer Pylons' paradigm, there is a slight 'overhead' > to writing Pylons versus Django. Erm, maybe. I would use Pylons for all of these due to the flexibility factor. Except for apps that are so CMS-like they would benefit from Plone. -- 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 -~----------~----~----~----~------~----~------~--~---
