On Thu, Dec 29, 2011 at 5:50 AM, David Mulder <[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] http://blog.mattwoodward.com 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
