[Catalyst-dev] [RFC] Template and Static directory locations

Jesse Sheidlower jester at panix.com
Mon Oct 23 18:17:13 GMT 2006


On Mon, Oct 23, 2006 at 10:38:38AM -0700, John Wang wrote:
> I was recently going through the template directory structure and realized
> that it's common for templates to be stored in MyApp/root/base which I think
> is very unintuitive. The words 'root' and 'base' don't really mean anything
> to someone who is unaware of existing conventions. The MyApp directory
> itself can be considered the 'root' and 'base' directory for the app. In the
> past ./root really meant template_root but some apps have started putting
> static files in there as well.

I agree with this.

> I think it makes some sense to create a directory convention with more
> meanining say:
> 
> MyApp/tmpl or MyApp/templates for templates
> 
> MyApp/htdocs or MyApp/public for static and other files
> 
> These directory names would make cat a lot more user friendly for new users
> and have more intrinsic meaning.
> 
> I avoided MyApp/static because one advantage of having a ./htdocs or
> ./public directory is that you can put a .htaccess and index.fcgi in it and
> then just point your web server to that directory. This would make it easier
> to get some apps up and running.

I don't agree with this. I think the meaning of "static" is
extremely, perfectly clear. You can put other levels under
it--/static/images/, /static/html, /static/js, whatever.
But "static" says _exactly_ what it is.

"htdocs" may have an advantage for some Apache purposes but
it's otherwise totally opaque; even people who use Apache
regularly might not know what it means.  And it shares with
"public" the problem of not specifying exactly what it is
you're using it for. "public" suggests a certain level of
access restrictions, not a static/dynamic disparity, for
example.

> For backward compatibility I was thinking we could have a backcompat plugin
> that would be loaded by default. This way users can easily remove the
> backcompat functionality if they don't need it.

Some kind of backwards-compatibility system would make a lot
of sense, but perhaps there's a better way of introducing the
change--if we want this to be the approved way of setting up
these directories, we should find a way of making it the
default.

Jesse Sheidlower



More information about the Catalyst-dev mailing list