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

[Matt S Trout]

Jesse Sheidlower wrote:
> 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.

web-data ?

I guess static is probably ok actually, since the .htaccess can remap stuff 
onto the fcgi handler anyway?

>> 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.

We need no compat mode. This can all be done from config.

Just change the scaffolds to generate config for this layout.

End of problem.

-- 
      Matt S Trout       Offering custom development, consultancy and support
   Technical Director    contracts for Catalyst, DBIx::Class and BAST. Contact
Shadowcat Systems Ltd.  mst (at) shadowcatsystems.co.uk for more information

+ Help us build a better perl ORM: http://dbix-class.shadowcatsystems.co.uk/ +