Just a reminder about variables

Just posting a reminder to everyone about watching out for variables in functions. I had one function where I was treating my loop variables how I would in java (in that I had the insane assumption they would be created and recycled automatically with no issue inside the for statements).


ORM Queries and Where in

Was updating some backend stuff on our customer site when I came across some code I had done right when I started to work with ORM in Coldfusion 9. I was using the quick ormexecutequery() function, and needed to do where [field] in (list). Originally I tried this:

view plain print about
1ormexecutequery('select name from area where id in (?)',[idList]);

I then tried doing different manipulation on the id list before putting in there, javacasting and using arrays, as that was the typical solution else where when dealing with Hibernate/ORM

I couldn't get it working, so I ended up doing the dreadful:

view plain print about
1ormexecutequery('select name from area where id in (#idlist#)');

Upon realizing I had that in my codebase, I took the Coldfusion ORM Google group and after a bit of searching, I found a link to a comments section on Adobe's help pages.

You see you can do what I was trying to do with making the idlist an array, but you have to use named parameters.

view plain print about
1ormexecutequery('select name from area where id in (:areaid)',{areaid=idarray});

Lucky save because otherwise I would have had to have gotten my list length, and then looped through it, to create a string of the the amount of question mark's I needed, using that in the ormexectequery() and then use the array on the end. While that would have worked, this is much better.

FW/1 and Dependency Injection

I recently started on the process of upgrading our customer website to the latest (and alpha version) of FW/1. Part of the reason of this upgrade was to implement Sean Corfield's DI/1 (Dependency Injection)

We have been using Coldspring for a long-time, and while its easy to use, something Dave Jr and I have always disliked is XML configuration. DI/1 will allow us when we create another gateway, service or bean to just drop it into the relevant folder, reload the application, and away we go.


How I started with Coldfusion

My first exposure to Coldfusion was with the company I am currently with, Construction Monitor. I was hired by them through a friend after my first year of university. My responsibilities when I started there did not include or have much to do with web development. I was doing tech support, and networking administration (fairly easy considering the size of the company is less then 25). I worked for them full-time that summer, and then went down to part-time during the school year. Sometime in my second year at school, and second summer with them I was forced to start poking about with the website for one reason or another.


Hibernate Criteria In-depth Part 2

Our main search in our application is Powersearch and it's a search that can be used both logged in and logged out.

Detailed views and exports are disabled while not logged in, but overall the tool is mostly the same whether logged in or not. When someone is logged in though, we have to filter by what they have access to (in terms of construction categories: residential vs. commercial, date ranges, new customers have to pay for access going back, and what market areas they want).


Hibernate Criteria In-depth Part 1

There's a lot of little things to working with Criteria objects.


Hibernate's Criteria Queries

Criteria Queries are an objected-oriented approach to building database searches. Where exactly do they fit in though? If you are just using normal SQL in Coldfusion and are comfortable with continuing to do that, criteria is probably not the technology to jump too. If you are have moved to using the built in ORM in Coldfusion and have moved away from writing traditional SQL in preference to HQL you may find have an interest in leveraging Criteria.