Hi, On 12/4/05, David Bernard <[EMAIL PROTECTED]> wrote: > I want to port the CRUD package of my TG app to 0.9 svn, and may be, > submit it to Turbogear. > But to do this I need to understand some choice... > > 1) in TableForm : Why using cherrypy.request.form_errors instead of a > dict inserted into input_values with key "error"?
http://yourhost/report_problem?error=foobar you could legitimately have an input value called error. I'd turn the question around: why use input_values["error"] instead of form_errors? > 3) in Widget : Why not set default value into the input() and > create_dict() ? I'm not sure what you're going for here. The default value is entered via create_dict if there's no value provided. > 4) in Widget : Why delete the value from param if the value is invalid > into input() ? You're not the first to ask this question, and I just remembered a good reason for this (I should really put in some decent docstrings). The idea is that the validator helps you do a convenient roundtrip to/from the web. Imagine something like a multiple selection widget that gets you a set from the web and converts that set into selections when heading out to the web. If the value(s) that came in could not actually be converted properly into a Python set, you wouldn't want to try to redisplay that value, since it wasn't actually a set. What may be needed, though, is a way to specify that a value was Invalid but still provide a partially converted value. For example, let's say the user can pick any combination of "Burger", "Fries" and "Drink". If the request comes in with "Burger" and "Chicken Sandwich", "Chicken Sandwich" is invalid but you could still return a set with just "Burger" in it. Kevin -- Kevin Dangoor Author of the Zesty News RSS newsreader email: [EMAIL PROTECTED] company: http://www.BlazingThings.com blog: http://www.BlueSkyOnMars.com
