-
Notifications
You must be signed in to change notification settings - Fork 107
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Drop AbstractView::initDefaultApp and App::init methods #1968
Conversation
b531f60
to
23a9ce7
Compare
7899ee3
to
dbae15d
Compare
dbae15d
to
6878438
Compare
8937e1e
to
71d8fbf
Compare
@@ -68,6 +68,7 @@ public function addActionMenuItem($item, $action = null, string $confirmMsg = '' | |||
$item = Factory::factory([View::class], ['name' => false, 'ui' => 'item', 'content' => $item]); | |||
} | |||
|
|||
$item->setApp($this->getApp()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
in theory, app can be already set if an object with an app preset is passed
@mvorisek Using invokeInit heavily, how can I set app manually? My central app class is set using $app = new App and then $app->invokeInit() is called, as around 50 models require App Scope right away. What is the recommended solution for this BC-break? |
there should be no or minimal BC break if you use App in Models |
Creating many implicit apps can imply negative performance and/or unexpected (other than configured, like implicit UI persistence comma) behaviour, both hard to debug.
If you call
View::invokeInit()
manually (not recommended, but needed for edge cases), then you need to set the app manually before the call.This PR also asserts app is set no later than in init, this requirement may be drop in the future, but currently it is needed to load a template which is defined in almost every View.
Also drop
ExecutorFactory::create()
method in favor ofExecutorFactory::createExecutor()
.