[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [cgiapp] ::TT ::AnyTemplate and ::TemplateRunner template file name discovery


On 7/12/05, Mark Stosberg <suppressed> wrote:
> I swear I haven't had an excessive amount of caffiene latey. I think I'm
> slightly under-worked at the moment, which has given my idle mind time
> to wander...

I must be the anti-Mark then.  I have had little to no caffeine, and
have been over-worked with family and work matters.

> ::Plugin::TT and ::Plugin::AnyTemplate and ::Plugin::TemplateRunner all
> offer to guess the file name of the template for you. Ruby on Rails and
> other Hot New MVC frameworks do this, too.
> 
> So maybe there's something to it.

There is definately something to it :)  If I find myself doing the
exact same thing over and over again, then I know that it can probably
be improved.  My templates are always named the same as my subroutine
names, so I simplified my development style by automatically
generating the template filename.

> But all three of the CGI::App plugins that do this differently. Here's a
> summery of the strategies used, with commentary:

I will only speak for CAP::TT since I am familiar with it

>   -----------------------------------------------
> 
>  TT will use the current package name, so:
>      My/App/form_display.html
> 
>   This might be too verbose. It would be nice to trim off the 'My'
>   directory level, since absolutely everything might be under My/App.

I don't think it is too verbose, as it means all project templates can
exist in the same directory if you want.  We have a unique namespace
for the function My::App::form_display, so why not use that same
unique namespace for the template name.  Of course with CAP::TT you
also have the ability to generate the template filenames yourself, so
you could change it to use your technique quite easily.

>   It is prone to collisions if two instance scripts use the same module,
>   but want to have different templates. Again, that can be addressed
>   with tmpl_path(), (That's what tmpl_path is for).

That is true, but as you say, that is exactly what the include paths
are for.  In my apps, I usually have a project template directory that
contains all templates for the project.  Then I have an instance
include directory that only contains those files that need to be
customized.  The Include path is set to look in the instance directory
first.  This works very well with very little duplication.

> Which one do you prefer? Myself, I can't decide yet.

I'm sure you can guess which one I prefer ;)

Cheers,

Cees

---------------------------------------------------------------------
Web Archive:  http://www.mail-archive.com/suppressed/
              http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: suppressed
For additional commands, e-mail: suppressed


Mail converted by mhonarc 2.6.15
This archive provided courtesy of JSW4.NET, Internet Hosting Services for Small Business.