Kinky ColdFusion Calendar System Now Has An Application File
Posted September 4, 2007 at 8:30 AM by Ben Nadel
A few people have asked me where my DSN information is being set in my Kink ColdFusion Calendar system. This is a totally valid question seeing as it is not set anywhere in my code. Right now, my entire testing sandbox lives under a single Application. Due to that, and the fact that I was trying to make my free ColdFusion calendar system as simple as possible, I wasn't doing any additional work to set the DSN - I was just inheriting the DSN information from the sandbox.
To make the system more clear, I have now added a new build that has a ColdFusion Application.cfc file. This file is a very simple file and defines the Application settings, the page request settings, and a single event method - OnRequestStart() - which defines the REQUEST.DSN structure. In general, this is NOT "best" practice. You shouldn't be setting your DSN information for every page request; instead, you should cache the DSN object in your APPLICATION scope or something to that effect. Again, I was just trying to keep my sub-application as simple as possible.
Hope this clears up some of the confusion.
Click here to view an online demo of the Kinky ColdFusion Calendar System.
What Other People Are Searching For
- Wanted: Full-Time ColdFusion Developer at Intoria Internet Architects
- Cold Fusion Senior Developer at Edge Information Management
- Back-End Web Developer-Information Technologist at Michigan State University
- ColdFusion Developer at Nonfat Media
- Mid-to-Senior Level Web Application Developer at SiteVision, Inc.
One thing I've always wondered about the whole REQUEST.Dsn thing is why choose the REQUEST scope over APPLICATION?
When I first started developing about 2 years back everyone seemed to opt for the APPLICATION.Dsn option, but gradualy over time I've seen people move over to the REQUEST scope for storing this information, is there any particular reason? or just a developer preference?
Excellent question. It has more to do with the way my test environment is set up. All of my testing lives under one environment, so I didn't want to make anything tied to the application - my test environment has literally thousands of files in it :) It really makes no difference in my testing, but I just didn't want to store anything in the APP in the testing.
In hindsight, I should have stored it in the APPLICATION scope. It would be a better choice.
Thanks tons for the app. I got a great leg up on my project and you showed me things I hadn't thought of yet. Appreciate your site and your work.
Always glad to help :)
Excellent work Ben.
One thing I would like to see in your calendar are the Federal holidays higlighted and labeled. That would be nice spiced up an event calendar.
Thanks for your work.
I might be a little bit dumb on this, but how do I run the SQL to install the tables and columns etc? I've never worked with an SQL file before.
I'm using MySQL on my local machine via the query browser and administrator tools.
When I try and run the script, it gives me the following error:
Script line: 1 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '[dbo].[event] (
[id] [int] IDENTITY (1, 1) NOT NULL ,
[name] [varchar] (100)' at line 1
As I have started working with MySQL lately, one of the *biggest* differences that I have seen is that MySQL does not use the bracket notation to escape values, as in [somevalue].
There's probably more to it than that, but trying removing the brackets.
Honestly, though, you'll probably just have an easier time to just manually build the tables. From what I recall, there are only like 2 or 3 tables.
I downloaded your calendar application a while back and have learned much from it, specifically, how to efficiently deal with event recurrence patterns in a CFML calendar application. I'm just stopping by here to say "Thanks!" This is another great time-saving and learning contribution.
Awesome my man - glad to help out.