On donderdag 29 december 2011 17:21:18, Matthew Woodward wrote:
On Thu, Dec 29, 2011 at 5:50 AM, David Mulder
<[email protected] <mailto:[email protected]>> wrote:
Now to the actual problem: ACF (and OBD as well) don't allow
the extend attribute to be dynamic for a cfcomponent tag. In ACF
this can be solved extremely simply (although ugly) by linking to
a file in the same directory which contains a dynamic include,
however in OBD this isn't possible as a .cfc is required to
contain cfcomponent tags.
You'll have to elaborate on this. I don't understand the specifics of
the workaround, and definitely don't understand why the cfcomponent
tags matter.
Also you may just want to rethink how you're approaching things. I've
never found myself in a situation where extends needing to be a
constant is a problem, but you can also solve this by using a build
script to put in the correct values for the environment to which
you're deploying.
Personally I don't really see a reason why the attribute would
need to be "constant" in the first place,
My understanding is this is because extends is handled at compile
time, not run time, so there's no way for it to "know" what the
variables are.
Either way, if there is a real technical reason for the limitation
than I would propose that at the very least a .cfc with an include
could be handled "correctly" (in the same way as ACF does).
Again, you'll have to elaborate on what you mean by "correctly." I'm
missing something.
--
Matthew Woodward
[email protected] <mailto:[email protected]>
http://blog.mattwoodward.com
identi.ca <http://identi.ca> / Twitter: @mpwoodward
Please do not send me proprietary file formats such as Word,
PowerPoint, etc. as attachments.
http://www.gnu.org/philosophy/no-word-attachments.html
--
online documentation: http://openbd.org/manual/
google+ hints/tips: https://plus.google.com/115990347459711259462
http://groups.google.com/group/openbd?hl=en
@You'll have to elaborate on this. I don't understand the specifics of
the workaround, and definitely don't understand why the cfcomponent
tags matter.
In ACF you can set the following:
test.cfc
<cfinclude template="#application.comroot#somedir.somefile">
extendtest.cfc in same directory as test.cfc
<cfcomponent extends="test">
</cfcomponent>
@Also you may just want to rethink how you're approaching things. I've
never found myself in a situation where extends needing to be a
constant is a problem, but you can also solve this by using a build
script to put in the correct values for the environment to which you're
deploying.
It's not without reason that one is using a high level language such as
coldfusion, one of those is that you don't want to go through the
trouble of building stuff. And these global definitions are used as
they differ on development vs staging vs production.
@My understanding is this is because extends is handled at compile
time, not run time, so there's no way for it to "know" what the
variables are.
Oh, I expected it to happen when the component is created, but that
might make sense, still in that case the workaround above should work
(and either way, the component is compiled after the request right? And
at that point in time application scoped variables are set right?)
@Again, you'll have to elaborate on what you mean by "correctly." I'm
missing something.
Correctly in the sense of "in line with ACF", thus allowing a cfc with
an cfinclude and without cfcomponent tags. Hope this clarifies it a bit.
David Mulder
--
online documentation: http://openbd.org/manual/
google+ hints/tips: https://plus.google.com/115990347459711259462
http://groups.google.com/group/openbd?hl=en
