<blockquote>Displaying a record is not the same as building a form, and
for the life of me I can't see why ad_form would be the
desired mechanism for doing this.
</blockquote>
Displaying a record involves many of the same steps as building a form, especially building a form for edit:
- retrieve a record
- do secondary lookups
- check access permissions
Ad_form already does this, and already has a display mode for showing records that have just been edited.
<blockquote>I think the templating approach taken by the CR is much
better for displaying records ... and the CMS/CR +
templating engine can already build default display
templates from attribute data.
</blockquote>
Is this something we can do with 5.0.0 core content-repository or in the current bcms-ui?
<blockquote>Continously overloading ad_form as has been done over the
past few months won't make its use easier to understand,
quite the opposite.
</blockquote>
No, but extending it (or a similar new function) into a more complete abstraction that handles the different paths would make it easier.
<blockquote>Your approach to documenting it would confuse me, and I
wrote it! :) Iterating a matrix of states into a one long
string of single-dimensional states is just confusing.
</blockquote>
The matrix is the obvious next step, but ad_form doesn't have a matrix of states. It has (as far as I can tell) a linear algorithm to figure out what to do, and I just tried to document its existing behavior as the first step to documenting the ideal set of states for an edit/display/new function.
I think the dimensions of the matrix should include:
Record status:
New
existing record
Behavior:
display form for new record
fetch record and display read-only
fetch record and display for editing
processes incoming POST and either make changes or display errors
I don't yet see a third dimension in the ideal model but there are some more dimensions in the ad_form matrix because of how it determines what to do next.
<blockquote>I'd like to see the example you wrote that crashed when a
field didn't validate. That sounds like a sloppy
implementation of some option ... AFAIK that behavior was
not possible in ad_form before folks started piling on more
and more special featurettes.
</blockquote>
No doubt. I'll post it in this thread.
<blockquote>I'm also curious as to which features you'd leave out in an "ad_form2" ...
</blockquote>
None.
<blockquote>Both of which can be auto-generated using the type attribute system.
</blockquote>
Is this something that exists now or a new approach we are considering?