TVs->Custom Fields

In my experience, there is a non-trivial amount of confusion in explaining the concept of TVs... heck I even had to beat it into Raymond's head before he "got it"... Once you understand them, though, they are incredibly powerful. However, I think our implementation can loose this confusion by a few simple changes:

Lose the distinction between [*content*] and [*TVs*]
There is no reason a TV can't be just another type of content. In fact, I propose changing the syntax from TV to "custom field" or some other such name. This could also serve to simplify the API a bit I think, keeping in sync with my philosopy for this stage of the project of less is more. There would be only one set of API calls dealing with getting data, children, etc.

Stop binding TVs to Templates
This initially made sense, but is kludgy in practical application. Custom Fields should behave exactly like [*content*], and be available to all pages by default, and by extension, to all Templates. Templates should not have TVs bound to them. If you add a new template that needs access to, say, 15 variables, it's an inconvenience to go back and enable them for the new template.

Bind Custom Fields to Chunks (or to Content Templates, if you prefer...)
The concept of limiting the presentation or use of Custom Fields to certain pages or content types is a VERY good thing, though. We could therefore introduce a new type of template, which is a Content Template (to which Custom Fields could be bound). A Content Template in this context is really nothing more than a Chunk with bound Custom Fields. It might be better to stick with that which people are already familiar, and just expand the concept of a Chunk. I'm leaning this way right now...

What do you all think about this?

Lose the distinction between [*content*] and [*TVs*]

Agreed 100%. TVs/custom fields/whatever you want to call them are the means to the end to allowing structured content in a CMS. Maybe we should explain (via screenshots) how to break down a page in to it's parts to make it easier for content contribution, assembly and reuse? Take a look at pages 21 and 22 of this presentation in particular, it's the same thing:
http://www.kineticode.com/docs/discovering_bricolage.pdf

Stop binding TVs to Templates

This I don't know about it. Because ideally you want to be able to say "create new press release" or "create new product datasheet" and these are really just templates with certain custom fields in them. We might want to make it easy to duplicate or copy fields from one template to another so they don't need to be recreated. Fields need to be restricted since you're controlling where and how their display is used in the template. I'm not sure how you'd get by without doing this. Authors/editors shouldn't really be picking templates, they should be picking page types with the concept of templates hidden.

Dave

More explanation on binding of TVs to templates, and why it's not such a good thing:

The concept of a template as it stands now is too restrictive. Templates = Pages/Docs in MODx. If you could create "sub-templates" that would be an acceptable I guess but you need to be able to call them via yet another bracketed/braced convention like [#template#]. And I'd rather not introduce yet another one to the mix to go with [[, [!, {{ and [+...

You can get around this with some trick TV manipulation and @bindings right now ... I just don't think we should have to be so tricky .

I think the right answer is to allow Custom Fields to be able to be used in any Template, Chunk and/or Snippet by default. And like in setting up access permissions, only lock them down if explicitly limited. That way you could keep the existing page-building conventions.

I definitely also agree though that there needs to be some sort of Content Template for sure, so an editor could just pick "New Blog Entry" from their Manager menu and start working without having to know anything more than what type of pages they need to build.