Re: Best practice question for Application.cfc
On Sun, Oct 14, 2012 at 7:27 PM, Azadi Saryev azadi.sar...@gmail.comwrote: If it is only applicationname that you need to be unique, then you could just use a hash of template path as app name, or some variation of the below: this.name = hash(getCurrenttTmplatePath()); I second this method. -Cameron -- Cameron Childress -- p: 678.637.5072 im: cameroncf facebook http://www.facebook.com/cameroncf | twitterhttp://twitter.com/cameronc | google+ https://profiles.google.com/u/0/117829379451708140985 ~| Order the Adobe Coldfusion Anthology now! http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:352912 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: Best practice question for Application.cfc
Hi Azadi, Thanks for the follow up. In this case, I'm also using the listlast() function to extract the name of the containing directory. So, my guess is in that scenario, I would not need the hash because we're only dealing with a single folder name. If that seems off to you, let me know. N . Nick Gleason | CitySoft, Inc. | http://www.citysoft.com Direct: (617) 899-5395 | Fax: (617) 507-0444 Spend Less Do More - Community Enterprise combines great features with an affordable price . . Return-Path: listmas...@houseoffusion.com Received: from mail.houseoffusion.com [64.118.74.225] by mail67.safesecureweb.com with SMTP; Mon, 15 Oct 2012 23:41:35 -0400 To: cf-talk cf-talk@houseoffusion.com Message-ID: cafczd6eray5dujyqz9pwcxqndfg543tqihedxuykvvvmo4e...@mail.gmail.com Subject: Re: Best practice question for Application.cfc References: 15d47c6$67f60c41$750c1d46$@com Date: Tue, 16 Oct 2012 12:41:22 +0900 Precedence: bulk Reply-To: cf-talk@houseoffusion.com From: Azadi Saryev azadi.sar...@gmail.com MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Rcpt-To: n.glea...@citysoft.com X-SmarterMail-Spam: SpamAssassin 0 [raw: 0], SPF_None, DK_None X-SmarterMail-TotalSpamWeight: 0 I use hash() not for security, but to 'normalize' the value of application name - to make sure it does not contain any problematic special characters, which getCurrentTemplatePath() may return (like 'C:\\some path\some.sub.path\my folder\etc etc etc\Application.cfc'). Azadi On Mon, Oct 15, 2012 at 9:20 PM, Nick Gleason wrote: Hello Azadi, Thanks for the feedback. Although I am interested in the extends attribute of the cfc for this, that seemed a bit tricky. Since all I need in the short run was to get the applicationname variable into application.cfc, I did do something similar to what you suggest. One question about the hash function in your example. Why would that be necessary here? I'm not storing this in a database at this point so I'm not sure if it's still necessary. Thoughts? Best, Nick . Nick Gleason | CitySoft, Inc. | http://www.citysoft.com Direct: (617) 899-5395 | Fax: (617) 507-0444 Spend Less Do More - Community Enterprise combines great features with an affordable price . . Return-Path: Received: from mail.houseoffusion.com [64.118.74.225] by mail67.safesecureweb.com with SMTP; Sun, 14 Oct 2012 19:28:02 -0400 To: cf-talk Message-ID: Subject: Re: Best practice question for Application.cfc References: 4f9f30b3$2f548fd9$34618e3a$@com Date: Mon, 15 Oct 2012 08:27:46 +0900 Precedence: bulk Reply-To: cf-talk@houseoffusion.com From: Azadi Saryev MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Rcpt-To: X-SmarterMail-Spam: SpamAssassin 0 [raw: 0], SPF_None, DK_None X-SmarterMail-TotalSpamWeight: 0 If it is only applicationname that you need to be unique, then you could just use a hash of template path as app name, or some variation of the below: this.name = hash(getCurrenttTmplatePath()); Azadi On Sat, Oct 13, 2012 at 10:47 PM, Nick Gleason wrote: Hi Folks, We're moving from application.cfm to application.cfc and I had a question regarding best practices. We re-use our base code and in the past, we have used a settings page that is external from the base code and unique per client to set the applicationname variable (and other variables). This is called at the beginning of application.cfm and provides with the unique application name. That same structure seems to work with application.cfc but requires calling a file at the top of application.cfc, above setting the application variables in application.cfc, to provide the applicationname. Is that approach (calling a file at the top of application.cfc to provide a unique client setting) considered a best practice for this kind of thing. Or, is there a more appropriate way? The only other thing I could think of would be to hard code the unique client applicationname in Application.cfc, but that would then require that Application.cfc be a unique file per client and thus not part of our core base code in the sense that we wouldn't include it in upgrades (so that it wouldn't over-write a unique client file with default values). Any thoughts on that? Let me know if I'm not being clear. Thank you in advance! Nick ~| Order the Adobe Coldfusion Anthology now! http://www.amazon.com
Re: Best practice question for Application.cfc
Hello Azadi, Thanks for the feedback. Although I am interested in the extends attribute of the cfc for this, that seemed a bit tricky. Since all I need in the short run was to get the applicationname variable into application.cfc, I did do something similar to what you suggest. One question about the hash function in your example. Why would that be necessary here? I'm not storing this in a database at this point so I'm not sure if it's still necessary. Thoughts? Best, Nick . Nick Gleason | CitySoft, Inc. | http://www.citysoft.com Direct: (617) 899-5395 | Fax: (617) 507-0444 Spend Less Do More - Community Enterprise combines great features with an affordable price . . Return-Path: listmas...@houseoffusion.com Received: from mail.houseoffusion.com [64.118.74.225] by mail67.safesecureweb.com with SMTP; Sun, 14 Oct 2012 19:28:02 -0400 To: cf-talk cf-talk@houseoffusion.com Message-ID: CAFcZD6dP9NYjRtW6QVzen=penxrnowx4hw-6brii9jssp0h...@mail.gmail.com Subject: Re: Best practice question for Application.cfc References: 4f9f30b3$2f548fd9$34618e3a$@com Date: Mon, 15 Oct 2012 08:27:46 +0900 Precedence: bulk Reply-To: cf-talk@houseoffusion.com From: Azadi Saryev azadi.sar...@gmail.com MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Rcpt-To: n.glea...@citysoft.com X-SmarterMail-Spam: SpamAssassin 0 [raw: 0], SPF_None, DK_None X-SmarterMail-TotalSpamWeight: 0 If it is only applicationname that you need to be unique, then you could just use a hash of template path as app name, or some variation of the below: this.name = hash(getCurrenttTmplatePath()); Azadi On Sat, Oct 13, 2012 at 10:47 PM, Nick Gleason wrote: Hi Folks, We're moving from application.cfm to application.cfc and I had a question regarding best practices. We re-use our base code and in the past, we have used a settings page that is external from the base code and unique per client to set the applicationname variable (and other variables). This is called at the beginning of application.cfm and provides with the unique application name. That same structure seems to work with application.cfc but requires calling a file at the top of application.cfc, above setting the application variables in application.cfc, to provide the applicationname. Is that approach (calling a file at the top of application.cfc to provide a unique client setting) considered a best practice for this kind of thing. Or, is there a more appropriate way? The only other thing I could think of would be to hard code the unique client applicationname in Application.cfc, but that would then require that Application.cfc be a unique file per client and thus not part of our core base code in the sense that we wouldn't include it in upgrades (so that it wouldn't over-write a unique client file with default values). Any thoughts on that? Let me know if I'm not being clear. Thank you in advance! Nick ~| Order the Adobe Coldfusion Anthology now! http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:352908 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: Best practice question for Application.cfc
I use hash() not for security, but to 'normalize' the value of application name - to make sure it does not contain any problematic special characters, which getCurrentTemplatePath() may return (like 'C:\\some path\some.sub.path\my folder\etc etc etc\Application.cfc'). Azadi On Mon, Oct 15, 2012 at 9:20 PM, Nick Gleason n.glea...@citysoft.com wrote: Hello Azadi, Thanks for the feedback. Although I am interested in the extends attribute of the cfc for this, that seemed a bit tricky. Since all I need in the short run was to get the applicationname variable into application.cfc, I did do something similar to what you suggest. One question about the hash function in your example. Why would that be necessary here? I'm not storing this in a database at this point so I'm not sure if it's still necessary. Thoughts? Best, Nick . Nick Gleason | CitySoft, Inc. | http://www.citysoft.com Direct: (617) 899-5395 | Fax: (617) 507-0444 Spend Less Do More - Community Enterprise combines great features with an affordable price . . Return-Path: listmas...@houseoffusion.com Received: from mail.houseoffusion.com [64.118.74.225] by mail67.safesecureweb.com with SMTP; Sun, 14 Oct 2012 19:28:02 -0400 To: cf-talk cf-talk@houseoffusion.com Message-ID: CAFcZD6dP9NYjRtW6QVzen=penxrnowx4hw-6brii9jssp0h...@mail.gmail.com Subject: Re: Best practice question for Application.cfc References: 4f9f30b3$2f548fd9$34618e3a$@com Date: Mon, 15 Oct 2012 08:27:46 +0900 Precedence: bulk Reply-To: cf-talk@houseoffusion.com From: Azadi Saryev azadi.sar...@gmail.com MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Rcpt-To: n.glea...@citysoft.com X-SmarterMail-Spam: SpamAssassin 0 [raw: 0], SPF_None, DK_None X-SmarterMail-TotalSpamWeight: 0 If it is only applicationname that you need to be unique, then you could just use a hash of template path as app name, or some variation of the below: this.name = hash(getCurrenttTmplatePath()); Azadi On Sat, Oct 13, 2012 at 10:47 PM, Nick Gleason wrote: Hi Folks, We're moving from application.cfm to application.cfc and I had a question regarding best practices. We re-use our base code and in the past, we have used a settings page that is external from the base code and unique per client to set the applicationname variable (and other variables). This is called at the beginning of application.cfm and provides with the unique application name. That same structure seems to work with application.cfc but requires calling a file at the top of application.cfc, above setting the application variables in application.cfc, to provide the applicationname. Is that approach (calling a file at the top of application.cfc to provide a unique client setting) considered a best practice for this kind of thing. Or, is there a more appropriate way? The only other thing I could think of would be to hard code the unique client applicationname in Application.cfc, but that would then require that Application.cfc be a unique file per client and thus not part of our core base code in the sense that we wouldn't include it in upgrades (so that it wouldn't over-write a unique client file with default values). Any thoughts on that? Let me know if I'm not being clear. Thank you in advance! Nick ~| Order the Adobe Coldfusion Anthology now! http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:352911 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: Best practice question for Application.cfc
If it is only applicationname that you need to be unique, then you could just use a hash of template path as app name, or some variation of the below: this.name = hash(getCurrenttTmplatePath()); Azadi On Sat, Oct 13, 2012 at 10:47 PM, Nick Gleason n.glea...@citysoft.com wrote: Hi Folks, We're moving from application.cfm to application.cfc and I had a question regarding best practices. We re-use our base code and in the past, we have used a settings page that is external from the base code and unique per client to set the applicationname variable (and other variables). This is called at the beginning of application.cfm and provides cfapplication with the unique application name. That same structure seems to work with application.cfc but requires calling a file at the top of application.cfc, above setting the application variables in application.cfc, to provide the applicationname. Is that approach (calling a file at the top of application.cfc to provide a unique client setting) considered a best practice for this kind of thing. Or, is there a more appropriate way? The only other thing I could think of would be to hard code the unique client applicationname in Application.cfc, but that would then require that Application.cfc be a unique file per client and thus not part of our core base code in the sense that we wouldn't include it in upgrades (so that it wouldn't over-write a unique client file with default values). Any thoughts on that? Let me know if I'm not being clear. Thank you in advance! Nick ~| Order the Adobe Coldfusion Anthology now! http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:352904 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: Best practice question for Application.cfc
Many thanks Mike and Dave. Sounds like we're in the ball park. If anyone else has different ways of doing it, let me know. Best, Nick Return-Path: listmas...@houseoffusion.com Received: from mail.houseoffusion.com [64.118.74.225] by mail67.safesecureweb.com with SMTP; Sat, 13 Oct 2012 14:12:49 -0400 To: cf-talk cf-talk@houseoffusion.com Message-ID: CAOnEp2f+=czlr6qqqsjymn6lvnqy0srlow5ts+ks8nv5+a6...@mail.gmail.com Subject: Re: Best practice question for Application.cfc References: CACi=xszchjy1aa1pzuhnjw5qktbat800vd+sasfjpmvugv9...@mail.gmail.com Date: Sun, 14 Oct 2012 05:12:19 +1100 Precedence: bulk Reply-To: cf-talk@houseoffusion.com From: Mike Kear afpwebwo...@gmail.com MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Rcpt-To: n.glea...@citysoft.com X-SmarterMail-Spam: SpamAssassin 0.6 [raw: 0.6], SPF_None, DK_None X-SmarterMail-TotalSpamWeight: 0 Which ever way you do it, somewhere or other you have to have a file that's unique to this site, or have a settings record in a database or some such. Does it REALLY make much difference if it's a site-specific Application.cfc or a site-specific Settings.xml file or a site-specific Settings table in a database? The way I do it is to have a config folder in the core code, which is where I put the site-specific things that are called by the generic core code. There's usually a config.xml with site name, application name, passwords to things. Then when I create a new site, I copy all the core code over, then go into the config folder and modify all the values in the config.xml.The config.xml file is called into a config.cfc that sets up all the application and other critical variables for the site at application start. But I dont think you necessarily need to do it the way I do.I would suggest though, that you keep all the site-specific variables in one place (in my case a config folder) so it's quick and easy to set up a new site. And also when you modify your code, you know that you can safely copy all your modified files into your other similar sites without breaking all the site-specific settings. This is not related to whether or not you use Application.cfm or Application.cfc. The same principles apply however you set up your code. But since you are changing your architecture, it's a good time to examine whether you have opportunities to make your code better organised. Cheers Mike Kear Windsor, NSW, Australia Adobe Certified Advanced ColdFusion Developer AFP Webworks http://afpwebworks.com ColdFusion 9 Enterprise, PHP, ASP, ASP.NET hosting from AUD$15/month On Sun, Oct 14, 2012 at 1:46 AM, Dave Watts wrote: We're moving from application.cfm to application.cfc and I had a question regarding best practices. We re-use our base code and in the past, we have used a settings page that is external from the base code and unique per client to set the applicationname variable (and other variables). This is called at the beginning of application.cfm and provides with the unique application name. That same structure seems to work with application.cfc but requires calling a file at the top of application.cfc, above setting the application variables in application.cfc, to provide the applicationname. Is that approach (calling a file at the top of application.cfc to provide a unique client setting) considered a best practice for this kind of thing. Or, is there a more appropriate way? The only other thing I could think of would be to hard code the unique client applicationname in Application.cfc, but that would then require that Application.cfc be a unique file per client and thus not part of our core base code in the sense that we wouldn't include it in upgrades (so that it wouldn't over-write a unique client file with default values). I think the most common approach for this sort of thing with Application.cfc is to use inheritance. You can have a base Application.cfc, then use the EXTENDS attribute to create a new Application.cfc with customized settings, overridden event handlers, etc. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ http://training.figleaf.com/ Fig Leaf Software is a Veteran-Owned Small Business (VOSB) on GSA Schedule, and provides the highest caliber vendor-authorized instruction at our training centers, online, or onsite. ~| Order the Adobe Coldfusion Anthology now! http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:352905 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Best practice question for Application.cfc
Hi Folks, We're moving from application.cfm to application.cfc and I had a question regarding best practices. We re-use our base code and in the past, we have used a settings page that is external from the base code and unique per client to set the applicationname variable (and other variables). This is called at the beginning of application.cfm and provides cfapplication with the unique application name. That same structure seems to work with application.cfc but requires calling a file at the top of application.cfc, above setting the application variables in application.cfc, to provide the applicationname. Is that approach (calling a file at the top of application.cfc to provide a unique client setting) considered a best practice for this kind of thing. Or, is there a more appropriate way? The only other thing I could think of would be to hard code the unique client applicationname in Application.cfc, but that would then require that Application.cfc be a unique file per client and thus not part of our core base code in the sense that we wouldn't include it in upgrades (so that it wouldn't over-write a unique client file with default values). Any thoughts on that? Let me know if I'm not being clear. Thank you in advance! Nick ~| Order the Adobe Coldfusion Anthology now! http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:352898 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: Best practice question for Application.cfc
We're moving from application.cfm to application.cfc and I had a question regarding best practices. We re-use our base code and in the past, we have used a settings page that is external from the base code and unique per client to set the applicationname variable (and other variables). This is called at the beginning of application.cfm and provides cfapplication with the unique application name. That same structure seems to work with application.cfc but requires calling a file at the top of application.cfc, above setting the application variables in application.cfc, to provide the applicationname. Is that approach (calling a file at the top of application.cfc to provide a unique client setting) considered a best practice for this kind of thing. Or, is there a more appropriate way? The only other thing I could think of would be to hard code the unique client applicationname in Application.cfc, but that would then require that Application.cfc be a unique file per client and thus not part of our core base code in the sense that we wouldn't include it in upgrades (so that it wouldn't over-write a unique client file with default values). I think the most common approach for this sort of thing with Application.cfc is to use inheritance. You can have a base Application.cfc, then use the EXTENDS attribute to create a new Application.cfc with customized settings, overridden event handlers, etc. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ http://training.figleaf.com/ Fig Leaf Software is a Veteran-Owned Small Business (VOSB) on GSA Schedule, and provides the highest caliber vendor-authorized instruction at our training centers, online, or onsite. ~| Order the Adobe Coldfusion Anthology now! http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:352899 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: Best practice question for Application.cfc
Which ever way you do it, somewhere or other you have to have a file that's unique to this site, or have a settings record in a database or some such. Does it REALLY make much difference if it's a site-specific Application.cfc or a site-specific Settings.xml file or a site-specific Settings table in a database? The way I do it is to have a config folder in the core code, which is where I put the site-specific things that are called by the generic core code. There's usually a config.xml with site name, application name, passwords to things. Then when I create a new site, I copy all the core code over, then go into the config folder and modify all the values in the config.xml.The config.xml file is called into a config.cfc that sets up all the application and other critical variables for the site at application start. But I dont think you necessarily need to do it the way I do.I would suggest though, that you keep all the site-specific variables in one place (in my case a config folder) so it's quick and easy to set up a new site. And also when you modify your code, you know that you can safely copy all your modified files into your other similar sites without breaking all the site-specific settings. This is not related to whether or not you use Application.cfm or Application.cfc. The same principles apply however you set up your code. But since you are changing your architecture, it's a good time to examine whether you have opportunities to make your code better organised. Cheers Mike Kear Windsor, NSW, Australia Adobe Certified Advanced ColdFusion Developer AFP Webworks http://afpwebworks.com ColdFusion 9 Enterprise, PHP, ASP, ASP.NET hosting from AUD$15/month On Sun, Oct 14, 2012 at 1:46 AM, Dave Watts dwa...@figleaf.com wrote: We're moving from application.cfm to application.cfc and I had a question regarding best practices. We re-use our base code and in the past, we have used a settings page that is external from the base code and unique per client to set the applicationname variable (and other variables). This is called at the beginning of application.cfm and provides cfapplication with the unique application name. That same structure seems to work with application.cfc but requires calling a file at the top of application.cfc, above setting the application variables in application.cfc, to provide the applicationname. Is that approach (calling a file at the top of application.cfc to provide a unique client setting) considered a best practice for this kind of thing. Or, is there a more appropriate way? The only other thing I could think of would be to hard code the unique client applicationname in Application.cfc, but that would then require that Application.cfc be a unique file per client and thus not part of our core base code in the sense that we wouldn't include it in upgrades (so that it wouldn't over-write a unique client file with default values). I think the most common approach for this sort of thing with Application.cfc is to use inheritance. You can have a base Application.cfc, then use the EXTENDS attribute to create a new Application.cfc with customized settings, overridden event handlers, etc. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ http://training.figleaf.com/ Fig Leaf Software is a Veteran-Owned Small Business (VOSB) on GSA Schedule, and provides the highest caliber vendor-authorized instruction at our training centers, online, or onsite. ~| Order the Adobe Coldfusion Anthology now! http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:352900 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
