On 1/19/07, Jamie <[EMAIL PROTECTED]> wrote: > I am a very experienced, professional web developer who is trying to > learn to use Pylons and am finding the process excruciatingly painful. > The biggest problem is that the docs seem to assume that I already know > how to use SQLObject/SQLAlchemy, Myghty/Cheetah, Paste, Routes, etc. > Or, just as bad, there are too many references to said components' > official docs, rather than thoughly explaining how to use them within > the Pylons docs. Yes, it may be a bit redundant to repeat info on the > Pylon's site, but bouncing back and forth between various projects' > docs is a bit overwhelming. > > I'm an ex-Perl, ex-Microsoft, and a soon-to-be ex-PHP developer who is > looking for a good Python-based framework. I've looked at both Django > and TG as well as Pylons. The reason I'm sticking it out with Pylons is > that I like how everything is loosely coupled. It will give me a lot > more flexibility once I learn the system. However, I'm wondering if the > learning curve is too steep? Because there are so many ways to work > with Pylons, the project's docs need to be outstanding and very > comprehensive. As they currently stand, the docs are far, far behind > either TG or Django. > > Specifics: > - The QuickWiki tutorial sucks. The bassakwards presentation is > thoughly confusing; it should presentated as a start-to-finish example > how to build a data-driven web app with Pylons. I don't want to be led > by the hand through someone else's code; I learn better by writting my > own code.
But if you skip the SMALL section 2, that's exactly what you get. Some people think inductively (learn the parts and then the whole, as you're suggesting), others deductively (see the whole first and then learn how the parts fit into it, as I do). I like the way the tutorial gives the choice of either, and also accomodates those who want to evaluate Pylons based on the prebuilt demo without spending time writing code (or dealing with code that doesn't work). > - Don't assume that your readers are already familar with MVC > frameworks, or heck, even know all that much about Python. Django in > particular is really good about being accessable to lesser experienced > Python web developers. > - Explain why I might want to use SQLObject vs. SQLAlchemy or > vice-versa and give me example of how to do the same thing using both. > I understand that the decision boils down to personal preference, but > as a developer who doesn't know either, *any* bit of advice would be > helpful. These are all different audiences and require different documentation. Most of Pylons' early adopters came from a similar MVC Python framework, so they mainly want to know how Pylons is different. But there are also advanced non-Python web developers like yourself, Pythoneers who haven't done much web work (Guido v R), non-Python programmers doing their first web project, and non-programmers doing their first web project. Targeting the last would lead to a 150+ page book that would be just too big for most users, and run the risk of going out of date quickly. It's a better task for a book publisher than for little oi' us. But you're right that we should have better background information somewhere on what an MVC is and how Pylons fulfills the requirements, and a detailed "choosing your libraries" type of page. Re installing a template engine, they are all close to the Kid example. The main difference is what options the engine accepts, how to specify a template (most engines use 'package.module' notation instead of Myghty's URL-like syntax), and how to handle fragments. I wrote about installing Cheetah at http://sluggo.scrapping.cc/python/pylons/pylons-cheetah.html Re SQLObject vs SQLAlchemy, my impression is SQLAlchemy is more stable, more thoroughly documented, and more flexible at this point. You can use it on three levels: 1) Use the connection pool and write your own SQL statements. 2) Use the SQL builder tools too. 3) Or use the high-level object-oriented layer. SQLObject is mainly geared toward level 3. I found level 3 in both libraries a steep learning curve, maybe too much learning for what it's worth, and more magical than I was comfortable trusting. So I went with SQLAlchemy's level 2, and plan to use level 1 in some existing projects for the auto-reconnect feature. But sometimes I come across ways level 3 would be useful, so I may buckle down and use it someday. As to whether to use either library or MySQL/PostgreSQL/SQLite directly, use the library. Bare DB-API requires too much boilerplate code (execute + fetch, creating cursors, working around the lack of auto-reconnection, etc). Re MySQL vs PostgreSQL vs SQLite, one of the joys of SQLAlchemy/SQLObject is you can try all three and choose the one with the best reliability/performance in your situation. This requires some care because each server has slightly different capabilities and SQL syntax. The SQL builders and OO interface hide the differences to some extent but not completely. If your organization is already using one of the servers, that would be a good choice. Watch out for high memory usage in SQLite with large or search-intensive databases. MySQL is optimized for read speed, but you have to use the non-default InnoDB type if you want transactions. -- 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 -~----------~----~----~----~------~----~------~--~---
