Application.cfc Implemetation
modius
Just a heads up on Application.cfc integration and related issues.
We're nearing completion of the work to implement Application.cfc to
replace Application.cfm/OnRequestEnd.cfm for Fortress. This has been
more complicated than originally anticipated for many reasons.
We've managed to sort out a mechanism that handles core, plugins and
projects through Application.cfc. The details are complicated and I
won't go into them here. Suffice to say we have engineered things
such that the project Application.cfc effectively "extends" a core
framework Application.cfc and is very simple to implement. Plus it
allows for the inclusion of plugin specific behaviours.
Application Specific Mappings are a furphy and do not work as
advertised in CF8. It appears that cfimport and "extends" do not
adhere to application specific mappings as defined in Application.cfc
in the same way they do to CFIDE based cf mappings. The two types of
"mapping" despite having the same name are very different in practice.
As we use inheritance and cfimport a great deal in FarCry this makes
using this feature near impossible.
The latter leaves us in a difficult position moving forward in our
desire to support stand-alone FarCry applications (ie. applications
that do not need to refer to a separately located framework location)
and multiple versions of FarCry under the same CF instance. We'd
hoped both of these options would make "getting into FarCry" a lot
easier. Not to mention significantly increased options for deploying
in development and shared hosting environments.
Our last option is to re-engineer FarCry so that it operates under the
webroot of your specific application. This would mean having no /
farcry cf mapping on the server, and relying on /farcry being
accessible from the webroot for all FarCry deployments. To accomplish
this change we will have to make significant changes to the way in
which the "webtop" is reached.
The upshot of all of this change, is that a series of significant
project level code changes will be required for anyone upgrading from
4.0 to 4.1. Well significant in that we can't script the changes.
They will include at least:
- renaming /farcry web virtual to /webtop (or removing it entirely)
- removing Application.cfm and replacing with Application.cfc (a
template would be provided with appropriate blanks to fill in)
You can track progress on this issue here:
http://docs.farcrycms.org:8080/confluence/display/FCDEV40/Application.cfc
All the best,
-- geoff
http://www.daemon.com.au/
Sean Corfield
> We've managed to sort out a mechanism that handles core, plugins and
> projects through Application.cfc. The details are complicated and I
> won't go into them here. Suffice to say we have engineered things
> such that the project Application.cfc effectively "extends" a core
> framework Application.cfc and is very simple to implement. Plus it
> allows for the inclusion of plugin specific behaviours.
That's the approach Mach-II and Fusebox 5.5 have taken.
> Application Specific Mappings are a furphy and do not work as
> advertised in CF8. It appears that cfimport and "extends" do not
> adhere to application specific mappings as defined in Application.cfc
They can't possibly: per-app mappings are a *runtime* construct
attached to a notional CF application. <cfimport> and extends= are
*compile-time* constructs applied to a specific file. You cannot
possibly have the compile-time behavior of a file depend on run-time
settings in another file - how could you use the same file (.cfm/.cfc
and associated .class files) from multiple applications??
> Our last option is to re-engineer FarCry so that it operates under the
> webroot of your specific application.
This is the approach that *all* the other CF frameworks have taken.
They let you install them under webroot on shared hosts and outside
webroot with a mapping where you have control of the server. This
seems like the right approach for FarCry (and might finally make it
easy to install! :)
> farcry cf mapping on the server, and relying on /farcry being
> accessible from the webroot for all FarCry deployments. To accomplish
> this change we will have to make significant changes to the way in
> which the "webtop" is reached.
Well, that part is the biggest bear now with installing FarCry
(especially on shared hosts).
> They will include at least:
> - renaming /farcry web virtual to /webtop (or removing it entirely)
It should be optional. There should be a standard, supported way to
install the webtop under the webroot.
> - removing Application.cfm and replacing with Application.cfc (a
> template would be provided with appropriate blanks to fill in)
This could be optional (it's optional in both Mach-II and Fusebox 5.5).
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood
modius
> > Application Specific Mappings are a furphy and do not work as
> > advertised in CF8. It appears that cfimport and "extends" do not
> > adhere to application specific mappings as defined in Application.cfc
>
> They can't possibly: per-app mappings are a *runtime* construct
> attached to a notional CF application. <cfimport> and extends= are
> *compile-time* constructs applied to a specific file. You cannot
> possibly have the compile-time behavior of a file depend on run-time
> settings in another file - how could you use the same file (.cfm/.cfc
> and associated .class files) from multiple applications??
an application specific cfmapping. Obviously it is not. You'll find
the misinterpretation is very wide spread and the documentation does
nothing to dispel the myth. Perhaps a compile-time config would have
been more worthwhile.
FarCry makes extensive use of cfimport -- custom tags are an important
part of our philosophy of keeping things simple for people who don't
want to understand the nuts and bolts of the framework. We also use
extends in very key places, not to mention would like to consider
using implements which I assume suffers from the same problems.
So Application.cfc based "mappings" are out. But heh, it's not the
end of the world ;)
-- geoff
http://www.daemon.com.au/
Sean Corfield
> I think my biggest complaint is the way this was advertised -- ie. as
> an application specific cfmapping. Obviously it is not. You'll find
> the misinterpretation is very wide spread and the documentation does
> nothing to dispel the myth. Perhaps a compile-time config would have
> been more worthwhile.
The documentation for cfimport is pretty clear that it only supports
mappings set in CF Admin.
The extends= issue is more complicated as the per-app mapping works
for the first time the CFC is compiled but you can then change the
per-app mapping and it does not change the behavior of the CFC (for
obvious reasons - well, obvious if folks think about it! :)
Application.cfc settings are, by definition, runtime. They can never
affect compile-time behavior. With <cfimport> that's why, for example,
you need it on every page that uses a taglib. It's also why
<cfprocessingdirective> must be on each page. Neither of those can be
just in Application.cfm/.cfc.
The problem isn't the product's functionality or the documentation but
CFers misunderstanding of the compilation process :)
modius
> The problem isn't the product's functionality or the documentation but
> CFers misunderstanding of the compilation process :)
documentation ;)
With respect to CFIMPORT it just repeats what was in CF7's doco. As
for Application.cfc mappings... this set of comments tells it all.
isaac dealey said on Oct 11, 2007 at 5:29 PM:
There doesn't seem to be any mention of this.mappings for setting
application-specific mappings in the Application.cfc anywhere in the
Application.cfc reference -- or for that matter -- in the
documentation anywhere as far as I can tell.
halL said on Oct 12, 2007 at 6:31 AM :
Isaac dealey is correct. The mappings variable was left out of the
Application variables table.
You can find information on using This.mappings at
http://livedocs.adobe.com/coldfusion/8/htmldocs/help.html?content=appFramework_04.html
If you follow the link provided you get this summary:
"These settings override the server-side settings in the ColdFusion
Administrator for the specified application only. Specifying per
application settings does not change the server-wide settings. To set
per-application settings, you must first enable per-application
settings on the Settings page of the ColdFusion Administrator. You
then set the mappings or custom tag paths in the Application.cfc
file."
Probably a language barrier, me being Australian and all, but it seems
very misleading to a dumb yokel like myself ;)
-- geoff
http://www.daemon.com.au/