Ok, this may sound like a somewhat cryptic title. We are talking about the importance of this, and now I mean the
this keyword. To be honest I never worried too much about the
this keyword. I know it is a component scope and when you refer to
this inside your component, you refer to the public scope, so everything from this component which is visible to the outside world.
But now I had some issues (explanation will follow). I was surprised to see how hard it was to find a decent explanation of the this component scope. Not easy to google, because ‘this’ shows up in a lot of web pages…
Using dynamic datasources in a cfml ORM system can be hard. I am working on some project full of cform, and as mentioned in my post on dynamic datasources in qb I have a project with a lot of legacy code, full of cfquery, queryExecute, some qb queries and… tons of cform entities. And for all this code I should be able to change my datasource on the fly, based on URL or the authenticated user. I already had all solutions in place for qb and queryExecute, but cform is a showstopper. Back in CF9 when cform was introduced you could only work with ONE datasource, the default datasource. Since default datasources where introduced in CF9 I suspect this was only done to accommodate for the lack of datasource awareness of the cf9.0 orm entities. In CF9.01 this became slightly better when we could specify some datasource property, but it has always been a pain to get this right. And unfortunately we often worked with a multidatasource setup. When we switched from Lucee 4 to 5 it took several years before a very important multi datasource bug was fixed. And now we even needed dynamic datasources, which is a real NO! in cform. So how about
In the past I’ve been using cborm a lot, since it makes handling coldfusion (hibernate) ORM so much easier. But lucee support for ORM was less than optimal in a multi-datasource environment, so I decided to rewrite this application more or less according to the fluent API approach as demonstrated by Gavin Pickin at ITB 2020. In this coding style I have two quite efficient ways of populating a new object:
property name="UserService" inject;
var user = populateModel(
//vs a shorter method
var user = UserService.new( myUserData );
Both should return the same populated user object, but the second one does the population within the new() method, so I got used to using this handy method.