@izharaazmi tested your plugin following your test instructions and all seems to work fine.

In code review, notice some minor things IMO:
1. the message when you have no installer plugins enabled should be a warning (yellow), not success (green).
2. There are some code style issues (missing since tags, php variables naming, etc).

Note: you could also use the new loading logo js layer (used now in joomla installation and install languages - see https://github.com/joomla/joomla-cms/blob/staging/administrator/components/com_installer/views/languages/tmpl/default.php#L20-L30)

Thank you! I'll look at these points next morning.

Can you please elaborate what about php variables naming and where do you
suggest to use the loadingLayer ?
You said "etc", are their more code style issues than the two listed by you?

Can you please elaborate what about php variables naming

For instance, this:

$show_info    = ...;
$webinstaller = ...;

shouldn't it be?:

$showInfo     = ...;
$webInstaller = ...;

You said "etc", are their more code style issues than the two listed by you?

for instance, The xml attributes order:

    <field
        name="install_directory"
        label="PLG_INSTALLER_FOLDERINSTALLER_TEXT"
        type="text"
        class="span5 input_box"
        size="70"
    />

should be

    <field
        name="install_directory"
        type="text" <--- this is before the label
        label="PLG_INSTALLER_FOLDERINSTALLER_TEXT"
        class="span5 input_box"
        size="70"
    />

You can check the coding standards here: https://joomla.github.io/coding-standards/?coding-standards/chapters/xml.md

See #10450 for my proposal how to solve the same (I think) issue.

@Bakual Yes. Almost same but not exactly. I was there and discussing about this idea. With this PR I propose to move the plugins calls to the model and make them independent of the layouts/templates. Use of JForm also allows us to keep the plugins possibly away from raw html code.

Imho it's a bit overengineering to use JForm. And it will only work for the simple core install types. It will never work for the "Install from Web" plugin. So you always will have $this->installTypes which contains either a JForm element or a string. Sounds a bit like flawed architecture to me.

What I also don't like is the call to JHtml::_('bootstrap.startTabSet', 'myTab'); in your model. The model shouldn't do HTML stuff at all. That's up to the layouts which is the reason I didn't move it away from there.
We can do it better with the new plugin event and move it eventually to the view (which imho is the correct place to call such plugin events), but due to B/C we have to keep the old events and those ones belongs to the layout due to the way they are set up.

What I also don't like is the call to JHtml::_('bootstrap.startTabSet', 'myTab'); in your model.

It is called there just not to break b/c with plugins generating tabs themselves, however the html returned is ignored already. I understand that it is still bad to be in the model. We can move to view if you suggest, that may be a better substitute likely than in the layout.

So you always will have $this->installTypes which contains either a JForm element or a string

No. The $installType->form is never supposed to contain html. If one really needs they may use a custom form field class, hence still allowing to override html layouts per template. That is what we do in Joomla. Relying on direct html output (whether echoed or returned) is not reasonable. And we don't only use 'hathor' and 'isis'.

due to B/C we have to keep the old events

Yes, those events are kept and still being fired. The output is stored in the $installType->html which is used if the plugin didn't product a JForm object.

PS: This weekend I'll be doing few tweaks in install from web plugin and then submit a PR for that too.

No. The $installType->form is never supposed to contain html. If one really needs they may use a custom form field class, hence still allowing to override html layouts per template. That is what we do in Joomla.

I didn't talk about $installType->form but about $installType itself. The webinstaller will always return the HTML you need to echo out. I don't think it can be done in a JForm.
And there may be 3rd plugins in future now that it is possible to extend the installer. I think JForm is to limiting here.

Relying on direct html output (whether echoed or returned) is not reasonable. And we don't only use 'hathor' and 'isis'.

We actually do that in multiple plugins. We could use layout files in the plugins if overriding is an issue here. But if you look at the plugins, all they really do is returning an input element and a button/link. Except the webinstaller plugin which does a lot more and doesn't fit into a JForm as said.

I didn't talk about $installType->form but about $installType itself. The webinstaller will always return the HTML you need to echo out. I don't think it can be done in a JForm.

The returned html in that case is stored in $installType->html instead; assuming it a old plugin ouput format. The new format always returns an object {name, title, description, button, form}. With this we can promote the newer extensions to be built this way and retain functionality of the existing ones via fallback to $installType->html. Otherwise we'd be forcing everyone to continue the same approach.

We actually do that in multiple plugins. We could use layout files in the plugins if overriding is an issue here. But if you look at the plugins, all they really do is returning an input element and a button/link.

I agree. This approach is good too. However, to guide everyone we'd need to convert our plugins to this structure. Most developers just start off with copying existing Joomla extensions. So we define the standards. Would you please rewrite those plugins using layout files in your PR #10450 ?

Would you please rewrite those plugins using layout files in your PR

Done.

@andrepereiradasilva I have made the required codestyle changes. Please test/verify.

I think this is obsolete now. Closing.