in reply to Why a mini-language? (was Re^3: RFC: Templating without a System)
in thread RFC: Templating without a System

So, while a mini-language may not make sense for you, it makes a great deal of sense in these shops.

Ack, thanks for pointing that out. There are also those shops in which they don't want to know or do anything beyond the design and layout, and consider inserting loops or conditionals or even variable templates as being "not their job".

Also, I find that having a mini-language keeps me honest about MVC. About the time it starts getting hard to write in TT, I realize that I'm actually writing control or model code, and that code belongs away from the view code. So, I rip that out and put it in Perl or SQL where it belongs.

Then you are using the restrictions of the mini-language to discipline yourself? It's a good thing to put up fences which thou shalt not pass, but it's better to have them "inside".

I love perl particularly for what is said in the perlmodlib manpage note at the end: "It would prefer that you stayed out of its living room because you weren't invited, not because it has a shotgun."

greets,
--shmem

  • Comment on Re: Why a mini-language? (was Re^3: RFC: Templating without a System)

Replies are listed 'Best First'.
Re^2: Why a mini-language? (was Re^3: RFC: Templating without a System)
by merlyn (Sage) on Jul 01, 2006 at 15:16 UTC
    Then you are using the restrictions of the mini-language to discipline yourself? It's a good thing to put up fences which thou shalt not pass, but it's better to have them "inside".
    It's not so much a restriction as merely a place where it starts getting interestingly harder.

    I don't consider the edge-of-road markers that make a very loud noise in my car when I start to drift a "restriction" either. After all, I can ignore the noise, and keep driving off to the emergency shoulder, as I might need to do occasionally. However, it's a nice warning that I need to rethink what I'm doing.

    TT's limits are more like Perl's "warnings": they can be ignored if you choose, but they seem to kick in almost always at the right time. After all, the thing I wrote to handle my photograph library is a huge 400-line TT component, and it does an insanely large amount of data wrangling that really belonged in a controller somewhere. But I still use that in production (until I replace it with something more ajax-like soon).

    And that's what I like about TT. I can putter around in it, and do model and controller things there, but I'm well aware that it should really be moved somewhere else. With Mason applications, I often see a ton of code in a URL that really belongs in a testable class as a controller or model code, because with Mason, the cost is actually less to put it at a URL instead of in the proper place. This is the danger of Mason (similar to the danger of PHP).

    -- Randal L. Schwartz, Perl hacker
    Be sure to read my standard disclaimer if this is a reply.

[reply]
      However, it's a nice warning that I need to rethink what I'm doing
      That's generally about the time when I say to myself "hey. Leave it. Go have some sleep/fun." - or - "Go do your papers. Your specs are flawed." I'm almost grateful when colleagues show up and say "Go home, you fool. This ain't going to be anything better, get some sleep." But I'm the more grateful when the bell rings within myself.
      (until I replace it with something more ajax-like soon)
      What use do you find for ajax in displaying a photo gallery?

      greetings,
      --shmem 

      _($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}
[reply]

In Section Meditations