Thanks for the verification...I figured it would work that way. And, yes, all my apps are customized and relatively small at this point...no general consumption apps. Which is probably why I haven't been terribly concerned with framewords, OOP, etc., since I don't reuse much code...
However, I am starting to develop "modules" that I can plug into any site that I develop... like announcments, calendar, email newsletter, etc. That does help make site development a lot faster. I still go through the modules and customize the code for the site, however. Rick > -----Original Message----- > From: S. Isaac Dealey [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 07, 2006 12:14 PM > To: CF-Talk > Subject: RE: OOP, why me? > > > > <cfif fileExists(ExpandPath(action & ".cfm"))> > > <cfinclude template="#action#.cfm"> > > </cfif> > > > Nice idea, Isaac... So the above ExpandPath > > function assumes my processing templates > > are in the same directory as the display page? > > > If so, what how would the code change if I put > > my processing templates in directory called > > "processing" and my display pages were in the > > "html" directory? > > > (Showing my ignorance about the ExpandPath > > function...haven't used it...familiar with it, but > > not in depth...) > > I unfortunately don't find ExpandPath() to be terribly useful in my > own development because it starts from the directory containing the > base template (the one used in the browser's address bar -- I'm sure > you already knew that :) ... The way I work (with lots of > subdirectories), the path of the base template is rarely (if ever) > relevant, because cfinclude and cfmodule tags don't use the base > template as their point of reference, they use the current template. > So imo it would be _much_ more useful (that is to say -- it would be > useful period) if ExpandPath() used the current template directory as > its baseline. To give you an example why the implementation of > ExpandPath() is patently bad, lets say you have a base template > form.cfm inside form.cfm you're including another template called > switch.cfm which includes code like I described above. Now lets say > that you decide you want to move switch.cfm and all of its associated > files into a subdirectory. Here's an illustration: > > You're chaing this: > > /form.cfm > /switch.cfm > /switch_x.cfm > /switch_y.cfm > > to this: > > /form.cfm > /switch/switch.cfm > /switch/switch_x.cfm > /switch/switch_y.cfm > > Now... if you've used ExpandPath() to check for the existence of the > file as in the code above, once you've moved these files your > application won't include any of the switch_x.cfm or switch_y.cfm > templates, even though the path to the included templates which is > used in your <cfinclude> tag is correct and hasn't changed. The reason > is because although you moved switch.cfm into a subdirectory, > ExpandPath() still starts from the parent directory. > > This can be fixed by changing the code to read ExpadnPath("switch/" & > action & ".cfm"), however, then you have the name of the subdirectory > in your code. What happens if you decide to change the name of the > directory? Well... when you change the name of the directory you then > suddenly have to change this block of code again, which shouldn't be > necessary. It's understandable that you would need to change the path > in form.cfm, but needing to change the code in a template because its > _parent_ directory name changed imo is unacceptable. > > Thus ExpandPath() will _always_ produce an undesirable dependancy on > the base template directory of your application. So... I don't > recommend that people use ExpandPath() as a rule... > > I used it in my original example really because this explanation > wasn't really necessary to explain the include concept, because you > can write code that works with it (even if it's less maintainable), > because I figured you'd appreciate the simplified explanation, and > because I had the impression your applications are designed > specifically for your clients (mine are for general consumption) and > tend to be smaller anyway (didn't you say this in a previous post?) in > which case, the maintenance hassle that ExpandPath() causes is less of > an issue. > > For your specific directory structure, this (or something very close > to it) should work: > > <cfif FileExists(ExpandPath("../processing/" & action & ".cfm"))> > <cfinclude template="../processing/#action#.cfm"> > </cfif> > > I'm assuming that the "html" directory is synonymous with your web > root directory. If the html directory is a subdirectory of your web > root, then you would just drop ../ from those paths. > > s. isaac dealey 434.293.6201 > new epoch : isn't it time for a change? > > add features without fixtures with > the onTap open source framework > > http://www.fusiontap.com > http://coldfusion.sys-con.com/author/4806Dealey.htm > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Message: http://www.houseoffusion.com/lists.cfm/link=i:4:234486 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
