> Well.. To me, it's important to separate the actual code from the > templates. I want to let people that know nothing about perl to be able > to not only modify templates, but create them from scratch. All I want > to do is to create the appropriate plugin for TT(k), and document its > features.
This seems a somewhat contradictory argument to me "I don't want the template creators to have to know Perl. Instead, they'll have to know this new perl-like language". I agree completely about separating code from layout. I've been loading a code template that does any DB queries, etc, and stuffing the data into appropriate variables. The code template calls a layout template, where the data is inserted into HTML. My designer can write layout templates with very minimal Perl knowledge (From what I've seen, in line with TT templates.) I certainly haven't used TT enough to be certain about this, but browsing through the docs and the like this seems to be the case. I'm open to admitting I'm wrong if someone can show me where. This is, however, off of the point I was shooting for. I know there will be philisophical differences. I'm mainly interested in functional differences. What does Toolkit do that Text::Template doesn't? > I have only looked briefly at Text::Template, but I just think its > templates are way to complex for non-perl users. The templates are as complex as you make them to be. A simple <!-- $Name --> works just fine. Simple loops and the like can be done Perl fashion without rewriting the language. > If you're only going to use it yourself, then it's a whole new bag of > chips. I'm a primary user, but I'm not seeing the complexity differences. Again, I'm not trying to attack Toolkit. A lot of work has been done and it's obviously gained a large and knowledgable following. I'm trying to learn from the work done and apply it in a fashion I find philosophically more pleasing.
