For me, many points of this discussion apply. And I'll try to put it in a way to fulfill Jens' original question. That is, arguments for and against TG and web2py. First off, I have not yet looked into web2py at all. Honestly, today marks the day that I first even heard about it ;) But two importand points emerge from this thread without even looking at (or knowing) either. These two points are:
- Documentation - Database interface I am sure that there are other prominent differences, but I do not like to guess. So I'll try to digest the information I read in this thread and inject some of my own thoughts. As said, I am not familiar with web2py, so I'll keep it short on that end. Documentation =========== Documentation has two main audiences. Newcomers and - let's call them - veterans. For newcomers it's extremely important to get to grips with a new system quickly and without exposing too much of the inner- workings of the framework. That is something that can be picked up on- the-go. Frankly, TG's documentation is mediocre. Out of boredom/ curiosity/..., I decided to work through the quickstart tutorial yesterday and found it not working. I consider myself very familiar with Python and (maybe to a lesser extent) TG so I was quickly able to solve the problems. Newcomers are surely put off by something like that. I have not yet looked much into the docs about TG2, but I remember those of TG1 quite well. One thing that is very important in *any* web- applications are forms. Diving into forms in TG can be quite daunting especially if you go into form validation. The trouble comes from TG's flexibility as you can work pretty much the way you like. In my opinion TG is missing some "Best practices" in this area (and others). The Wiki Tutorial (if it's working), gives you all that is necessary to get you started. But after that it feels like there is a large black hole somewhere sucking in all the important information. Some people recommended me to just "look it up in the source code". And at first I thought: "You can't be serious!?" Coming from a PHP background where the source code of many FOSS projects is a big jungle infested with spaghetti monsters, I really did not intend to even *start* looking into the code. Eventually I gave in and did it anyway and boy was I surprised! The code looks clean and is very well documented. Thumbs up for that ;) This is a very cool thing for the TG "veterans". Not so much for newcomers. >From the earlier posts in this thread, I gather that this is an area where web2py definitely has a big advantage over TG. The way it sounds, web2py is very straight-forward to use as it's documentation does not get in the way. This is very cool for newcomers or people that try to evaluate the framework and compare it with others. After you have the overview of how the components are strung together, it all boils down to reference. This is something I cannot elaborate for web2py. Only people that have been working with it for a while can give valid feedback. That rules me out ;) As for TG, it's not all too bad even. As TG builds on other well known frameworks, you can rely on the docs from these. For me the two most important references here are that of the database abstraction ( SQLAlchemy in my case) and the webserver (cherrypy). The docs of SA are amazingly complete. And well explained. So, many thumbs up there! On the other hand, the docs of CherryPy are so-so. You can figure out most of the details, but more advanced features show more gaps (see the end of the following document for example: http://www.cherrypy.org/chrome/common/2.2/docs/book/chunk/ch03s03.html#id3507420). But that's not TG's fault/problem. When it comes to looking at TG, as I said earlier the source code is clean and well documented. So with only a little bit of digging you can find all you need. But then again, TG adds a dash of abstraction on top of the existing frameworks. I'll note the "expose" decorator and TG2's "DBSession" object as examples. Unfortunately, the differences between the original framework's concepts are not well documented. And even after working for a while with TG now, they are a mistery to me. I have the gut feeling though that TG2 will do much better. Also in the documentation. Database interface ============== As has been mentioned already, the importance of this element depends strongly on your needs. A long while ago, I started to redesign an old web-page and considered to give Ruby on Rails a try. That was short lived. At the time, the database boasted a whopping 86 tables. And it's growing. In that database I've got a lot of natural pkeys (some of them composite), and also quite a lot of surrogate pkeys. Putting that in a framework as restrictive as the RoR one was a no-go. Enforcing that each table has a "id" column posing as primary key was the first show-stopper. But we're not here to discuss RoR. But from what I see, web2py makes the same assumption. Don't get me wrong. This is not necessarily a bad (or evil) thing, it solely depends on your needs. As for my pet-database, I had no trouble at all to get it working in SQLAlchemy. A *very* important thing here, that most ORMs silently ignore, are relations with attached attributes. Consider the classical example of invoices ( [user] [orders] [item] ). Now, a user can surely order an item n times. One way of modeling this is as follows (i'll put primary keys in brackets): User( [user_id], fname, lname, ... ) Item( [item_id], label ) ItemOrder( [user_id, item_id], amount ) This shows a many-to-many relationship (ItemOrder) with an attached attribute (amount). Modeling this in SQLAlchemy was very easy. And it's a very common situation. How well web2py handles this, I cannot say. On the bottom line though, as already said, it depends on your needs. If you only have straight-forward tables and relationships, that is to say, simple one-to-many and man-to-many relationships without attributes, and not table inheritance, then it's safe to say that it does not matter what ORM you use. All of them can handle this very well. Bear in mind though, that over time the database might grow. We all know this, the client inevitably will change his requirements or come up with new ideas and you need to adapt the software. This can very easily reach down to the database level. If right now, your model looks simple and easy, in two years time this might not be the case anymore. If the ORM you chose cannot handle upcoming model changes you're in for a treat. If however, you can say that the requirements of your application are rock-solid and won't change in the future than you can go for more restrictive (and thus simpler) solutions. It all depends on the size of your application. Something else to bear in mind: As already mentioned in an earlier post, the more of your model you get into the database, the more robust your application will become. As a side-effect the application- logic code will be much simpler. Triggers and properly configured foreign key constraints can be a boon to every application. But also table structure affects the resulting application code a lot. With natural keys (even if composite) you can even avoid some SQL joins while still retaining all required data. Finishing thoughts/Summary ===================== Whether to use web2py or Turbogears depends largely on application size and scope. The way it looks to me, web2py is good for small inert projects, and TG offers all the flexibility in the world needed for large-scale apps. Additionally I beleive it still worthwile to start even small projects using TG. Primarily because you will be prepared for unexpeced changes in the application. While writing this, I skimmed through the web2py "cookbook" tutorial, and a few things popped into my mind. First, why make the tutorial only available in PDF? Plain HTML would read so much easier, but that's only my opinion. What's worse, the tutorial defies good code style for python. Mainly because it collapses some lines into one and leaves out too much valuable whitespace which makes it harder to read. Also, it uses a funtion "T" for i18n translation. Why a *capital* "T"? Why not use the widespread "gettext"-standard and name the function "_" ? These are only minor glitches I saw, also I only looked briefly under the hood so I ask myself: "Are there more of these surprises?" I am a big fan of standards (whether exmplicit or implicid). They are there for a reason. Use them! I think greenpoise's posts make it clear, that TG2 easily scares off newcomers. If you don't have the tenacity to really "dig in" you'll be disappointed by TG. But if you *do* dig in (which for me is always the fun part) you get to see the hidden beauty and coolness of TG :P I hope I made sense and was not too biased. I can only repeat that I do not know enough about web2py to make a fair judgement. Please keep that in mind! If anything I wrote is incomplete or even totally wrong, I'd be glad to hear Massimo's comments. I beleive his comments it would benefit Jens a great deal as well. As I'm too lazy too proof-read this chunk of text, I'll just blindly click on the "send" button right now. So my apologies for nonsense sentences ;) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" 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/turbogears?hl=en -~----------~----~----~----~------~----~------~--~---
