I am wondering what kind of ill-effects can arise from NOT using the
CFC's complete type (path) in the returntype attribute. That is, using
Returntype="Person"
As opposed to
Returntype="com.sitename.foobar.Person"
Obviously, in a perfect world the complete path would be better as its
not ambiguous and CF can perform run-time type checking (as much as
possible for, which for CF isnt that much). We are considering an
application controlled by MachII that in turn can control many
different "sites" (e.g. foo.com, bar.com, baz.com) using 1 core
"MachII" framework (at the root) and then the root index.cfm does a
lookup on CGI.SERVER_NAME to do a lookup and include the correct path
to that site's mach-ii.cfm. The idea is that every site would then
have its own set of CFCs which all inherit from a Core CFC suite (so
each site can be customized). But for every site specific CFC it would
have to specify its complete path and this wouldn't be always known.
E.g. we want to be able to quickly make a new site and use it, so all
object creations would look like:
Obj = CreateObject('component', '#Request.SiteName#.Objects.Person').init();
That is, the system is purely dynamic. But now you can see that the
returntype would have to be just the CFC name and not a complete path
since that isnt really known.
Are we going totally off the deep-end here? The idea is that we
develop 1 code-base to share amongst many different sites with a few
little tweaks here and there (done by extending core objects) but for
the most part they would all be same, except for the presentation and
view layer, obviously.
Any ideas?
Thanks in advance
/cody
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to
[email protected] with the words 'unsubscribe cfcdev' as the subject of the
email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting
(www.cfxhosting.com).
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
