"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes: > For example... say I have a multi-part process starting with a form. In > PHP or ASP I would probably make the form action submit to itself, > validate the parameters, and in the event of successful validation, > redirect to the next page in the process, and in the event of > unsuccessful validation, show some errors on the page when redisplaying > the form. How would this process be achieved with 0.8.9? Assume I'm > happy to do the validation by hand in Python rather than trying to > figure out validator objects.
I really recommend that besides the Starting Guide you use the Documentation Playground, at wiki: http://trac.turbogears.org/turbogears/wiki/DocumentationPlayground Anyway, you can try any of these: - keep you PHP/ASP way of working and submit the form to itself, making sure that you read the keywords passed when the form is submitted and that you return things when there's something or when there isn't - submit to another method that will do different validations accordingly to the context Actually, the second way is the one that is documented and I believe it is the best on since it allows you to separate a lot of code from code that triggers displaying. Since you're using 0.8.X you're not using Widgets and you'll have to do error handling by hand, using "py:if" in your templates to show your error messages (widgets do that internally). You'll have to return the error message as well as all the information you want to show again on the form. So, on the python side you'd have something like this: class ...: def __init__(self): ... @turbogears.expose() def default(self, *arg, **kword): ... return controller(arg, kword) @turbogears.expose() def index(self, *arg, **kword): ... return controller(arg, kword) @turbogears.expose(html = "project.templates.template") def controller(self, *arg, **kword): <process *arg and **kword> <see what you'll return to your template> values_for_template = dict( key1 = value1, key2 = value2, ) return dict(values = values_for_template) This is the basic "boilerplate" of a class using separate methods for each operation, as I mentioned in the second option above. Here you start having options: using formencode.validators to validate data from your template (recommended since you can use this validation with new versions of TurboGears later when you upgrade), validating data by hand (painful, but it works), returning to the first page where user did input data, returning a new page, etc. @turbogears.expose() # If returning a different page, you have to # pass the template here as I did in controller() @formencode.validators(...) # Will become turbogears.validators in 0.9 def save(self, **kword): <process values from dict kword and validate them> <save data to the database creating new instances of some class from your model> # Returning the same as in the controller: return self.controller(...) # Returning a new page: # return dict(...) # Redirecting somewhere: # return cherrypy.HTTPRedirect(turbogears.url(...)) # becomes just # turbogears.redirect('url') # in 0.9 @turbogears.expose() # If returning a different page, you have to # pass the template here as I did in controller() @formencode.validators(...) # Will become turbogears.validators in 0.9 def update(self, **kword): <process values from dict kword and validate them> <save data to the database creating new instances of some class from your model> # Returning the same as in the controller: return self.controller(...) # Returning a new page: # return dict(...) # Redirecting somewhere: # return cherrypy.HTTPRedirect(turbogears.url(...)) # becomes just # turbogears.redirect('url') # in 0.9 @turbogears.expose() # If returning a different page, you have to # pass the template here as I did in controller() @formencode.validators(...) # Will become turbogears.validators in 0.9 def delete(self, **kword): <process values from dict kword and validate them> <save data to the database creating new instances of some class from your model> # Returning the same as in the controller: return self.controller(...) # Returning a new page: # return dict(...) # Redirecting somewhere: # return cherrypy.HTTPRedirect(turbogears.url(...)) # becomes just # turbogears.redirect('url') # in 0.9 If there were errors in any of these, you'd have to return an errors dictionary (you'll return it as None if all goes well to be able to test "if errors" in your template) and show it in your template: <input type="text" id="my_id" name="my_name" /> <span py:if="errors">${errors.get('my_name_error', '')</span> For this hypothetical "form", when submitted you'd process and test kword['my_name']. To fill in the form you'll have to change it a little: <input type="text" id="my_id" name="my_name" py:value="data.get('my_name', '')" /> <span py:if="errors">${errors.get('my_name_error', '')</span> and pass a "data" dictionary. If you're reusing forms to enter and show data, this will work. You can use data['my_name'] if you're sure it exists (otherwise you'd get an AttributeError in your template). I believe that in generic lines that's it... :-) I've answered a bit more than you asked, but... :-) In TG 0.9 things are much easier with widgets, forms, validators and error handling. -- 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 -~----------~----~----~----~------~----~------~--~---
