Is there a way for a CFC function to know how its ...
# cfml-general
d
Is there a way for a CFC function to know how its been called? Whether its being called from remote, local or another component function.
s
I don't know if there's an efficient way but one option is something like this:
Copy code
try {
  throw "";
} catch ( any e ) {
  // walk e.tagContext to see what's in the call tree
}
πŸ‘ 1
I guess I'd ask: why do you need to know this?
d
the methods in question were made for remote access(frontend post requests with complex objects sent in the body), and I'm now seeing an opportunity to also use those same methods but calling them from other components server-side ofcourse. however, in order to read the complex json objects I need to deserializeJson(). So I was thinking if I'm calling my method via another component method then I don't have to deserialzieJson().
hope that makes sense.
hmm. I guess I can use isJson() to check...doooohhhhh
I figured it out. I didn't mention that i'm using Application.cfc::onCFCRequest() method to intercept those http calls then do the deserializeJson(). Well If I call those methods from another component method its just normal business - the onCFCRequest method is not intercepting anything.
s
I would generally recommend the remote methods be their own specific CFC and do all the marshaling and validation they need, then call the actual underlying CFCs/methods with that cleaned up data. That separates the business logic from the "controller" aspect of remote calling parameters and return data formatting, and makes your business logic more reusable.
πŸ‘† 4
πŸ‘†πŸ» 1
The remote API you provide should be designed for remote usage -- and that API is likely to be different than any directly callable "API" within your business domain.
(this is yet another area where making something easy for those poor CFML devs -- creating a remotely callable API automatically by just slapping
remote
on a method -- leads to a lack of thought and design of how the code should actually be structured 😞 )
πŸ‘† 2
a
Yeah too easy to forget that "MVC"-type considerations still apply in these cases too. The
remote
method should just be the controller bit.
l
There’s a bif called : callstackGet