|Do you know where your variables are?|
Your idea forces me to write wrapper objects for every object I want loaded,
Yes. However, as with good code, the handler only need to be written once and if it turns out that something was overlooked, it can easily be added and all code using the handler gets the new advanage.
... and you force me to implement the logic in new(). That would prevent me from putting the logic in my object itself.
I don't get what you're saying. Look at your counter-example:
In your example, customer_name is a declarative form of my handler. It's the same thing. And guess what? My handler reads pretty similarly:
There is, however, a huge difference here. Hand those two snippets to programmers who know nothing about the two modules and ask them what the code does. Mine builds on the knowledge programmers already have. There is nothing knew you need to learn for that handler. Once you understand that a handler is "a constructor which takes a CGI object and returns the appropriate instance", that's it. You're done. There's no going back to the docs to read that "constraints" means, or to figure out if "constraint_method_regexp_map" is what you really need.
In any event, I've no problem with DFV. It's a great module, it's just a different approach and I've never liked how much stuff I seem to have to wade through to figure out what I need.