Hi Peter, Thanks for response, Yeah generally we use relative or calculated paths in this case its actually some very trippy code that reads in the CFC as a file and parses it for cfproperty tags. The reason we do that in addition to using getmetadata(this), is then in our ORM we can have
com.api.news <cfproperty> tags like CF9 ORM with com.api.customisednews extends com.api.news <cfproperty> an additional tag So ORM function driven from <CFPROPERTY> aka cf9 but with extendable and overloadable properties, The thing that was breaking our code was the fact that the path wasn't referencing a valid file, the path itself could have been anything Thanks Alex On Feb 9, 1:38 am, "Peter J. Farrell" <[email protected]> wrote: > AlexS said the following on 02/08/2011 06:40 PM:> So I guess its a config > change somewhere. > > Yeah, check the bluedragon.xml config file. As Jordan just mentioned, > it's just something the installers miss.> We use this path as part of our ORM > to do inherited properties, its > > not a big deal for me and I can patch our code to deal with it but in > > the interests of reporting the weird ones. > > Thank you for reporting this stuff -- it makes OpenBD a better project > in the end. > > Just to go OT to code on this. I've been burned before by other > developers that rely an path as indicated to do stuff -- especially > absolute paths. I'm not exactly sure what the path is driving and how > that is being done, but you might consider using the CFC dot path > instead -- those can be mapped and are relative in nature. I always > recommend refactoring any code that relies on absolute paths -- it's a > maintenance nightmare. > > .pjf -- tag/function ref: http://www.openbluedragon.org/manual/ mailing list - http://groups.google.com/group/openbd?hl=en Get to Texas in Feb for OpenCFSummit http://www.opencfsummit.org/
