Implement yet another way to access PW's globals

[owzim]

Currently we have those to access for example 'pages':
 

// in templates
$pages->find('something');

// in functions or classes not extending WireData
wire('pages')->find('something');

// in classes extending WireData
$this->pages->find('something');

// or even a deprecated old way
$this->fuel('pages')->find('something');

I propose to implement yet another way:
 

Wire::pages()->find('something');

// or

Wire::config()->debug;

// or

Wire::input()->urlSegements;

It would just be a matter of adding those in the Wire class:
 

public static function input() {
	return self::getFuel('input');
}

public static function pages() {
	return self::getFuel('pages');
}

public static function page() {
	return self::getFuel('page');
}

// and so on ...

Perhaps it's just aesthetics, ... for my eyes it's definitely way more pleasing.

What do you think?


 

[Nico Knoll]

I don't know a case where I would need it but I think it won't hurt to implement it either.

[horst]

I don't know if I'm right here, but isn't this the way to call static methods? (and only static methods regarding to strict mode?)

Strict Standards: Non-static method MyClass::myMethod() should not be called statically

[ryan]

Around PW 3.0, I'm looking to make PW multi-instance compatible so that you could have multiple ProcessWire instances (each connected to separate databases) running from the same PHP code. This opens a huge amount of flexibility. But it also means that any kind of static references will have to disappear because function calls like Wire::getFuel('var') and wire('var') make the assumption that there is only one instance of ProcessWire running. This is one of the bad things about static calls in general. When that time comes, we will be able to apply contexts to our template files so that calls like wire('var') still work. But the reality is that non-static calls like $this->wire('var'), $this->var, and $var are technically superior when it comes to a multi-instance environment. So my opinion would be that it's not good to introduce new static calling methods when they may soon be obsolete.

[horst]

Around PW 3.0, I'm looking to make PW multi-instance compatible so that you could have multiple ProcessWire instances (each connected to separate databases) running from the same PHP code.

 

OMG, Ryan! Then I need for sure a seat belt at the office chair, avoiding liftoff. 

[owzim]

I don't know if I'm right here, but isn't this the way to call static methods? (and only static methods regarding to strict mode?)

Strict Standards: Non-static method MyClass::myMethod() should not be called statically

Not sure what you mean. Of course you can only call methods statically if they're static.

Wire::input();

... would be a static call, yes.

Did I misunderstand?

[owzim]

Around PW 3.0, I'm looking to make PW multi-instance compatible so that you could have multiple ProcessWire instances (each connected to separate databases) running from the same PHP code. This opens a huge amount of flexibility. [...] So my opinion would be that it's not good to introduce new static calling methods when they may soon be obsolete.

Great news Ryan.

Would it then not be possible to make even the static calls like wire('var') aware of their contexts? I mean at the moment a wire('page') call is ware of it's page context, it knows on which pare we are currently on. In classes, couldn't we apply that also to some kind of DB context awareness then?

How would a module know on which PW instance it's currently working on? I assume that the instance properties, like $this->input or $this->page are somehow set in the background and the access of them code wise would not change for a module dev, right? So why wouldn't it be possible to have a static call also have a context (PW instance)?

[ryan]

Would it then not be possible to make even the static calls like wire('var') aware of their contexts? I mean at the moment a wire('page') call is ware of it's page context, it knows on which pare we are currently on. In classes, couldn't we apply that also to some kind of DB context awareness then?

Feasibly it's possible, but it's not desirable. Making wire('var') aware of context involves pre-compiling the template files to replace wire('var') with wire($this, 'var'). So it's something we do to provide backwards compatibility in template files. We won't be providing that backwards compatibility outside of template files, so people will have to use $this->var, $this->wire('var') or wire($this, 'var'); elsewhere. Also, a Static::syntax implies dealing with a framework that only has one context, which gives the appearance of a weakness that isn't there, something I think we'd want to avoid. While I'd really like to limit statics in ProcessWire as much as possible (just because they are more than often a bad programming practice), that syntax is perfectly fine for static functions where context doesn't matter or where you are passing the context into it. For example, $sanitizer functions would not need to have different behavior in different contexts. I've even seen some frameworks that do use statics for sanitization functions as well. In the end though, IMO they would still be better served by providing the same functions non-statically. 

How would a module know on which PW instance it's currently working on? I assume that the instance properties, like $this->input or $this->page are somehow set in the background and the access of them code wise would not change for a module dev, right? So why wouldn't it be possible to have a static call also have a context (PW instance)?

The plan is that when you do this...

$main = new ProcessWire('/site/');
$intranet = new ProcessWire('/site-intranet/');

...everything in each of those two instances will be unique to those instances and whatever site files are stored in /site/ or /site-intranet/. That means that when a module is initialized, it is only initialized for the instance (whether main or intranet). When a module refers to $this->var, it's referring to API variables that are part of its instance only. This enables you to have multiple sites talking to each other. 

Currently this isn't possible precisely because PW uses statics for API variables behind the scenes. But the fact that we've kept that behind the scenes is a good thing because that means it doesn't matter how our API variables are stored. We can switch them to a stronger storage mechanism that would be tied to an instance. This is one reason why I deprecated the Wire::getFuel() syntax (that appeared in early versions of PW2) early-on... though you might still see it appear in a few core spots, which will need to be changed. But we've really tried to keep the public API clear of static calls so that the API would not have to change as PW continues to grow as a framework.