>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.
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.
>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.
Is this something we can do with 5.0.0 core content-repository or in the current bcms-ui?
>Continously overloading ad_form as has been done over the
>past few months won't make its use easier to understand,
>quite the opposite.
No, but extending it (or a similar new function) into a more complete abstraction that handles the different paths would make it easier.
>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.
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:
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.
>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.
No doubt. I'll post it in this thread.
>I'm also curious as to which features you'd leave out in an "ad_form2" ...
>Both of which can be auto-generated using the type attribute system.
Is this something that exists now or a new approach we are considering?