Clean Adminhtml: Mage_Api blocks

[sreichel]

Description (*)

I'd like to get rid off Adminhtml. It is just a collection of classes that belong to a specific module. (in most cases)

My idea is to move all code to correct place and keep empty/deprecated adminhtml-classes for BC (like mysql4-classes).

To #2533 (comment)

I would definitely support this, but question:

if we are changing the block class names, are we updating these in all the layout xml files and in any PHP where we createBlock manually? Or do we continue to call adminhtml/blockname ?

All classes are still there and marked as deprecated. As soon i have finished it, there will be a module that holds all the deprecated classes.

No need for changes in 3rd-party-code!

Related Pull Requests

• see [preview] get rid of "Adminhtml" #2533

[kiatng]

How about moving the admihtml controllers to app\code\core\Mage\Api\controllers\Adminhtml?

[sreichel]

Controllers, models later ... ?

controllers are not autoloaded, could be a problem when overriden in 3rd-party-code?

[kiatng]

I think dismantling Mage_Adminhtml is breaking BC no matter what. For example, it will break override in app/code/local/Mage/Adminhtml.

[sreichel]

#2533 (comment)

It should not break anything. The classes in "Mage/Adminhtml" are still there to override. Do i miss something?

[colinmollenhour]

I agree that it should have been organized this way all along, but man that is going to be a ton of work with lots of risk of regressions and no difference to the end user.. IF you're going to do it is there some automated way to do it? Also I'd suggest adding code to detect missed updates. E.g. in createBlock you can check for the old block aliases like adminhtml/api*.

[sreichel]

Its "only" 15 modules, that have blocks in adminhtml.

Check for aliases is planned.