Web templating/db tool with best designer/coder separation?

[Paul Boddie]

Dave Cole <djc at object-craft.com.au> wrote in message news:<m3r8iye24k.fsf at ferret.object-craft.com.au>...
> >>>>> "Max" == Max M <maxm at mxm.dk> writes:
> 
> Max> Jon Ribbens wrote:
> >> In article <af2gh6$2c2$0 at 216.39.172.122>, Bengt Richter wrote: Take
> >> a look at http://jonpy.sourceforge.net/ . It almost completely
> >> separates code and HTML so that the designer and the coder do not
> >> interfere with each other.
> 
> Max> I do understand that argument, but I almost certainly don't agree
> Max> that it is of much use.
> 
> I agree, I am not sure it is such a good argument myself.

It's a sort-of-incomplete argument, really. In most situations, the
designer and developer need to agree on what is being presented, so
they must "interfere" with each other in some way. However, the nature
of the interference should be focused only on the structure of the
data, not on the way the data is stored, for example.

>                                                           If you are
> working in an environment where HTML editors do not understand the
> templating system then you are going to need at least one person who
> can post process the HTML and integrate it with the templating logic.
> No magic templating system is going to solve that problem.

If the designer and HTML editor together know nothing about the
templating system, the best that one can hope for is a diminished
amount of work doing that integration for the developer. Moreover,
where changes need to be made again by the designer, it really helps
if the developer can avoid doing any work "unintegrating" the
templates from the system. Being able to make a round trip with the
templates is pretty interesting, in my opinion.

> Max> The development of the Cmf and Plone are good examples of this
> Max> wrongfull approach. They make it easy to create one single type
> Max> of application, but makes it very hard to re-use their components
> Max> to build other types of applications.
> 
> Whenever you build any toolkit you have to decide on the set of
> problems that you wish to solve with the toolkit.  The smaller the
> problem domain the more useful you can make the toolkit.

Indeed. Some kinds of applications may be addressed well by a
particular toolkit, and since you might spend most of your time
constructing those applications for customers, for example, it would
definitely be worthwhile abandoning "complete freedom of expression"
for something which gets the job done quickly, effectively and
cheaply. This is arguably where many toolkits/frameworks fall down -
by trying to be everything to everyone, they become as complicated as
the language they're written in and don't always offer much more than
the bare language in doing a particular job. Consequently, people get
the temptation to write "rival frameworks" from scratch.

Paul