From your example it looks like the use of the query writer as you suggest also removes the usage of the templated form builder.  This is, I do believe, a very bad idea.  Having worked with a large site built with custom built-by-hand forms which saw the .adp files shrink by a factor of (I kid you not) roughly 500 times when moved to the use of a single form builder template shared among all forms, I will never go back to writing my own input tags again.  Ditto for giving up the kind of validation made easy by the form builder/ad_form.

What's wrong with using object metadata to drive things?

As far as this comment goes:

"Differences from the cr include the fact that you write down your data model: a real table with real constraints."

I must say I'm at a loss to understand it.  When one customizes a content datatype one writes a real table or allows the attribute creation code to create the table for you, but in both cases your custom type has a "real table with real constraints" resulting.

As far as comments above regarding the fact that we have too many ways to do things with little documentation as to which are best practices and which are deprecated/frowned upon, this is absolutely true and something we should strive to fix.  All forms in the system should be built with the form builder and preferably ad_form, for instance, which in almost all cases greatly simplifies their creation and processing and makes easy the task of providing forms within a site with a uniform look and feel.  On and on with item after item we should standardize our approach.

But of course lots of people don't like the form builder, are uninterested in using the content repository, are uninterested in exploring the use of object metadata to automate the boring stuff, etc etc.

We have people who want to build square, pentagonal and hexagonal wheels as well as reinvent the traditional round wheels to be found in the toolkit.

So I'm not optimistic about our ability to settle on a handful of best practices used throughout the toolkit.

Query-writer can be used with the form builder. You just fill an array with the attributes/values and call the query writer proc.

The query-writer url api has built in per attribute validation. I'm currently adding multi-attribute validation. It uses the same filters as ad_page_contract. It also automatically does a length check on char/varchar attributes, although now I think there is an ad_page_contract filter that does the same thing.

Using the query-writer url api ensures that the same filters are applied every time an object is created or updated, I think with ad_form you can only ensure this is true for one form.

The query-writer url api is designed to make it easy to handle insert/update/delete of any number of objects in one pass. I'm sure you can do the same with ad_form, but you don't need to write any tcl code with query-writer.

Query writer has flags for each attribute, arranged by group. By default there are Admin and 'registered user' groups. These flags could be used to build forms which only show the attributes (and even only allowed attribute values) on a per group basis. So one form could serve both admin and regular users.

There is nothing to prevent someone from extending query writer with a generic form. Given the object name, operation, and group, you can relatively easily do this. It might be nice if you could pass in a subset of possible fields you want displayed. Query writer already has help fields on a per attribute basis that could be included as well when errors occur.

It is just my opinion that a written down data model is the best documentation of what is possible with a package. Trying to discern/write the data model by reading/writing a bunch of tcl or pl code which creates a table attribute by attribute is impossible for my small brain. I've written and used more generic methods of representing a data model, but they quickly become useless when it is time to figure out how to use it. I also like being able to drop a package and recreate it to see if it installs after I have made changes. Probably you can do this with the cr too.

Most of the stuff I work on isn't what I would consider a content application. But if I needed revisions, and whatever else is on the laundry list of features provided by the cr, I would still look at using it. Query writer is not a content manager.