|XP is just a number|
This module does not consume the query data. It's merely a subclass of CGI-Simple. As such, it behaves exactly as that class does with the exception noted in the documentation.
As for your second and third questions, they're closely related. The current implemenation handles existing objects and could easily create new objects for a single field and you'd have to populate the other fields manually. For existing objects that's cumbersome and I don't like it. The only thing which stopped me from implementing that is figuring out the best syntax. One way would be this:
With that syntax, the handler would look for a "customer" param and, failing to find one, would attempt to build a new customer object from the fields list. Still, it's a bit clunky.
One way around that would be to implement another idea I had: "profiles". You would do this:
With that syntax, $profile would point to a file or class (user's choice) which describes various form profiles and the "use" key would point to a scalar or array ref detailing the profiles to be used for this code. That would put the object profiles in a centralized spot.
Alternately, one could do this:
With syntax like that, you specify the location of the profile file or class and the "from_param" lists the name of the param(s) in the form specifying which profile(s) to use. The default would be "__PROFILE__", so even naming it in your code would be optional. Thus, the forms would identify which handlers are needed instead of the code being responsible for it.
These are all very basic ideas and are not fleshed out, so I just put together a simple proof of concept to see how things would work. More suggestions are welcome.
Update: D'oh! I'm an idiot! With a very minor change to my existing code, I can make this work very easily. Instead of passing the param value to the handler, I can pass the Class::CGI object to the handler. The handler would have the resposibility of knowing which field(s) it needed. That's the proper place to put this!