14 thoughts on “Use FormEncode to verify one date precedes another”

1. FormEncode is some good stuff. Definitely worth diving into.

2. Yeah, it is really nice to keep all the type-conversion code separate
   from the code that really does something. However, it is really a
   little too fancy for my tastes. At some point, I want to study
   validino more, because it is just a lot simpler to read.

3. FormEncode is really cool and underrated, IMHO. The documentation is really basic and not organized very well, though, so you need to read the source and experiment at lot, to understand how all the combinations of different validators, compound validators and validation schemas work and which tricks there are to write your own validators. Also, the set of standard validators provided with the FE distribution is lacking in many respects (min/max for Integers anyone?) or plain buggy (DateTimeConverter).

   I have a sizable collection of re-usable, custom validators for my TurboGears apps now, and I hope I'll find the time soon, to publish them somewhere.

4. Yeah, FE is a fantastic idea, but like many great ideas, the first
   stab may not be the best possible implementation.

   I think a big list of examples would go a long way to make it FE more popular.

5. from the code that really does something. However, it is really a
   little too fancy for my tastes.I think a big list of examples would go a long way to make it FE more popular.I hope I'll find the time soon, to publish them somewhere

6. Then when I run my schema on d2, where the start_date is after the stop_date, my schema raises an Invalid exception. In a web framework like TurboGears, there is some exception handler that will catch that exception and take that error dictionary and redraw the form and print my error message.

7. +1, dude… +1

8. Thanks — it took a long time for me to figure that out and I hope I saved somebody else some time.

9. Thank you very much – I was just trying to work out how to do this! Thanks for posting!

10. Wonderful! Glad it helped.

11. Thanks! Good one!

12. you're welcome

13. Thank you Matt,

    this is indeed exactly what I was in search for myself!

    Another way of doing this would include malforming the controller to raise a ValidationError in case end lies before start, but yours is a more elegant way. It is a pity, most of the framework documentation covers mostly the standard cases. At http://tinyurl.com/bngms2t the answer is given, but you will not find this by obvious searching terms for the date problem.

    Again, RTFM is the answer, but your helpful pointer saved a couple of hours 🙂

    Regards from Germany

14. Hey, I'm so happy this helped you out!

    I think formencode is a great idea because it is very important to examine all the inputs coming in to our programs.

    But the formencode implementation is very hard to use! Especially when you want to do more complex validation. For example, you may want to verify some input corresponds to an allowed value stored in a database, or stored in a config file. It is not elegant to do this!

    It is also not elegant to coalesce values from several sources, for example, sometimes I want to draw an HTML form and fill in some of the fields to save the user time. I want to grab those values from the query string first, but if that fails, then inspect the some data stored in a session database table. This is possible, but not elegant, and difficult to explain to another programmer.

    I'm working on a replacement to FormEncode, called Scrubber. It doesn't have any of the cute syntax tricks because it doesn't use metaclasses. At some point I will write up a description, but you use the class like this::

    
    s = MyScrubber(wsgi_environ, 
        database_connection, 
        config_file_wrapper) 
    
    
    errors, values = s.make_errors_and_values()
    
    if errors:
        # re-draw the form, using the errors dictionary
        # to draw error messages, and using the values 
        # dictionary to pre-populate fields.
    
    else:
        # do whatever you want.
    

    You have to define MyScrubber like this::

    
    import scrubber
    
    
    class MyScrubber(scrubber.Scrubber):
    
        # Every subclass must define this
        def make_errors_and_values(self):
            errors, values = dict(), dict()
            self.extract_date1(errors, values)
            self.extract_date2(errors, values)
            self.verify_date1_precedes_date2(errors, values)
            return errors, values
    

    There is no magic introspection involved. You have to write out the definitions of extract_date1 and extract_date2 and verify_date1_precedes_date2 yourself. Each method gets a reference to the same errors and values dictionary, so if one of the extract_… methods failed, then the later method can check for the relevant error, and quit early.

    Here is what extract_date1 might look like::

    
    import datetime
    def extract_date1(self, errors, values):
    
    
        # If you are using something like webob or django 
        # requests, this part will look different.
        parsed_QS = urlparse.parse_qs(
            self.wsgi_environ['QUERY_STRING'])
    
        if 'date1' in parsed_QS:
            raw_date1 = parsed_QS['date1']
            try:
                values['date1'] = datetime.datetime.strptime(
                    raw_date1, '%Y-%m-%d')
            except ValueError as ex:
                log.debug(ex, exc_info=1)
                values['date1'] = raw_date1
    
        else:
            errors['date1'] = 'This is required field!'
    
        return errors, values
    

    This pattern works really well for me. I know some people might complain about the amount of redundant code, but I don't care any more. I prefer an obvious verbose solution that works 100% of the time over a fancy solution that ignores weird corner cases.

    Anyhow, thanks so much for writing. I'm glad to know it helped you out.

Comments are closed.