Color picker in CFEclipse

Did you realize that the color picker in CFEclipse can actually choose colors from outside the Eclipse window?   Pretty sweet stuff!   To do this, you just click the color pallet icon at the top, then choose the eye dropper tool.  You can then use the eye dropper to select a color anywhere on the visible desktop, even outside of the window.   This will set the color to what you selected and display the hex value.

Another +1 for things I like about using CFEclipse!

EDIT:
I just realized that my Windows version of CFEclipse had a completely different color picker than my installation on Ubuntu .  I have not updated CFEclipse on that machine in a while so I am guessing that this was one of the updates. (See Rob Rohan’s reply below)    This is what the one I am referring to looks like:

rob said:
The color picker actually invokes the system color picker so it looks and behaves differently on Linux, Mac, and Windows. The feature you are talking about only works on Linux and Mac I believe (unless windows itself updated the color picker). Still very helpful for those of us on Mac and Linux ;)

Reactor is not just for database abstraction!

Even if database abstraction was all that Reactor did, I would still use it because it does it very well.  However, the more I use it the more I realize that that is actually just a small part of what I love about it.

Take for example the current application that I am working on.  It is a mortgage loan application where a User can have multiple LoanApplications.  A LoanApplication can have multiple Borrowers.  Borrowers can have multiple Properties.  Properties can have multiple Liabilities.

While it is certainly possible to hand code these relationships in your CFCs, it is a *LOT* of work.  In our new efforts, we are taking the following approach and finding that it is a sweet way to go.

To explain a bit, we are refactoring an application that does about 40 bazillion queries on every request as a user steps through 9 tabbed pages in the application.   We have modified that approach quite a bit.  In our new model, the loan application itself it a single HTML document with client-side tabbing.     Before the user steps into the application, we have loaded a very basic LoanApplication object into our LoanApplicationFacade.  So now when we need to access/modify any data, we can access it through that single entry point.

Our active LoanApplication starts out with just some very basic details and a single borrower.  As the user walks through the application we are using AjaxCFC to update and construct the LoanApplication object behind the scenes.  This is where Reactor really begins to come into play.

For instance, say we add a co-borrower.  This is as simple as this:

CoBorrower = LoanApplicationFacade.getLoanApplication().getBorrowerIterator().add();

Just by doing this, we now have a second borrower that is part of the loan application.  When we add an asset property to this CoBorrower, we can do this:

NewProperty = CoBorrower.getPropertyIterator().add();

… and so on.  Using these relationships, managing the entire LoanApplication object is a breeze.

So, say for some reason I want to create a list of all cities that the Borrowers own property in.   I can do something like this:

<cfset CityList = “” />
<cfset BorrowerIterator = LoanApplicationFacade.getLoanApplication() />
<cfloop condition=#BorrowerIterator.hasMore()#>
<cfset ThisBorrower = BorrowerIterator.getNext() />
<!—  now loop through this Borrower’s Properties —>
<cfset PropertyIterator = ThisBorrower.getPropertyIterator() />
<cfloop condition=#PropertyIterator.hasMore()#>
<cfset ThisProperty = PropertyIterator.getNext() />
<cfset CityList = ListAppend(CityList,ThisProperty.getCity()) />
</cfloop>
</cfloop>

The cities are: <cfoutput>#CityList#</cfoutput>

So back to our application, we have decided that databases are overrated!  Rather than continually making these unnecessary round trips, we are just building this object into memory.   We are only actually persisting it under two scenarios, those being if the user actually submits their loan application, or OnSessionEnd().   Now, that we are actually to the point of database interaction, I can point out another really cool piece of Reactor.  Rather than looping through all of these objects by hand, saving them, then saving the relationships, etc., the beauty of cascading saves comes to the rescue!    For example, in our Application.cfc OnSessionEnd(), we have the following code:

try    {
if (LoanApplication.loanApplicationExists())    {
LoanApplicationFacade.getLoanApplication().save();
SessionSaved = true;
}
}
catch(Any excpt)    {/* an error occurred while saving */}

Now obviously it is a HUGE thing that we only have to call a single save() to save everything about our LoanApplication, but to me this still isn’t the big deal.  The truly big deal to me is the ease at which I can manage these relationships.  In fact, with the way these relationships are structured, writing save routines by hand would be a breeze as you can see in the Reactor core files.