FWIW when I select software to use, I am usually not interested in all the academic arguments about it's structure, mainly because I don't understand them! I go for the one that has loads and loads of complete working examples, not just the odd snippet. If Pylons is to win people over, I think it must have a very extensive set of complete working examples, particularly in the use of Ajax. When I say 'complete', I mean everything necessary to run the application which includes sample databases, which are so often left out. To demonstrate my point, I tend to use the YUI Ajax libraries simply because there are loads of well documented examples which work, I am not interested if JQuery is in theory superior.
On 31 Aug, 20:32, Mike Orr <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
