Being the one who started this thread, I wish to thank all posters for their contributions. They have been full of information, good judgement and civility. A lot of ground has been covered and the differences between the two frameworks are now much clearer to me - and, hopefully, to everyone.
I did not state what we intended to use either of these two frameworks for, which was a mistake on my part. We are deciding which framework to use as the core element in the IT architecture of a research institute at a European university. I hit on TG and a colleague of mine hit on web2py, and we needed arguments pro et con. This you have now have now supplied, in abundant - and perhaps sufficient - measure. Thanks to all! Jens PS: Keep the thread spinning! On Apr 27, 2009, at 3:38PM, Michel Albert wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
