On Thu, Jun 06, 2002 at 12:02:47AM -0600, Rob Nagler wrote: > These are the reserve words of TT: [...] > Looks an awful lot like the same keywords in any general-purpose > programming language.
Yep, I agree. You can use it like a programming language and it gives you more than enough rope to hang yourself, or at least get tangled around your feet and trip you up :-) However, the way that I (mostly) use it, and the way that is encouraged in the documentation, is to use it like a programming language only with respect to presentation issues, not application issues. For example, using a FOREACH to calculate some sum of values is probably a Bad Thing, but using it to iterate over a data set and generate a table is a Good Thing. It a presentation loop, not a programming loop. Same goes for conditionals, and so on. Even defining the equivalent of functions or macros. If it's something that generates a presentation element and doesn't have any side effect on the application processing or underlying model then I generally think it's OK. Of course, it all depends on how you defined "presentation" and "programming". But anyway, I'm not defending TT against HTML::Template or any other module because they admirably serve different purposes to different people at different times. TT is most definately not an enforced pure template language. You can use it that way if you like, but you can also use it as a quick, dirty and butt-ugly hacking tool. I construe that to be a good feature of a general purpose templating solution that TT aspires to be. But I also readily admit that too much freedom to Do the Wrong Thing can be a weakness in particular environments. That's why we have different modules. Sometimes you need a hammer, sometimes you need a saw, sometimes you need a socket set. Sometimes you use a wrench to bang in a nail because you can't find your hammer. That's a useful feature of a wrench, even if it's not what it was designed to do. > I think the rule is: if you can solve Towers of Hanoi in the language, > its general purpose enough. Indeed. And TT was designed to be general purpose enough to solve the Towers of Hanoi. I personally don't use it like that when I'm building web sites, preferring to adopt a much more rigorous coding standard, but there are also plenty of times when I do for small hacks. > To solve this problem, we added a letter. bOP is MVCF, where F stands > for Facade. Yep, I'm doing something that's roughly similar. Rather than have a facade which presents a collection of backend objects, I'm building what is, I suppose, a composite built from a collection of backend objects. The way our data is structured seems to favour this approach to my current way of thinking, but I will give the facade option some more thought now that you've mentioned it. But I think the concept is the same. You have some object or data structure which represents the collection of all the different components that combine to form one particular configuration of a site. This is our site model, a separate entity from our MVC, similar to your F. > There are some basic design rules. Eliminating redundancy is one of > them. Eliminating redundancy is another. :-) > I don't see how it is an "Aspect" (in the capital A sense). Only really in the sense that it's an orthogonal dimension in our data space. A degree of freedom, if you like. Something that cuts across a system but needs to be defined in one place (or plane). > I suspect you'll find AOP won't be in heavy use in five years except > for debugging features. The magic of OO is hard enough to understand, > and AOP is really magical. AOP also doesn't solve very many > problems. I agree, but I found it useful in the way that it helped me to identify and put a name on a common problem. Once the lightbulb went on in my head and I said "Oh, this is like the problem described in AOP" then it gave me a direction to tackle it. > Why is there so little discussion of the M in MVC? It's far from a > trivial problem. Indeed. A
