I'm using the CreateObject() method to create an instance of a CFC and then interacting with this newly created 'instance'. I'm doing this because that's how it seems to be done, but I don't understand why we do this.
Why can't we just interact with the CFC directly instead of creating an instance of it?
A CFC is just a file with some code in it, so it makes little sense to suggest "interacting" with it, just the same as you might suggest "interacting" with a CFM file without <cfinclude>-ing it or similar.
A CFC defines a component, and to use a component, one creates an instance of it. In some languages - eg Java - one can have static properties and methods, and one can access them via the class rather than necessarily object, but CFML does not have this concept. CFCs define components which are used as objects, just the same as in other languages a class defines what it is to be an object, and to use an object, one first needs to create an instance of it.
You can call the cfc directly using cfinvoke. You just have to realize that cfinvoke creates an object of the cfc first, then executes the method you invoked. Also, once the method is invoked, the object is no longer available.
If your .cfm page is only going to use one method of the component, cfinvoke is ok because there is less code for you to write. However, if you use two or more, it's less efficient because a new object has to be created each time.
In other word, while you don't have to create an instance of the cfc first, it's often a good idea to do so.
I hope you have read OOPs and its practices. CFC is your 'blueprint' (say a car design) and object is your own data model (say a car of blue color (method to set color), with nitrogen filled tires (method to set pressure in tires) and runs on LPG (method for fuel type)). CF allow you interact directly with CFC (CFINVOKE) and you do not have to create an instance each time but it just only make sense that you would not want to go to workshop/design lab each time you want to change a configuration for your car.
Related
In Glimmer.js, what is the best way to reset a tracked property to an initial value without using the constructor?
Note: Cannot use the constructor because it is only called once on initial page render and never called again on subsequent page clicks.
There are two parts to this answer, but the common theme between them is that they emphasize switching from an imperative style (explicitly setting values in a lifecycle hook) to a declarative style (using true one-way data flow and/or using decorators to clearly indicate where you’re doing some kind of transformation of local state based on arguments).
Are you sure you need to do that? A lot of times people think they do and they should actually just restructure their data flow. For example, much of the time in Ember Classic, people reached for a pattern of "forking" data using hooks like didInsertElement or didReceiveAttrs. In Glimmer components (whether in Ember Octane or in standalone Glimmer.js), it's idiomatic instead to simply manage your updates in the owner of the data: really doing data-down-actions-up.
Occasionally, it does actually make sense to create local copies of tracked data in a component—for example, when you want to have a clean separation between data coming from your API and the way you handle data in a form (because user interfaces are API boundaries!). In those scenarios, the #localCopy and #trackedReset decorators from tracked-toolbox are great solutions.
#localCopy does roughly what its name suggests. It creates a local copy of data passed in via arguments, which you can change locally via actions, but which also switches back to the argument if the argument value changes.
#trackedReset creates some local state which resets when an argument updates. Unlike #localCopy, the state is not a copy of the argument, it just needs to reset when the argument updates.
With either of these approaches, you end up with a much more “declarative” data flow than in the old Ember Classic approach: “forking” the data is done via decorators (approach 2), and much of the time you don’t end up forking it at all because you just push the changes back up to the owner of the original data (1).
I have a set of configuration variables (not environment specific) that need to be wrapped in a class that exposes them to the rest of the application. If all I wanted to expose was the values, I could load them via a YAML file / expose on the Rails config object, however I want the class to offer a simple API that combines / manipulates these pieces of data. This data will never change after initialisation, but needs to be used in numerous places. Storing it in the database seems like unnecessary complexity.
I initially experimented with storing state on a class and accessing it via class methods: Example.getter, but this is problematic in development due to class reloading blowing away the state. The same is true for Singletons.
Another alternative is storing them on an instance of a class, but where should that instance live? I could add it to the Rails config object and access it there, but using the config object as some kind of registry doesn't feel right: Rails.application.config.example.getter and is very verbose.
How should I store this kinds of configuration so it is easy to access from within the application?
I'm running my applications on CF 9. I created a CFC to concentrate my cookie handling instead of all the tags strewn about. It is simple. It has two attributes (name, value), and has 5 methods (setCookie, deleteCookie, verifyCookie, clearAllCookies, and init).
Since I wanted this method to be available throughout the application, I put this code in the onApplicationStart method of my application.cfc file:
application.oCookie = createObject("com.mycookie").init();
When I need to set a cookie in any code file I just call it like so:
application.oCookie.name="testCookieName";
application.oCookie.value="testCookieValue";
application.oCookie.setCookie();
My question is: Do I need to put a lock on this code each time I do this? If two separate users were to be on pages accessing this code at the same exact instant, can I end up with mixed up cookie values being set?
To make your oCookie thread-safe, it has to be a singleton (with no state) that only acts as a thin layer to the <cfcookie> or the cookie scope.
Therefore you should design your com.mycookie so that it accepts application.oCookie.setCookie(name, value) instead. And make sure you var-scope everything and don't store anything in the variables scope of mycookie.
And I don't think you need to use cflock.
If you haven't already, you may want to checkout WireBox.
I am connecting to a REST service. It's QuickBlox, to be specific, but it should not matter other than that the REST API is defined like a SQL query (but notably minus the joins) and I can do CRUD on it.
QuickBlox provides iOS SDK, which gives me an interface to construct the REST query with a callback.
In my program I want objects like User, UserResourceTable, Card, for example. (It's not exactly like this as User resides in a special QuickBlox module, but for the sake of the question it's OK to ignore this.)
I have constructed something I think is similar to the ActiveRecord pattern (I hope). So in my User class I have CRUD methods, and Card class also. And these CRUD have callbacks (or rather, Objective-C blocks which are closures).
Originally I have "read" as class method (like a Java static method), since before calling read there is nothing about the object that's read so I thought I would provide a static factory method on the aforementioned classes.
UserResourceTable is not directly expose to whoever uses the User class. It's created when User is created and read when User is read.
Now this all went OK until I started to think about unit-testing. I end up deciding to do dependency injection (DI), then I want UserResourceTable to be injected into User. But it now seems difficult to do DI while read is a class method/static method and I now think I want read to be an instance method. (Especially there is no static variable in Objective-C and even if I can use static variable in the file to kind of use it I wouldn't know when to inject it. It just smell bad to me.)
Now read would be something like this (pseudo code):
User user = User(); // user just so we can call read()
User userFetched = user.read();
A few questions:
Is it a good idea to have read as an instance method?
Is ActiveRecord suitable for my situation? Perhaps a better model?
Right now the User, UserResourceTable, and Card all directly uses QuickBlox sdk (or rather, via a thin wrapper). And I intend to inject UserResourceTable into User. I also like to inject Quickblox's interface (or the thin wrapper) into User, UserResourceTable, and Card. I would have some factories to do this. Does that sound any good?
My company has haphazardly upgraded the production server of our website to CF9, and while we were relatively lucky with very few incompatibilities, I am running into one problem that over the last week has caused me a considerable amount of grief.
Our sites use the Coldbox framework with the Transfer ORM, with function inheritance through abstract objects. Previously in CF8, when I would cfdump an object, I could view all of my setters and getters that existed in the object. However, CF9 modified the cfdump function to dump only the metadata for the object. The new CF9 documentation states that there is a metainfo tag that when set as true, should dump inherited objects (like my setters and getters for my database columns), but in this instance, it does not work.
While ultimately this isn't a back-breaking problem, it's become a considerable pain for me as I don't have rote memorization of all the functions in these objects; I'll be looking to dump a function because I know what I'm looking for but don't quite remember the name, only to find that it's not being dumped because of the way it's inherited from Transfer. I've tried the following things so far as solutions without any luck:
cfdump metainfo=true
Creating dump function in the abstract decorator
creating a dump function in the base decorator
Creating dump functions in defined override decorators
We're using the latest versions of Coldspring and Transfer, and Coldbox 2.6.4. Any insight as to workarounds or resolutions would be appreciated.
If you're not getting cfump to do it for you, first thing to do is file a bug at http://cfbugs.adobe.com/cfbugreport/flexbugui/cfbugtracker/main.html
The next thing I would do is use the Component Browser in a separate tab to keep an always ready copy of your full component documentation ready to use:
http://[yoursite]/CFIDE/componentutils/componentdoc.cfm
Faster than cfdump, save, reload, check, undo, save, retest. The component docs should show you all of your inherited methods.
if your still really want the old functionality back and you happen to have a CF8 install somewhere CFDUMP was implemented as a custom tag internaly so you grab the old one from CF8 and port it into your cf9 install.
just copy /WEB-INF/cftags/dump.cfm and rename it as you go..
how about creating a dump function that does this
<cfdump var="#myobject#" label="built-in dump">
<cfdump var="#getMetaData(myobject)#" label="object metadata">
getMetaData() would give you back your getters and setters