Hi,
I tried moving my mappings from the web-admin to the application.cfc.
But I have a problem with a application.cfc mapping and cfimport
This is happening:
Without Mapping:
<!— Works —>
<!— Works —>
Mapping in lucee web-admin:
<!— Works —>
<!— Works —>
Mapping in application.cfc:
<!— Works —>
<!— Fails —>
Is this a normal behaviour? If yes, please explain the difference.
Actually my idea was to have a configurationfile for everything without
touching the admin.
My System is Win7, Lucee Exress, 4.5.1.000
Best,
Michi
Mapping in application.cfc:
<!— Works —>
<!— Fails —>
Is this a normal behaviour? If yes, please explain the difference.
Sounds like what Scott Stroz put me onto in this blog article:
I never bothered to follow-up what Railo’s position was on this behaviour.On 17 May 2015 at 21:28, ‘Michael Hnat’ via Lucee lucee@googlegroups.com wrote:
–
Adam
Is there anything you haven’t written an article about?? Seriously!
Haha, well one of the main reasons I started the blog is to build a
reservoir of docs explaining issues ppl have. The other was unabashed
self-promotion. I dunno which is the primary driver 
application.cfc should work like in the admin. Especially when the admin is
telling me “take this code snippet and put it in your application.cfc”.
Certainly in the context of the bit you quote from Admin, at least that’s a
bug.
I guess it comes down to whether there should be an expectation that
works like other tags that use mappings, and in that case should
be able to use application-specific ones. TBH, I don’t see why not.
The docs don’t say anything about this one way or the
other: <cfimport> :: Lucee Documentation (probably a
candidate for an update, once the “official” position is known here). At
the very least perhaps adding “doesn’t work with application mappings”
might be a good addition… I need to work out how to edit these things, so
might see if I can add that as an experiment.On Monday, 18 May 2015 08:15:59 UTC+1, Michael Hnat wrote:
From my point of view this is a bug. I think the setting in the
–
Adam
My understanding ( from Sean Corfield ) is that cfimport is a compile
time directive, but application.cfc mappings are runtime. Hence you can not
cfimport a tag based on a application.cfc mapping.
Yeah, I’m not so sure about that being true.
If one changes the location of a mapping in admin, then reuse a file which
had previously leveraged that mapping, the change is reflected but the file
is not recompiled.
If you want real fun, try this with Adobe’s cfcompile.bat for offline
compilation.
JochemOn Mon, May 18, 2015 at 10:15 AM, Adam Cameron wrote:
On Monday, 18 May 2015 08:59:31 UTC+1, Chris Blackwell wrote:
–
Jochem van Dieten
http://jochem.vandieten.net/
My understanding ( from Sean Corfield ) is that cfimport is a compile time
directive, but application.cfc mappings are runtime. Hence you can not
cfimport a tag based on a application.cfc mapping.
Mappings in Web or server admin are known when your template is compiled,
so they work ok
This should probably be clarified in the docs for mappings (do they exist?)
and cfimport.On Mon, 18 May 2015 08:26 Adam Cameron <@Adam_Cameron> wrote:
On Monday, 18 May 2015 08:15:59 UTC+1, Michael Hnat wrote:
Is there anything you haven’t written an article about?? Seriously!
Haha, well one of the main reasons I started the blog is to build a
reservoir of docs explaining issues ppl have. The other was unabashed
self-promotion. I dunno which is the primary driver
From my point of view this is a bug. I think the setting in the
application.cfc should work like in the admin. Especially when the admin is
telling me “take this code snippet and put it in your application.cfc”.
Certainly in the context of the bit you quote from Admin, at least
that’s a bug.
I guess it comes down to whether there should be an expectation that
works like other tags that use mappings, and in that case should
be able to use application-specific ones. TBH, I don’t see why not.
The docs don’t say anything about this one way or the other:
<cfimport> :: Lucee Documentation (probably a candidate
for an update, once the “official” position is known here). At the very
least perhaps adding “doesn’t work with application mappings” might be a
good addition… I need to work out how to edit these things, so might see
if I can add that as an experiment.
–
Adam
–
You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/693c1097-d1b3-4606-a108-4f94e18615a8%40googlegroups.com
https://groups.google.com/d/msgid/lucee/693c1097-d1b3-4606-a108-4f94e18615a8%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.
Is there anything you haven’t written an article about?? Seriously!
My understanding ( from Sean Corfield ) is that cfimport is a compile time
directive, but application.cfc mappings are runtime. Hence you can not
cfimport a tag based on a application.cfc mapping.
Yeah, I’m not so sure about that being true.
If one changes the location of a mapping in admin, then reuse a file which
had previously leveraged that mapping, the change is reflected but the file
is not recompiled.
I’ve perhaps got my lunchtime blog article topic sorted out now ;-)On Monday, 18 May 2015 08:59:31 UTC+1, Chris Blackwell wrote:
–
Adam
I tried to use aplication.cfc to map a DSN a few times using the code from
the web-admin page but I didn’t have something configured correctly.
Could anybody share an example of a working cfc with mapping? I’d love to
see what works for you guys.>