Hi Lion! (We're in the same local Python group.) I've been lurking around TurboGears for a month or so. It *is* like walking in the dark once you get off the path, but the rate of development is so rapid that much of it will be well lit in a couple months. It's just an awkward time right now because there's such a wide spread between the released and development version, and many "necessary" tools are only in the development version and are unfinished. But the same thing has happened with Debian and other projects, and eventually a stable version does come out that has enough features you can write a serious app with it. So I'd urge you to stick around even if TG isn't ready for your apps yet, because you learn a heckuv a lot of stuff along the way, not just about TG but about all its base projects, and their implementation issues, and all that background info will be useful later, no matter which framework you choose.
On 12/28/05, Lion Kimbro <[EMAIL PROTECTED]> wrote: > I had come in with the expectation that I would be able to rely on > documentation alone, and just figure my way through things. That's not > the right expectation to have, and that's why I felt burned. Perhaps TG needs a wiki page listing what's unfinished, missing, or hard to do, so that new users can keep this in perspective and not keep searching the documentation for something that isn't there. > I would like to write a tutorial/travel-log after I'm done, that tells > about how I wrote my software, how I think beginners should approach > learning TurboGears. > > It'll roughly go like so: > * part 1: downloading, installing, IRC, mailing list, expectations > * part 2: actually writing the code > * part 3: disaster strikes, you need some info: IRC, mailing list > * part 4: finishing the app, making it look nice > > It'll explain what I thought were rough points, and what things worked > well- incredibly well, even. That would be a great article. Even an ongoing journal showing what was easy/hard, and what workarounds you made due to unfinished features, would be valuable. > Elvelend, yes: This was a problem I ran into many times. I was unsure > about whether something is in CP, or in TG. They're both big, and they > seem to sort of blend in with one another. So, it was very hard to know > where I should be looking. > > Perhaps something that says, "For these kinds of problems, check the > CherryPy documentation. For these kinds of problems, see the TG > documentation." Of course, this assumes relatively complete TG > documentation. Actually, I don't think this part is that difficult. Read the CherryPy manual and see how the pure-CP examples are structured. Then compare them to the TG examples, and you'll see that certain things are done in a certain way in TG but in an ad hoc way in CP. Then skim through the TG source and you'll see that TG takes control of a few certain aspects but mostly leaves CP untouched to do its thing. CP provides the basic URL parsing and server, but TG imposes the MVC. You can also trace objects through the import statements to figure out who's responiable for what. > I'd offer to help, but I don't think I can be much assistance; The time > it would take you to communicate to me what needs to be in the > documentation could well exceed the time it takes you to write the > documentation yourself-- a classic problem. Just listing what you find difficult is a good start. Otherwise, people may not realize it's underocumented. -- Mike Orr <[EMAIL PROTECTED]> ([EMAIL PROTECTED] address is semi-reliable)
