On 2004-10-12, Thilo Planz <[EMAIL PROTECTED]> wrote:
>> However, I strongly recommend a different name. :) The current name
>> sounds like you are adding support for HTML::Template to CGI::App
>> as a plugin...which doesn't make sense.
>
> Yeah, I am not so happy about the name myself.
> But I could not come up with anything better.
The best name depends on what you consider the primary function:
Is the it the ability to handle "nearly static" pages easily, or the
'show_tmpl' system of handle data passed to the template?
Or are both of these equally important?
>> - A new and novel way of managing HTML::Template input:
>> keeping the input for each template in it's own file.
>> I don't really see the use of this. :)
>
> Well, it does away with the need to know anything about the templates
> in your runmodes, not even what
> kind of data they need/want.
>
> Simple example: You have a common page header, which makes a page title
> like this:
><tmpl_var page_title>.
> Where do you set the page title, which is arguably a presentational
> issue.
> You cannot set parameters from with your HTML::Template, so you have to
> do it in the run mode that calls
> the template. Which means the designer cannot easily change the page
> title.
>
> Another example: If you have a page that displays a BBS, you can have
> your bbs/index.html and bbs/index.html.pl which
> gathers the data for the template.
> You do not need to write a runmode to display that page.
> The data file is the mapping file between the template and your DB
> access modules.
I can began to see what you saying, but it's still hard to visualize
what this system would "feel" like. When I try to think of it, I think
of a run mode with some code in a Perl module, and some stuck out in a
.pl file, making it harder to debug.
I guess I don't really run into the "page_title" case since my shop
using Dreamweaver templates rather than having "header" and "footer"
files.
Perhaps you have a system where you have moved 95% of your functionality
into DB Access modules and other "Model" modules, so your CGI::App run
modules are virtually shells. If that's the case, I can see why you
might want to just get rid of them.
My "flow" tends to be different. I put a moderate amount of DB code
directly into the run modes, and move complex and frequently used
code into DB access modules.
That's the great thing about a flexible plug-in system-- We can each
plug-in the pieces that work best for us. If this system works well for
you, chances are that someone else will appreciate it as well.
Mark
--
http://mark.stosberg.com/
---------------------------------------------------------------------
Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
