This is certainly something that could be useful, and I was trying to work out how to do something very similar quite recently.

You might want to think a bit about how to get a useful separation of concepts: in my case, I already have a bunch of field definition objects (constructed from the same data as was used to create the table in the first place), so I hope you'd provide a mechanism (by subclassing or with a direct hook) to bypass the "fetch and parse the describe table info".

Another issue is the level of control the caller has over the output: she might want to choose, for example, whether a particular varchar field should be presented as a text input field or as a textarea, and might also want to supply the visual dimensions of the result. I haven't yet come up with a clean way of passing such information around.

If you allow such levels of control, you'll probably find (as I did) that you need to incorporate both the field name and the display type into the parameter name, so that you know how to decode the parameters when the form is submitted. This also allowed me, for example, to invent a pseudo input-type of "date" and present it as 3 drop-downs for day/month/year instead of being forced to present it as a string.

Hugo