Hi Jerry,
My approach has been to use ad_form (!) and try to take full advantage of its ability to fold the various steps (fill in, validate, confirm, submit) and modes (add, view, edit) into a universal tcl/adp pair for the particular object. The advantage of centralizing stuff clearly outweighs the disadvantage of increased complexity/readability, I think.
Furthermore, I try to combine its services to different user types by dynamically providing fields/functionalities depending on the user's privilege. This is (as you know) only possible if the page isn't living under /admin, since that would require that the user has a fullblown admin privilege on the package instance. Sometimes it is useful to have separate admin pages under /admin, though, but that's mostly because you may need a different UI for efficient admin of the package and not because you don't want to mix in admin functionality on user pages, IMO.
In the package we recently wrote (Curriculum) I found it convenient to put the "curriculum-ave.tcl/adp" page (the form for the "curriculum" object) under a /lib dir parallel to the /www dir (thus above the page root) and treat it as an <include> that is included from two separate places; /www/curriculum-ave.adp and /www/admin/curriculum-ave.adp. Rather than linking from the /admin pages to a *-ave.* pair living under /www, I moved this pair to /lib mainly in order to preserve the bread-crumb trail in the yahoo-style navigation in both /www and /admin.
I'd encourage liberal use of <include>s for other reasons as well. For one it makes it a snap to write portlets for dotLRN.
/Ola
