|
Hi Gary,
I was just thinking just then (i do that from time
to time) on CFIMPORT and mappings, couldn't you create an application variable
that points to the relevant paths through-out your application. So that when you
use the power of CFIMPORT (on every frikin page, to which i agree sux biggins)
it won't affect your code in anway thus your different development environments
can be kept independent of server mappings via your application scope (thexy
cfshared object is what i call application scopes :D)
This would get around the Ignorance of CF Mappings
(CFMX and Mappings seem to me personally as an unportable solution, especially
if your in a shared hosting environment.. but like you we have our own thexthy
beasty production environments so i can see the benefits of just using them vs
long winded pathing).
but yeah, also using CF Mappings you are hit with
other penalities, especially in way of Flash Remoting (ie if your store your
CFC's in a CF mapped environment, it can lead to potential... what the [EMAIL PROTECTED]!!!)
To me like you said earlier, seems like the Java
Runtime compiler uses the CFIMPORT as a direct reference to pull information
from a taglib, but then if you where to compile such code, i can see another
dangerous aspect in that what if you where to do a CFIMPORT within a CFIMPORT?
you could end up doing a freaky cycle of gathering code at runtime and putting
it into java logic!
While i hate having to do the cfimport at the top
of every freaking page, i'd also love the ability to do it once (i'm a big
shared object fan), but sadly i personally can see it never happening as it
could become a bit of a resource demand? I'd love to see more info on this
aswell as i rely on the CFIMPORT concept for presentation layer logic
bigtime.
Scott
While I absolutely love the new <CFIMPORT>
functionality of CFMX I have a number of gripes about it's
implementation.....
1. It is not
possible to specify the TAGLIB parameter as anything but a constant string.
If I could specify a variable then I would be really happy and my other
gripes would go away. This is an issue because of other points
below....
2. The <CFIMPORT>
*MUST* be inline on the page you want to perform the import into. You
cannot put it into another CFM file and perform a <CFINCLUDE> on it.
If you could do this, you could then easily change just one file (the
<CFINCLUDE> one) and have all your pages get their tags from a different
path).
3. <CFIMPORT> ignores
CF mappings.
(NOTE: I have thought
of another possible solution to my problem and that would be putting the
<CFIMPORT> tags into Application.cfm - but I think this may provide the
same sorts of problems as using <CFINCLUDE> - I will try that after
sending this and report back if I find joy)
Why is this a problem?
Well.... if you create a generic <mytags:page>
tag for all of your CFMX pages you need to <CFIMPORT> at the top of each
page. This is fine except when your devlopment and production
environments may have different root paths for storing some of this
stuff.
For example:
I develop a lot of stuff on my laptop.
This is my own laptop and I do stuff other than for my main employer on
it as well. I store my custom tags in a directory called /system/cftags
(for example). However, work stores them in a directory called
/work-system/cftags (names changed to protect the guilt). I dont want to
have a /system/cftags and a /work-system/cftags (and any number of other
possibilities if I develop for multiple locations).
So - when I have to port my development code from my
laptop to works acceptance and or production systems I am in the place where I
have to go and edit the files that have <CFIMPORT> in them (either
manually or automatically - the point is I should not have to).
Now.....
I am guessing I know exactly why this is the
case......
<CFIMPORT> is
probably NOT actually a CFMX tag but is actually a mechanism to provide an
instruction to the Java compiler. It just looks like a tag.
Therefore, CFMX really knows nothing about it as far as it actually
being a "tag" and when CFMX actually sets up it's environment with variables
and suchlike, this "tag" has been consumed in the compilation process.
BUT.....
That does not make my life for using <CFIMPORT>
any easier - and the functionality of "custom tags" that it provides is just
SO useful that I dont want to abandon it.
It really shows promise for creating complex systems, but then falls
down when trying to maintain those complex systems if you need to migrate
between different environments or you need to make architectural changes to
the site.
Can any of the MM people
on the list shed any light on any possible future enhancements/changes that
may alleviate the above issues?
Gary Menzel
IT Operations Brisbane -+- ABN AMRO Morgans
Limited
Level 29, 123 Eagle Street BRISBANE QLD 4000
PH: 07 333 44 828
FX: 07 3834 0828
****************************************************************************
If this communication is not intended for you
and you are not an authorised
recipient of this email you are prohibited by law from dealing with
or
relying on the email or any
file attachments. This prohibition includes
reading, printing, copying, re-transmitting,
disseminating, storing or in
any other way dealing or acting in reliance on the information. If
you
have received this email in
error, we request you contact ABN AMRO Morgans
Limited immediately by returning the email to
[EMAIL PROTECTED]
and
destroy the original. We will refund any reasonable costs
associated
with notifying ABN
AMRO Morgans. This email is confidential and may contain
privileged client information. ABN AMRO Morgans
has taken reasonable steps
to
ensure the accuracy and integrity of all its communications,
including
electronic
communications, but accepts no liability for materials
transmitted. Materials may also be transmitted
without the knowledge of ABN
AMRO Morgans. ABN AMRO Morgans Limited its directors and employees do
not
accept liability for the
results of any actions taken or not on the basis
of the information in this report. ABN AMRO Morgans
Limited and its
associates hold
or may hold securities in the companies/trusts mentioned
herein. Any recommendation is made on the basis
of our research of the
investment and may not suit the specific requirements of
clients.
Assessments of
suitability to an individual's portfolio can only be made
after an examination of the particular client's
investments, financial
circumstances and requirements.
****************************************************************************
---
You are currently subscribed to cfaussie as: [EMAIL PROTECTED]
To unsubscribe send a blank email to [EMAIL PROTECTED]
MX Downunder AsiaPac DevCon - http://mxdu.com/
|
