Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl-Sensitive Sunglasses
 
PerlMonks  

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

by adrianh (Chancellor)
on Jun 19, 2003 at 15:31 UTC ( #267237=note: print w/ replies, xml ) Need Help??


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

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


Comment on Re^3: Nirvana through the templating yin yang (TT2 / CGI.pm)
Re: Re^3: Nirvana through the templating yin yang (TT2 / CGI.pm)
by chunlou (Curate) on Jun 19, 2003 at 21:39 UTC
    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://267237]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others chanting in the Monastery: (3)
As of 2014-08-31 00:39 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The best computer themed movie is:











    Results (294 votes), past polls