Jorge Godoy wrote: > "[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
Thanks. I found a bit of an example at http://trac.turbogears.org/turbogears/wiki/WidgetlessForm but unfortunately most of the rest seems to be either for esoteric stuff or for 0.9. There is a real lack of explanation on how to perform basic tasks, it seems. There's lots on SQLObject but I'm not interested in that at the moment unfortunately. > 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. I don't see how it really helps at all. Could you elaborate? Why would I want 2 different methods that are going to essentially show the same page anyway? Isn't that breaking some sort of web maxim about having 1 url per resource? I don't think the initial showing of the form and a showing of the same form with some errors should be considered as 2 separate resources. > So, on the python side you'd have something like this: [snip] > This is the basic "boilerplate" of a class using separate methods for each > operation, as I mentioned in the second option above. Is this just to have multiple URLs go through the same Controller method? I don't think I'd want to do it that way since I would expect every distinct URL to have a different behaviour. > @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 Unfortunately that is now the 3rd different way I've seen to use validators, which is part of why I don't particularly want to touch them at this point. > 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 Ok, that's quite helpful, thanks. Is there anywhere in the official documentation that shows that, in addition to strings and dicts, you can return... well, whatever that object is, to do a redirect? I would never have known to dig through the cherrypy documentation for that. I'm not complaining at you, of course. You've been very helpful. I am just trying to make it clear to anyone reading that this is really all very obscure. > 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> Yes, that makes sense to me, from my PHP background. > 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 assume I can just fill data with the contents of kword, and as you say use 'get' in case the values haven't been submitted. > In TG 0.9 things are much easier with widgets, forms, validators and error > handling. Perhaps I just picked a bad time to start using TurboGears when the knowledgeable users seem to be mostly using a version that differs significantly from the last stable one. -- Ben Sizer --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
