On Thu, Dec 02, 2004 at 01:27:09PM -0500, Stefano Mazzocchi wrote: > Sylvain Wallez wrote: > > >You miss an important point here: many Cocoon users are not able to > >write Java code, and even less a Tag implementation. The purpose of > >taglibs and template languages is to provide pre-packaged higher-level > >constructs that hide the underlying complexity. > > I'm sorry but I can't take this argument any longer. > > Programming is not just learning a syntax, but it's the mapping of a > mental model. Mental model that people that write templates simple *DO > NOT* have, nor care to have.
Thank you, Stefano, for emphasizing the split between the "mental model" of the programmer versus that of the template designer. I would like to now accentuate another aspect of our problem and solution space. Babel-Driven Separation of Concerns (BDSoC) versus Graduated Complexity Separation of Concerns (GCSoC) We are currently using Babel (different languages) to enforce separation of concerns, and this has its merits, in that it creates a high barrior between different concerns, but also carries an obvious price. Another (complementary?) route would be to separate concerns via Graduated Complexity (same languages, with different levels of feature-sets available.) This would at least allow the people assigned to the different concerns to talk the same languages, with just the specific vocabularies varying. For example, picture a generic tag engine with sets of tag libraries. Configure one instance of the tag engine, giving it access to only the "programming" tags (such as to duplicate ESQL functionality.) Configure another instance of the (same) tag engine with access to only the "templating" tags. The framework development community now is in the easier position of supporting one instead of two "languages", while the separation of concerns is still enforced upon the framework users. A side effect in this example is that the programmers and template makers gain a common base language, possibly making their needs easier to express to each other, maybe even leading to cross-pollination between their skillsets, allowing them to work more smoothly together while working on their respective concerns. WDYT? --Tim Larson
