-
Notifications
You must be signed in to change notification settings - Fork 9.4k
Add Value to Magento Framework's public API #17296
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
Merged
magento-engcom-team
merged 3 commits into
magento:2.3-develop
from
navarr:add-value-to-public-api
Oct 25, 2018
Merged
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
I don't think it's a good idea to make fat ugly model a part of API. Why isn't interface sufficient?
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.
When writing a backend model for a config, Magento expects that the model implements methods that do not exist in the Interface (such as "addData"). Though, this can be solved by any implementation of ValueInterface extending from AbstractModel (as Value does).
However, this model contains all the default functionality expected from a configuration backend model - including setting the correct events to fire and invalidating the cache. I have hard trouble finding a backend model that does not extend from Value.
Tutorials and examples online also show that the typical config backend model utilizes this model. I would think for those reasons it should be part of the public @api so that custom module's backend models may depend on it not removing functionality without a major version break.
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.
If you do not use the Value model, you must also specify the resource and resourcecollection for configuration yourself. Magento does it for Value as such:
It appears that in all cases the expectation is that you extend from this model
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.
@navarr do we have any other model extending
AbstractModel
marked as@api
?Uh oh!
There was an error while loading. Please reload this page.
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.
@orlangur Yes. For example
\Magento\Customer\Model\Customer
andMagento\Eav\Model\Entity\Type
. Nothing inMagento\Framework
, however.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.
Currently we have the interface for this model marked with
@api
. There's no sense to mark the model itself as@api
as well since we won't be needed the interface. That's why it is important to extend the interface while we can deliver that to 2.3.0Uh oh!
There was an error while loading. Please reload this page.
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.
@navarr If you you're still interested in delivering this and your other PR #17300 to 2.3.0 please answer me
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.
@slavvka I've had little personal time to work on open source - so forgive me for the delay - though I had last spoken about this over two months ago.
I laid out a variety of good reasons that this model should be part of the API on August 1st, and that simply updating the interface is not good enough. My fallback position on this is that "developers currently rely on this model to perform the basic tasks associated with a backend value"
And similarly Magento expects that it is receiving a Value model for a vast majority of the information it conveys to such objects:
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.
Since current interface is not enough and we are in code-freeze stage now, I propose the following:
In 2.3.0
@api
@api
In 2.4.0
@api
in 2.5.0
@api
from the model and leave only one interface marked as@api
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.
So, the decision is made. We are following to what @paliarush described. Please remove
@api
mark from the interface and add there a description what is going to be done with it. Also please add a description to the model that what it will be marked as@api
temporarily until we introduce a new interface and make everybody use use it.