Re: Nirvana through the templating yin yang (TT2 / CGI.pm)

[chunlou]

What architecture to use is often dictated by your organizational and development environment, besides your teammates' skills and the merit of the technology itself.

Whimsical development process encourages PHP type of technology, which more easily allows "on-the-fly" coding with little planning.

N-tier architecture (starting with your using templating, for instance) requires intellectual and procedural supports from both programmers and non-programmers.

The idea could be characterized in the following table, as an example (be the changes due to internal or external reasons):

		Architectural1. (Backend Logics) Changes
		Rare		Often
		Business Rules2. (Middle Layer Logics) Changes		Business Rules2. (Middle Layer Logics) Changes
		Rare	Often	Rare	Often
Presentation (Frontend Logics) Changes	Rare	Assembly? (just kidding)	Template + scripting lang.	(ever happened?)	Template + scripting lang.
	Often	Template + compiled codes	PHP	(not sure this can happen)	PHP (simple 2-tier) + yoga, aspirin, etc

^1. This usually means DB, XML, etc.
^2. This translates into Perl scripts, Java beans, COM, stored procedures etc. for most people

[EvdB]

I feel the need to clarify - and disagree.

If I correctly understand your table you are saying that in all the likely scenarios templating is the way to go, unless both the logic and presentation change often, and then putting the logic in with the presentation (ala PHP) is best.

Surely with both the logic and presentation changing the best thing is to have them both seperate. As long as the interface is well defined then the two can be changed with minimal interaction.

I am currently refactoring a PHP site I wrote in 2000 into a perl site. All of the pages are becoming shorter and cleaner, even with my ruthlessly splitting them into logic and templates. This may be influencing my view on this but quite frankly there is no reason to do it the php way once you have fully understood the templating way.

Like the table though - thought provoking. Now back to that PHP...

--tidiness is the memory loss of environmental mnemonics

[adrianh]

Surely with both the logic and presentation changing the best thing is to have them both seperate. As long as the interface is well defined then the two can be changed with minimal interaction

Agreement to the N^th power! Especially if the presentation maintainers and the logic maintainers are different groups of people.

With shifting requirements it's best to try and keep everything decoupled from everything else.

(Update: Not that this is a pro-Perl, anti-PHP statement. You can mangle the code and presentation together just as easily in Perl.)

[chunlou]

The issue is behavioral, not logical and technical. The table depicts more of what tends to happen than what ought to be.

When I said "PHP," I meant "PHP-like" way of coding style, i.e. writing everything mostly in one file, which applies to ASP, Perl-CGI, etc. I meant more of "style" than "technology." But "PHP" is shortest to write, lazy me.

When you do a webpage in PHP (or whatever technology/style akin to it), you can do everything in one file (call it the "one-file" style). It takes minimal design and planning effort.

When you do templating, you need at least two files (logically, not if physically), a template and a script.

If you use XML as templating technology, you need (logically or physically) as many as four files--XML, XSL/XPath, {$insert_ur_fave_lang} script, and DTD/Schema. That needs a lot of thinking, even though it might not actually physically take you that much time.

For a lazy or inexperienced person, or for a person who has been torn by constantly scraping and redoing his work because of incessant whimisical change requests, would he tend to do it in one file or four files? "Why should I constantly make changes in four places rather than one?"

If everyone does what's "logical," I didn't have to explain to someone why he shouldn't embed a SQL statement directly into ASP, but rather write a stored procedure and call it from ASP instead. Or, to a manager, why JSP doesn't make much different from ASP--it's the people (programmers and others) who make the difference (as some people, especially those who don't "implement" anything, tend to believe technology by itself does magic, and implicitly feel it can compensate for faulty business ideas and relieve them from thoughtful planning and "well-defined" spec).

The key phrase is "as long as the interface is well defined," as you said it. When sometimes you have account managers continuously walk up to a programmer directly requesting making changes at once, without notifying the project manager, everything is "on-the-fly" rather than "well-defined."

That's why you can't usefully implement templating without descent (intellectual and procedural) support from programmers as well as non-programmers.

The world tends to go the natural human behavioral way rather than the logical programmers' way. Behavioral change is hard. In my experience, people issues far exceeds technical problems in any project, for people don't always do the "logical" things.

In reality, within a timeframe, it's often only feasible for me to compromise the technology and the procedures in order to accommodate the prevailing human habits at the time.