On Wed, Oct 30, 2002 at 10:08:42PM +0000, Tim Sweetman wrote: > For spaghetti avoidance, "the right thing" tends to constitute > nonspaghetti; separating stuff out; abstraction layers; passing the > right data, and just the right data, to another part of the system > through a comprehensible interface.
Yep, and all that's possible with my little toy system. It doesn't force it, true, but even so, if it results in spaghetti that's the user's fault, as it is trivial to avoid. > Firstly: > "Trivial templates by variable substitution" is not an intuitive thing > to do. "The only intuitive interface is the nipple". Although I imagine a good stout club is up there with it. Sadly, we're talking about computers. > I'm doing it here, because DC did it earlier, because in a sense > it removes content from presentation. However, a bunch of variables > isn't something that you can (without heavy wizardry) simply pass > somewhere else. You could pass each variable individually: > > my ($width, $height, $iq, $motherfuckers_per_second, $foo, $bar, > $blarch) = > $slimshady->vital_stats; Eeuuuwww. I'd refer to the slimshady->width accessor method when I needed to spew the width to the output. Remember, I'm abstracting application logic out from the presentation. slimshady would be an instance of the Musician::Allegedly class, defined outside the template and wrapped up in easy-to-reuse-and-not-tied-to-the-web-at-all goodness. > Secondly: > Except for trivial amounts of data, slinging data around in hashes, hash > references, list references etc is good for this sort of application. Welcome to the world of objects :-) > "Trivial templates by variable substitution" does not make this > particularly easy. Templating systems (well, TT and H::T) _do_. In that case I guess that phtml isn't trivial in your view. Personally, I *do* think it's trivial, cos the implementation is only a few lines of simple code and a couple of lines in the apache config. I don't see why people make such a song and dance about this stuff. > Separating templates out also means it's easier to change appearance > without changing functionality. As I have, in fact, done on a site using my system. > It reduces friction between specialised > graphic designers and coders. It keeps dreamweaver and emacs relatively > happy. Graphics designers, dreamweaver and emacs are of no interest to me, but they wouldn't find my toy intolerable. Let me clear up a few things here. I wrote my toy system because I had an itch which needed scratching. I looked at pre-existing alternatives and rejected them all for various reasons. The only reason I'm even bothering to argue about this is because of the incorrect assertions coming from people who really should know better that my sort of solution inevitably leads to spaghetti code and all the rest of the nastiness from Revelations. If there's anyone here looking for a solution to their problem, I don't want them to only hear the solution that I consider to be horribly over- engineered. And I certainly don't want them to reject potential solutions based upon misinformation. > It makes it easier to grep your source without running into > fragments of HTML-or-whatever. So isn't it a good thing that I don't have that problem! I rock SO hard. > All of which are good things in general, > rather than spaghetti avoidance features in particular, and which go > away if you start having Perl-like bits in your templates. No, they do not. They *can* go away *if* the user is an idiot. But would you let an idiot loose in your templates? If your graphics designer is messing around in the bits he's specifically been told not to mess with, then HE is the problem. If your HTML "coders" are too dense to understand the few simple constructs they might need - like looping - then THEY are the problem, and they can be easily replaced by out-of-work perl mongers. > OK. You maintain that: > > *any* templating > > language is code embedded in presentation Yup, if it's to let you do anything useful like dynamically build a visual representation of a table of data. > Loosely speaking, when we talk about code, we mean stuff that can do > some of these: > 1. implement an arbitrary algorithm > 2. loop for an arbitrary period. Perhaps forever. Perhaps not. > 3. perhaps do IO, perhaps system calls. > 4. perhaps invoke your methods elsewhere within your system. That list looks remarkably like it's been designed ex post facto to rule me out. I say that anything you write to tell the computer what to do is code. Turning data structures into nicely formatted tables counts. Some choose to invent a new language to do it in, whereas I was lazy and impatient and used someone elses which, tbh, does a far better job than I could in any reasonable time frame if I tried to create my own.. > A good language makes it easy to do what you're trying to do. OO > languages make certain kinds of useful encapsulation easy; I've found this amazing language with all sorts of OO features. It's called perl (yes, without the a, bloody illiterates). > Making > spaghetti code easy, making structure difficult, and taking bloody ages > to write and debug are all bad features in a language. OK, this "perl" language does make spaghetti easy. They even have competitions amongst their leetest haXx0rs to see who can write the worst code. But it's trivial to avoid making spaghetti if, unlike them, you want to use the language as a serious tool. -- David Cantrell | Benevolent Dictator | http://www.cantrell.org.uk/david Educating this luser would be something to frustrate even the unflappable Yoda and make him jam a lightsaber up his arse while screaming "praise evil, the Dark Side is your friend!". -- Derek Balling, in the Monastery
