>>Generally speaking imho it's best for custom tags to be >>"black boxes" >>if possible, in other words, feed it everything it needs >>as an >>attribute, and know what it returns (if anything). That >>way other >>templates never have to know anything about how the custom >>tag >>functions, all they have to know is what to pass to the >>tag and what >>to expect in response. Imho if you plan to use the custom >>tags >>directory, don't use the application scope directly -- >>feed those >>variables to it as attributes. Otherwise call the tags >>using relative >>paths (which is what I do anyway, and imho is better since >>it's more >>controlled), or a cf server mapping (which I avoid for the >>reason that >>they're difficult to get if you have shared hosting).
> I agree with you 100%. I guess I should explain a little > more what I am trying to do...maybe there will be a > solution that does not involve the application scope at > all, or maybe I'll just throw out what I'm trying to do. I > have a custom tag that parses an HTML "template" and > inserts content into specially marked regions in the > template. Since these templates change rarely (days or > weeks or months without changing), I thought that > preparsing the template and storing in a persistent scope > a representation of the parsed template, ready for content > insertion, would result in performance gains. I must say > here that I got the idea from what the Fusebox 4 Loader > file does (http://beta.fusebox.org/index.cfm?method=Fusebo > x4.basicConcepts, 3rd paragraph under the Lifecycle > section). > I naturally thought that the application scope would be > most appropriate, but I ran into the issue that it may run > across situations where no cfapplication tag has been > executed and thus the application scope is unusable. So I > wanted to be able to test for that case. Gyrus has shown > us the code to check if the application scope is usable. > So I guess my question now is, am I getting into something > messy and perhaps dangerous anyway by using application > variables in a custom tag? > It satisfies the "black box" concept because the > application variables it uses are completely internal to > the tag - caller templates do not need to know anything > about that. But it could be argued that using the > application scope as I am could cause other problems (I > can't name any, but perhaps there are potential problems) > or is just bad programming practice. But I prefer to write > well-mannered code. > Any thoughts, anyone? Hey Mike, The plan sounds pretty reasonable. The only caveat I really have is to ensure that your variables being stored in the application scope are stored in their own structure with a good, solidly unique variable name, like #application.myapp.contentstore# ... Also in CFMX I would definitely recommend using functions instead of custom tags -- functions have the advantage of being slightly more efficient than custom tags as a result of their "mixed mode" isolation -- that is, they're not as isolated as custom tags wherein you must specify the caller scope in order to reference variables from the calling template and instead require use of the var keyword / scope to isolate variables. Do remember to isolate all the function's variables however. s. isaac dealey 972-490-6624 new epoch http://www.turnkey.to lead architect, tapestry cms http://products.turnkey.to tapestry api is opensource http://www.turnkey.to/tapi certified advanced coldfusion 5 developer http://www.macromedia.com/v1/handlers/index.cfm?ID=21816 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Host with the leader in ColdFusion hosting. Voted #1 ColdFusion host by CF Developers. Offering shared and dedicated hosting options. www.cfxhosting.com/default.cfm?redirect=10481 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
