Not planned Add CalledBy Variable to All Model Functions

[Snog]

I know it's a task, but adding a CalledBy variable to all model functions would allow developers to decide if their extension to model functions should run during certain operations or not.

For example, let's say a node gets extended using a developer's table and there's no need to have that info during a rebuild, the developer could condition his extension with something like if(!$calledBy == 'deferred') and prevent it from running during a deferred process.

ie:...

public function getThreadById($threadId, array $fetchOptions = array(), $calledBy = null)

Would be called like this..

$thread = $this->getModelFromCache('XenForo_Model_Thread')->getThreadById(
           $routeUrlMatch['params']['thread_id'],
           array('join' => XenForo_Model_Thread::FETCH_FORUM),
           'inlinemod' 
         );

We already have the Hint in the listener, but this would extend that concept even farther at the model level. I can think of many instances where this would come in handy.

 

[Mike]

Doing something similar with specific methods might be viable, but I can pretty definitively say this wouldn't really happen "globally". If something like this were to happen, I don't think the calling context (eg, "deferred") is really what would be defined; it would likely represent the usage context (eg, "full" to mean that we need as much data as possible because this is a focal point).

Based on that and the particular suggestion here, I'm going to say this isn't planned.

 

[Snog]

Doing something similar with specific methods might be viable, but I can pretty definitively say this wouldn't really happen "globally". If something like this were to happen, I don't think the calling context (eg, "deferred") is really what would be defined; it would likely represent the usage context (eg, "full" to mean that we need as much data as possible because this is a focal point).

Based on that and the particular suggestion here, I'm going to say this isn't planned.

I can understand the 'full', etc. for certain functions. I only used 'deferred' because that's the process that prompted the suggestion. I was doing an import on a site that already had a large number of add-ons installed and noticed the import time was insanely long when it came time to finalize the import. After investigation I found it was the add-ons causing the long import time. And the same applied to rebuilding caches. So the idea to have the variable came to mind.

Anyway it wasn't meant as a steadfast, must have this way suggestion. It was more of a concept than anything else.

Although it would be nice globally. If an add-on only affects the member page, then a getUserByName($input['username'],'member') would allow the possibility to eliminate all other calls in other parts of the forum where the info from the add-on isn't need.

 

[digitalpoint]

Not sure it's practical, but it certainly would help a situation where I have a bunch of custom joins when loading a user related to trophies. I ended up getting super hacky with it because I didn't want all those joins happening every time a user is loaded (every page view).

Would be nice if trophy evaluation queries aren't the same as the normal one for loading a user when they are on the site.

 

[Luke F]

It's not a terribly clean solution but you could just parse debug_backtrace()

 

[W1zzard]

Have you considered using the $_SERVER global variables for detection of what page is loaded etc?