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

[Dave Cole]

>>>>> "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.  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.

Max> In smaller one-of systems it makes sense, but in an app-server
Max> like Zope where the idea is that different components can be
Max> joined together to create a bigger application, there has to be
Max> stronger rules for layout and design of the components so that
Max> they will automatically fit into the bigger whole.

Whenever you have a medium to large size system you need to establish
rules to ensure that components fit together.  Zope is certainly not
unique in this regard.

Max> Page template languages is the wrong approach in this regards.

Are you able to explain why?

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.

If your problem falls within the domain of the toolkit then you will
like the toolkit.  If your problem is not addressed by the toolkit
then you are likely to question the usefulness of the approach.

Max> And I believe that the reason is that they are using pagetemplate
Max> languages to bind it together, which leads to this kind of
Max> design.

I suggest that the problem that they are trying to solve has lead to
the implementation.  I could be misunderstanding you, but could you
explain an alternative approach to solving the problem which would
deliver a more general solution?

Max> I my experience, tools which separates logic from view in the
Max> "pagetemplate" approach is doing it wrong.

Again, can you explain why?

Max> The layout may be separated, but reuse of code/componentes
Max> greatly suffers from this approach.

Not sure I agree here.  Maybe I am missing something because I think
that a clear separation of presentation and implementation increases
the cohesiveness of code and reduces the incidence of pathological
coupling.

- Dave

-- 
http://www.object-craft.com.au