On 1/20/07, Christoph Haas <[EMAIL PROTECTED]> wrote: > > Hi, Jamie... > > On Friday 19 January 2007 03:04, Jamie wrote: > > I've been struggling to learn how to use Pylons and it's getting to the > > point that I'm about to give up and just use Django. > > Ewww... the dark side? :) > > > I need some advice on how to make this less painful. > > > > I've been a (professional) web developer for over a decade now and > > can't remember ever being this frustrated with learning a new trick. I > > started back in 1997 as a Perl guy. Then I moved to Microsoft ASP and > > then to ASP.Net. However, the .com crash then made it difficult to find > > work on large, ambitious web projects. ASP.Net was overkill for the > > corporate identity sites I was building to eat so I learnt PHP. Now I'm > > creating larger web projects again and feel like I'm wearing a > > straightjacket when using PHP. But I want to stay with open-source so a > > couple of months ago I began to teach myself Python. > > Although Python has for long not been a typical web application language I > think it has become an insider's tip. I assume that you are used to have > things more tightly coupled. In PHP there is a clear way to access a > database. There are a few helpers that deal with templates. But either you > need third-party components, too, or the tools aren't comfortable (e.g. an > ORM is way better than writing SQL statements). > > > I'm at the point now that I'm comfortable with writing productive apps > > in Python and am looking for a good MVC framework. > > My first rather large project (mentors.debian.net) is written in Python > solely by using the MySQLdb and CGI modules. I wrote pure SQL. I created > HTML pages from within the code just by using the nifty '%' variable > substitution. I tried to stay with tools that are mostly in the standards > library. Authentication and cookie handling was all done manually. And the > application is still far more readable than the countless projects I did > in Perl. But it can be better. I consider refactoring the > mentors.debian.net CGIs and replace them by a web framework. Pylons looks > promising so far. > > > I started with > > Django and found it reatively easy to pickup. However, one of the > > reasons it's easy is because all the components are so closely tied > > together. I decided to buckle down and try to learn Pylons because of > > how loosely coupled everything is and I agree with the WGSI philosophy. > > But having to learn Myghty/Cheetah (still haven't decided), SQLAlchemy, > > Paste, and Routes all at once sucks. Add in the lack of my Python > > background and things are overwhelming. > > For me learning most aspects of Python was rather hard. I wanted to find > patterns I know in Perl/PHP and translate them to Python. That didn't work > at all because Python has some programming concepts that are unknown to > the rather simple languages like Perl/PHP. Back in the university days I > had to learn Scheme (a LISP dialect) and Modula-2. (That has been in the > last decade and I must say I'm deeply disappointed about the junk you > learn there.) Nobody taught us about C, C++ and object-oriented > programming. So I just didn't understand certain concepts. Thanks to the > book "Beginning Python" I think I learned most aspects in no time. > > And actually the point why I love open source is that I can take any > component that has proven to work and glue it together to get a whole. You > wouldn't start writing a name server - there's Bind. Why invent a web > server for static files - there's Apache. Program a new database - or just > go with PostgreSQL or MySQL. You need to learn Bind to run a name server > and learn about httpd.conf to run a web server and even learn some SQL > (and knowing MySQL doesn't help you much when trying to use PostgreSQL). > That's what LAMP is all about. And I think this is what Pylons about, too. > You certainly need to learn about the components it uses but > > (a) Pylon tries to create a basic framework that glues the parts together > so that they work well together and > (b) if you aren't happy about a component it's more or less easy to replace > it > > Enough with the preaching. Yes, I've been playing around with Django and > Turbogears and Pylons for weeks in my spare time. I didn't like Django > because it seemed to be good for web projects that are 99% > content-management. You need the same things time and again. And Django > provides them. But do anything that Django isn't good it and it gets > extraordinarily hard. My impression of course. I find the approach of > Django a bit strange. Why have they reinvented the wheel? Were they > frustred too and felt that recreating the parts was easier than > understanding what others did? > > Turbogears looked promising. I was confused by a lot of FUD > saying "everybody's moving to Django anyway" but Turbogears was nice. > Especially the Mochikit integration since I wanted to play with AJAX. I > mainly didn't like that it used SQLobject and although you can use it with > SQLAlchemy some features wouldn't work with it. I have no real argument > against it. And the community is way bigger, too.
TurboGears and Pylons are very similar. I ported a rather large TG project to Pylons in a matter of hours. The model code (SQLAlchemy) and templates (Genshi) didn't really change at all, and the controller code refactoring was pretty basic. > Pylons was where the journey has ended so far. SQLAlchemy is nice (I now > only heard the rumors about shortcomings of SQLobject but also encountered > some myself). The templating with Myghty (or Mako) was very nice. I didn't > need to learn another artificial language like in Kid or (worst of all) > Django. It's just Python - the language I learned and want to use. It's > actively developed (which may make it hard to follow in real-life projects > that still need to run in 5 years - I don't know). And the people involved > on IRC are nice, too. (Even though everybody besides me seems to live in > Australia so nobody's talking to me during my common business hours. :) ) I'm surprised that you'd consider something like Kid or Genshi to be an "artificial language". The syntax they use is Python. The only difference really between an XML template language and a string template language is that the XML template languages integrate better with third party tools and they guarantee that everything gets escape properly and such. For me, it's conceptually very similar to the difference between writing SQL code with string interpolation versus using a library to do it correctly and automatically for you. > > Is there anyone else out there that is trying to learn this all at > > once? How are you doing it? > > I wasn't doing well. I'm the impatient type. Actually I'm not only > impatient but also a perfectionist (without a deadline). I'm trying to > find the perfect tool for any job so I can decide for one when it's time > for a new project. So I'm often wasting time trying all available systems > (Django, Turbogears, Pylons, etc.) and even reading many of other people's > opinions about those to make up my mind. It would probably be easier to > decide for one and see if it works out. But that's me. :) > > So I knew Python. But I didn't work with SQLAlchemy before. I didn't know > about Myghty. I hadn't heard of Paste before. And I was even scared to > work with a web framework because most of my regular clients run a site at > a common web hoster who offers nothing more but Perl as CGI, maybe Python, > MySQL and an FTP access. You can use SQLAlchemy perfectly well as just a nice wrapper around DB-API and write all of your SQL statements as per usual. It's good at that, and it works well for data models that aren't conducive to ORM. My needs are basically data warehousing and some pretty gritty reporting so ORM would really just get in my way. > Before the length of my mail grows up to math.infity: Yes, I know how you > feel. My suggestion would be to start with the tutorial to have some > instant success. Then as you need it dig deeper into the documentation of > each component. My personal learning curve was pretty flat because I took > the top-down approach. I started with as much knowledge as I had and once > I needed a new feature I looked it up in the appropriate location. It's > very slow at the beginning but later gets you on the track rather quickly. > The myghty web site for example is just plain evil. I don't need a syntax > diagram kind of documentation or a reference for kernel developers. Just > tell me the most frequently used features and how to use them. I have now > written a few parts of my new application. And when something works I'm > looking up some examples to find out whether there are better ways to > accomplish the same result. > > > My suggestions to the maintainers: You need to vastly improve the docs > > if you're serious about increasing user adoption; the QuickWiki one in > > particular. There are just too many statements along the lines of "see > > the official docs for X for more info". The bassakwards presentation of > > the QuickWiki is also confusing. A start-to-finish, step-by-step > > walkthrough on how to create a database-driven Pylons app would be a > > boon to the project. "If you're using Postgres, do A, B,C. If you're > > using MySQL do D,E,F". "If you're using SQLAlchemy do this. SQLObject > > do that." Just my two cents... > > Such an approach sounds reasonable for Django. And the Djangobook project > is a nice effort. But they have reinvented every wheel so there is nothing > they can refer/link to anyway. But imagine you are a web hoster who offers > LAMP. Would you provide a documentation to your customers on how to use > the database, submit SQL queries and how to program Perl? > > I second that Pylons needs more and better documentation. But the blog and > wiki tutorials are nice already to get started. They just leave you with a > lot of questions. What looks easy for someone who has worked with Pylons > or knows the other components Pylon uses is just confusing for newbies. > And that's also a problem of creating good documentation: the moment you > know all the aspects of something to be able to write documentation it's > hard to think as a newbie. Well, I doubt there is a way to document "the > right way" while Pylons is evolving and offers you to use different parts > (e.g. SQLobjects instead of SQLAlchemy or Mako instead of Myghty). > > My personal contribution might be > http://workaround.org/moin/PylonsCheatsheet which I mainly started for > myself. I couldn't remember everything when I started my first controller. > So from time to time I add something I learned there. After a week I knew > how to create URLs with h.url_for() and what 'h' stands for and where it > comes from. Perhaps one day I can contribute it with more content. Right > now it may look a bit ridiculous. :) > > Don't give up. Perhaps we'll meet on IRC? I didn't find the Pylons documentation to be all that helpful either, but on the other hand I found the code to make a lot of sense... and I already had working knowledge of most of the components I planned to use (WSGI, Paste, SQLAlchemy, Genshi, ...) so it was really just a matter of reading some chunks of Pylons code before I understood it. It was a hell of a lot easier to look at Pylons code than CherryPy+TurboGears. -bob --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
