I am just wondering if basing on the current etp code is actually going to be beneficial?
The end result is going to be so different that making an upgrade path to a totally new package would not be any harder, so that leaves (in my mind) the only benefit being that there is something that actually works sooner in the cycle.
I think given that the CR framework is quite strong, and will drive the backend design of any CMS system, building it from scratch will be easier and yield a better result.
I also think that the types and auto-generation issues are not going to be on a CMS shopper's wish list, mostly because they won't understand what to use them for. A better early hit will be the ability to auto-build navigation from a cr folder tree, easy ways (plural) to edit the cr tree and items. he only cr items i think we really need are:
* styles (adp or adp/tcl)
* blobs
* attachments (arbitrary blobs attached to other items - ideally auto-generating dimensions for images)
* single page adp chunks (or adp/tcl chunk pairs)
* sub-tree adp chunkc (or adp/tcl chunk pairs)
* internal links
* external links
all except blobs should be database bound.
The one i called sub-tree is what midgard calls "dynamic pages", an example is a page that sits at say /foo and is rendered for /foo/bar /foo/bar/sheep ad nauseum, and gets the sub urls (bar, bar/sheep respectively) as an argc/argv[] pair so it can render accordingly.
I know the latter is not what we expect in ACS, and if we wanted to do that we would register an aolserver hook, but for a cms content programmer, it actually turns out to be amazingly flexible and is what cms programmers expect.
That sort of system doesn't have a lot in common with etp, and I feel that taking etp along for the ride is just unnecessary bagagge.
