> if using a system like toolkit for a big webapplication I need to > implement the whole pagestructure twice:
False. It breaks into two parts: one query section that gets the data and sets variables, one presentation section that displays those variables in some form of HTML. > 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. Not really the same structure. > 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. Correct. > 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. Somehow it seems to me that it would be a good idea > to have the queries in the templates. If you have 50 queries to do your work, you have a confusing situation regardless. The best solution is to reuse any code where possible, and modularize where it isn't. > 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 I'm having troubles envisioning your situation. We have a host of different uses of the database here. Our solution: We will have different instance scripts that call the same module. This module will set data and call templates. (Our modules are based on CGI::Application, which helps reduce redundancy, but isn't required for this sort of setup) We have a good number of different modules that each do their own thing. So I suppose that we do end up with more than 50 scripts, modules, and templates. But they're each in their own area, so maintenance is easy. If we are changing navigation, we have one set of templates to change. If we're changing the data pulled for any given tool, we have one module to change. Because all the parts aren't globbed together, it's very easy to locate and modify any particular piece. > 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.... If that's your template, what's in the non template portion? I'm advocating having non-template code that is raw perl setting variables, and template code that is NOT perl to display. Coding is easier in perl, and non-coding is easier outside of perl. I hope I'm making some sense, I'm not clearly understanding your needs. -- SwiftOne [EMAIL PROTECTED] _______________________________________________ templates mailing list [EMAIL PROTECTED] http://lists.template-toolkit.org/mailman/listinfo/templates
