if using a system like toolkit for a big webapplication I need to implement the whole pagestructure twice:
No, you're not following. What we're talking about here is not specifically Template Toolkit, but rather a widely used approach for separating concerns, usually called "model-view-controller." You can read a brief introduction in my article:
http://perl.apache.org/docs/tutorials/tmpl/comparison/comparison.html
However, TT does not force you to do thing this way. You could simply replace your existing HTML-generating subs with templates, as Andy suggested.
on one hand I need to implement the templates and its structure and on the other hand I need to develop the same structure in the calling perl-tool.
Separating the code that fetches the data from the code that displays the data is generally considered a positive thing. It means you can change the presentation without breaking all the SQL and business logic, or even have multiple different presentations of the same data.
example : I have two different pages gathering data from different databases. So I need two templates and in the calling script I need two different database-selects that needs to be processed depening on the call.
Only if the SQL and the presentation in the two pages have nothing in common. This is no different from what you do now -- different actions require different code.
I fear that in real-life this will create confusing hard-to-read perlscripts. If you have a big project with 50 different types of pages you need to implement 50 queries in one script or create 50 different scripts.
Again, only if there is no overlap between these queries, and this is no different from if you were not using TT.
Somehow it seems to me that it would be a good idea to have the queries in the templates.
Why? Because you're worried that it will be hard to keep track of which code needs to run which template? In practice it's quite easy on most projects. You can use the URI to help choose a template. The Apache::Template module maps requests directly to templates based on their URI. Or you can make a lookup table like this: 'SEARCH_RESULTS' => 'search_results.tmpl'.
Of course you can put the SQL in the templates. People mostly use that for simple pages which just run one or two queries and then display the result.
How do you all deal with this ? Just writing a monstrous perlscript or many small ones ? Or do you create a big library of functions that are than all passed to all templates and the template picks the needed one ?
Any of those would work. You could also follow the example of things like CGI::Application. I tend to make several medium-sized scripts that hold all the code for a single application, like "address book" or "product display."
In our current system each template contains of two seperated parts: * the html-template * some perlfuncs that are relevant to this template.
This solution seems not so bad to me....
I don't understand why you think this would change with TT.
What I see now is that the templates itself are easy to maintain with TT while other systems that allow perlcode in the templates help to keep the structure of the whole page.
TT allows perl code in the templates. It's just that the people on this list (including me) tend to discourage that approach because it usually leads to spaghetti code.
Honestly, TT is flexible enough to fit your way of working. The people on this list have used many other templating systems and would not be using TT now if it made their lives harder.
- Perrin
_______________________________________________ templates mailing list [EMAIL PROTECTED] http://lists.template-toolkit.org/mailman/listinfo/templates
