It seems clear that no solution is going to please everyone, so I
guess that means the framework shouldn't build in anything.
I do think that means that the default behavior in this regard should
be documented, with some possible alternative strategies described.
I know what I'm going to do for real apps -- Den's solution, with no
cfms or cfcs except Application.cfc and index.cfm in the web root.
It's simple and clean, with virtually no risk or overhead. It does
require some web server setup, a mapping, and a split my source code
that I haven't done before, but that's the trade-off I choose to make.
I think. Will know for sure when I have time to actually implement it
and see how it goes.
And I guess that's the point, that everyone can handle this however
they choose, once they're aware of it. For some reason I expected the
framework to manage this core bit of security, but I'm good with it
just being mentioned as a possible concern.
@Den: Do you have to do anything special for ColdBox to auto-discover
the stuff in your src directory? Or are you just pointing all your
conventions to dirs inside there?
@Mark: What "this" were you saying could be done with app-specific mappings?
In general, I like to explicitly point my conventions where they need
to go. While in development these are mappings, but when I go to
production, the sources from the mappings are compiled and placed in
the WAR. Not that I need that kind of optimization, but it's fun
anyways. =)
I've got a cfdistro (cfdistro is the tool I use to build/deploy CFML
projects- bunch of ant scripts mostly) ColdBox example deal I've been
meaning to publish for a while now, which I thought I'd get out last
week, but I ended up playing with CFEclipse code instead. Maybe this
week!
If I do get it out, I'll holler here, as it is an example of much of
the stuff I was talking about.