"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes: > Thanks for the tip on the multiple select, I'll try it out just as soon > as I can. Regarding using the widgets, I have no doubt that they are > time-saving in the long-run. I'd love to use them, but I haven't much > of a clue as to how. It seems easier and more time-effective right now > to do forms by hand, than to poke around in the relative darkness > (spartan docs) with the widgets. That said, I'll look at them more > closely today and see if I can't suss them out.
If you write your forms by hand you'll have to either write your own validators or call formencode.validators (or turbogears.validators) by hand, what might be annoying and pollute your code. Unless, of course, you're not doing any validation at all to what you get from the web (this is dangerous). > Regarding the backtraces, I'm using .9a4, and have done almost all of > my learning on .9. And many of the backtraces I see are quite useful. > The one I mentioned previously however (template cannot be found) is > misleading. "What do you mean the template can't be found? It's right > there!". This led my to my controllers.py, assuming I had type-o'd the > name or something similar. After much head-scratching I found the error > in the template itself, fixed it, and that remedied the problem. Hmmm... It probably was referring to the ".pyc" file that is generated by Kid. If there was an error, then there would be no "template.pyc" and hence the error message you saw. > Another example that I have seen often lately would be the backtrace > that ends with "ExpatError: not well-formed (invalid token): line X, > column Y", where X and Y are numbers. This doesn't really tell me (the > noob) anything about where to look to fix this. The content above seems > to imply something that kid doesn't like, but my gut tells me it's > something that I did wrong in the controllers, or in how I'm handing > data to the template, not the template itself. This is one I haven't > figured out how to fix yet. It was related to an more "sophisticated" > feature (relatively speaking) I was attempting to add to my app, and > when I ran into this I just removed the latest changes I made and moved > on to other areas. It can be a lot more useful if you compile the template by hand and keep the source (.py) generated, and then look at the said line to see what it is about. With this you can go back to your ".kid" and fix the problem. The backtrace has some hints as well. I usually do a lot of incremental changes and tests, so this doesn't bother me much since it is related to something I have just changed. I start simple and then I add features, one at a time. > Obviously a backtrace can't always perfectly identify where a problem > lies, but a reference along the lines of "when you see <foo> it usually > means <bar>" at least for the common and non-obvious ones would be very > useful to the uninitiated. This is especially true since TG ties so > many tools together that even figuring out which set of docs to look in > for information can be daunting. You could start a page with a "cheat sheet" for Kid errors ;-) Add to the problem that you can use other templating tools -- such as cheetah, for example -- and then you'll see that the problem is bigger than you thought :-) -- Jorge Godoy <[EMAIL PROTECTED]> --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
