I wrote earlier about my Beany component for handling Beans (especially immutable ones) easily. I thought this time I'd just cover a few extra little features that I've added to it to make it a bit easier to use.
Despite not being a big fan of Beans generally, I do find that there are situations in which they are useful. One of those is as configuration objects to pass in to a component. I can add the data in one packaged set.
In reading about Clojure recently, one of the big advantages of Clojure is immutable variables. I wouldn't want immutable variables in ColdFusion all of the time, but it would be really nice sometimes.
OK. I am finally going to bite the bullet and start using Git. This has been on my to do list for a white, but I haven't found the time. So, instead of finding the time I am just going to move open source projects that are currently on subversion over to github.
My plan is that I will then learn Git by necessity. We'll see how that works. It is a little scary to just jump in like this, but I have yet to just "dip my toes in the water" so this seems the best way.
That being said, if anyone has any suggestions for best ways to learn Git as I go or tools I can use to make this easier, I am eager to hear about them.
Here's to jumping in with both feet! I'll try to blog about my progress.
One thing that I run into frequently in my programming life is the desire to schedule events. I like CFSCHEDULE, but by iteself it has a few limitations that I don't like. It is a bit limited in the intervals available and I have to have an HTTP page set up for it.
What I want is the ability to schedule a CFC method to be run directly from that CFC. Fortunately, Scheduler.cfc allows me to do just that. Scheduler.cfc itself still requires a scheduled task to run it. Scheduler.cfc also has the ability to report data about the scheduled tasks that it has run, but (as it is just a CFC) it doesn't have a UI to report that data.
The Scheduler program solves both of those. It is essentially a wrapper for Scheduler.cfc. When the program is installed (copying it to a folder after installing Neptune), it automatically creates a "/schedule.cfm" and creates a ColdFusion scheduled task to execute it every 15 minutes (you can, of course change that). It also creates a page that reports all of the scheduled tasks running on the system as well as how long they execute (in seconds) on average, as well as the ability to see details of every time that they have run.
This information can be invaluable if you are trouble-shooting a scheduled task.
I just updated the com.sebtools to Build 11. I am really happy with the progress made here, but I think my version names stink. I can't figure out what to call versions of a package of loosely-related CFCs that have different versions themselves.
The last time I posted about a new build of com.sebtools, it was about Build 8 and A LOT has changed since then. For a full list, see the change log. Here are some highlights, however, of just a few things that I think are really neat.
Whenever I see any example saying "See how easy this is!?", I inevitably think "What happens when my needs differs a bit from the expected?". My worry is that I could start with a situation for which the tool is a good match and then things change a bit. Do I have to abandon the tool altogether in those cases? Basically, I always want to know how much elasticity any solution has.
More often than not, it seems, systems that are extremely efficient have very little elasticity (think of airline schedules where bad weather anywhere effects flight patterns everywhere). I think that the past several blog entries on Super-Easy CRUD/File Management have demonstrated that the com.sebtools package provides great efficiency for basic CRUD and file tasks. What it hasn't demonstrated (yet) is how elastic it is when the problem is more complicated than what com.sebtools is built to handle.
We have come a long way in our question to easily manage records and files. Taking advantage of the com.sebtools library, we have a single file that effectively provides a component for every table and methods for every basic action on that table. I would like to focus in a bit more on the API for these components now. Specifically, I would like to focus on how we can get the recordset we want - even for operators other than equality.
What we want is to be able to specify the exact recordset that we want - which columns, which rows, which pages - by passing in arguments. Ideally, we could do this just in our data definitions without writing any extra code.
Today we continue our quest to use com.sebtools to easily manage records and files in our example HR application. So far, we have defined our data set with XML, gotten that definition into Records.cfc, and consolated our multi-table application with ProgramManager.cfc. The last step wasn't necessary for a multi-table application, but does make things nice.
What we don't have, however, is any interaction among our tables. We have Departments and Employees, but no relationship between the two. For this example, an employee can work for one (and only one) department.
There are a few pieces of information that are helpful for most of these sorts of relationships. We would like to know the name of the department for every employee (and perhaps a boolean indicating if that employee is in a department). We would also like to have the number of employees for any given department and a boolean indicating whether or not that department has any employees. Fortunately, Manager.cfc can provide all of this for one short line of code.
Today is Tuesday, so it must be time to continue figuring out how to take advantage of the com.sebtools package to manage CRUD and files in the easiest possible way.
So far, we have defined our data set with XML and gotten that definition into Records.cfc but we have only been using one table. To be clear, there is no reason we can't continue to do things the we we have been doing them and still handle multiple tables. It is only that we would have to have a separate component for each table.
Not only that, but the goal is to have an "HR" application. It seems to be that it would be convenient to have the model for the application all tied together.
Before we talk about how to get data into Records.cfc, we should cover how the two relate. Manager.cfc actually stores all of the data structure definitions and does all of the work. It manages the database (through DataMgr) and the files (through FileMgr) and image sizing (through CFIMAGE.cfc). So, why have Records.cfc at all?