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.
TemplateDispatcher? TemplateRunner?
Ideas anyone?
- 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.
You still need to write a runmode to edit a BBS message, but that runmode does not have to do anything
related to producing output.
It can just forward to the runmode show_tmpl.
Now, if we have a way to auto-discover runmodes (using same kind of naming convention) you would not have
to write a CGI::App subclass-module at all.
You just write your business logic modules and very small dynamically included Perl files (like the data files in my plugin)
that pull things together.
Thilo
--------------------------------------------------------------------- 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]
