My purpose in going to a greater level of detail is that I feel ad_form is currently a "leaky abstraction." It hides details, but not consistently enough, so that its behavior is unpredictable. For example, I wrote code that behaved worked fine until a data field didn't validate, and then ad_form was essentially in a new mode, and it crashed. So I want to drive down past the abstraction, make sure we get it right, and then come back up with a tighter abstraction.
Re: display mode - I think we should go in the opposite direction. That is, we should use ad_form as the recommended, simplest method of displaying single records in detail view. My reasoning is, it's most of the way there already and it's the right approach. The logic for determining which fields to display and in what mode is usually very similar for both edit and display mode. And while ad_form is already pretty complicated, I think that's because of its history and because it's stuck in-between - in particular, in between functional style and declarative style. In some parts you simply describe what you want to see, and in others you have to know the right order of things and what will and won't get pre-processed and when.
Another approach I want to put on the table is creating ad_form2, where we take the best of ad_form and take a clean conceptual approach.
Please see my post earlier in this thread for an enumeration of things I think we should be able to do with ad_form.
