Repository navigation
Class imports in page logic
Page logic files can use application classes in function parameters, constructor calls and static method calls. PHP needs the class's namespace to resolve its name correctly.
WebEngine gives classless logic files a generated namespace so several files can define functions such as go() without colliding. For example, page/index.php uses a namespace ending in page\index_php.
If we use AnotherThing without importing it, PHP looks for it relative to that generated namespace. The resulting error might mention:
GT\AppLogic\page\index_php\AnotherThing
When the name appears in a logic function parameter, the service container can throw ServiceNotFoundException. A constructor or static method call can instead produce PHP's Class not found error. Both can have the same cause: a missing class import.
This applies to shared files such as _common.php and nested page logic too. The generated namespace is an implementation detail; we do not need to create an application class inside it.
If AnotherThing is declared in the App namespace, import it at the top of the logic file:
use App\AnotherThing;
function go(AnotherThing $anotherThing):void {
$anotherThing->run();
}The import also applies to new AnotherThing() and static calls within the file. Use the namespace where the class is actually declared, which may differ from App.
Alternatively, use the fully qualified name:
function go(\App\AnotherThing $anotherThing):void {
$anotherThing->run();
}Check that:
- the class name and namespace are spelt correctly
- the import is in the logic file that uses the class; imports in
_common.phpdo not apply to other files - the class file is in the expected location for its namespace
- Composer's autoloader includes any external package that supplies the class
See application classes for the project's namespace and directory conventions, and Service Container for dependency injection.
In development mode, WebEngine adds a friendly explanation, a suggested action and a link to this page when it recognises this error. The original exception message and trace remain available. The explanation describes a likely cause, so it is still useful to check spelling and autoloading before changing the imports.
The built-in HTML error response displays the guidance automatically. JSON fallback responses include it in a separate context object. Custom error pages can display it using the bindings described in errors and logging. The extra guidance is omitted when app.production is enabled.
- File-based routing
- Page views
- Page logic
- Dynamic URIs
- Headers and footers
- Custom HTML components
- Page partials
- Binding data to the DOM
- DOM manipulation
- Hello You tutorial
- Todo list tutorial
- Address book tutorial WIP
- Blueprints
- Application architecture
- Coding styleguide WIP
- PHP environment setup WIP
- Web servers WIP
- Background cron tasks
- Database setup WIP
- Client-side compilation WIP
- Testing WebEngine applications WIP
- Production checklist WIP
- Security WIP