I was just reading over my last post (something I probably should have done before I posted it) about CMS and realized I really screwed the pooch on some of the tech-terms. I blame it on acronyms... there's just too damn many of them! ;)
I said:
"Well, I think what Justin is probably interested in keeping is the CMA half of Radio's CMS: the template and macro execution/expansion features, which constitute a major portion of Radio's functionality. The CDA half, I agree, is pretty basic."
But given the simple definition of CMA as content authoring tools and CDA as content generation and publishing tools, I should have said:
Well, I think what Justin is probably interested in is throwing out the CMA half of Radio's CMS system and keeping the CDA half: template and macro execution/expansion features. The publishing part of CDA, I agree is pretty basic.
I don't want to replace Radio completely. I want it to continue being my CMS. I want it to continue publishing my blog. What I want to replace is the news aggregator and editing tools. [Justin Rudd's Radio Weblog]
What else is there? There's no other content management to speak of, except blog & story editing. You drop files in a directory and it pushes them out for you? Bah, that's not CM. All I use Radio for is news and posting. If you replace news and posting, what's left? [The .NET Guy]
Well, I think what Justin is probably interested in keeping is the CMA half of Radio's CMS: the template and macro execution/expansion features, which constitute a major portion of Radio's functionality. The CDA half, I agree, is pretty basic.
In my dream weblog software, CMA is handled via XML templates which are processed using XSLT. When publishing content, the data is pushed through a pre-processor not unlike that of ASP.NET where all <%= %> occurences are translated to xsl:valueof calls. Macros would be written using VSA and/or as external .NET components (registered somehow with the system) which are then passed as extension objects to an XslTransform for processing.