Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot
 
PerlMonks  

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

by EvdB (Deacon)
on Jun 19, 2003 at 15:27 UTC ( #267235=note: print w/ replies, xml ) Need Help??


in reply to Re: Nirvana through the templating yin yang (TT2 / CGI.pm)
in thread Nirvana through the templating yin yang (TT2 / CGI.pm)

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


Comment on Re: Re: Nirvana through the templating yin yang (TT2 / CGI.pm)
Download Code
Re^3: Nirvana through the templating yin yang (TT2 / CGI.pm)
by adrianh (Chancellor) on Jun 19, 2003 at 15:31 UTC
    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 Nth 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.)

      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.
        The issue is behavioral , not logical and technical. The table depicts more of what tends to happen than what ought to be.

        Sorry, I misinterpreted your post as saying that this was what should be, rather than what usually is.

        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.

        I was trying to clarify my statement, not yours :-) I've been accursed of being anti-PHP in the past - and I'm not.

        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.

        True. In my opinion adding too much complexity is an even greater sin that not having enough. Needless complexity is evil. Things should be decoupled to make things simple - not just for the sake of it. A four tier framework is not the right answer to all questions.

        For a lazy or inexperienced person, or for a person who has been torn by constantly scraping and redoing his work because of incessant whimsical 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?"

        The lazy person needs firing.

        The inexperienced person needs experience and mentoring.

        The experienced person should realise that decoupling makes dealing with whimsical change requests easier not harder. If it doesn't then something is wrong.

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

        It's nearly always a matter of context. Stored procedures might not make sense if you need to support multiple databases. JSP might not make sense if the rest of the company's codebase is ASP. A 4 tier application might be overkill if all you need to do is munge a database table into an HTML page. Etc.

        It is part of our job as a developer to explain these things. After all, if they didn't think it was magic why would they have to hire us :-)

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

        As the years go by I am more and more of the opinion that the "well-defined" spec is a myth outside a few safety-critical environments. The world doesn't work in a way that can produce a well-defined specification document. Business requirements change to quickly and cannot be expressed exactly without an unwarranted expenditure of effort, or by actually writing a working system that allows reality to be compared with expectations.

        (Pointless anecdote: I once did some work with a .com startup who regularly changed their entire business model between meetings. One month it would be selling a product, next month it would be selling demographic information from site visitors, etc. It didn't end well :-)

        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 the fifteen odd years I've been a (vaguely :-) professional coder I can't recall a single project lasting more than a few weeks where the spec hasn't changed, often significantly.

        Most of the time this isn't due to a lack of will, just lack of communication or an incomplete understanding of the problem space.

        These sorts of issues are have caused me to move towards more agile development methodologies - where these issues drive development, rather than getting in its way.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://267235]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others taking refuge in the Monastery: (4)
As of 2014-09-21 16:09 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (172 votes), past polls