cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Larson <...@keow.org>
Subject Re: [Design] JXTG 2.0 (Just say no!)
Date Thu, 02 Dec 2004 19:14:45 GMT
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

Mime
View raw message