Removing AbstractView::get()

[Hackwar]

User description

This is the documentation entry for the deprecation in joomla/joomla-cms#44162

---

PR Type

documentation

---

Description

• Added a new documentation entry for deprecations in Joomla version 5.3.
• Deprecated the AbstractView::get() method, planned for removal in Joomla 7.0.
• Provided alternative code examples to replace the deprecated method.
• Explained the advantages of the new approach for IDEs and static code analysis.

---

Changes walkthrough 📝

	Relevant files
Documentation	new-deprecations.md Document deprecation of AbstractView::get() in Joomla        migrations/.52-53/new-deprecations.md Added documentation for new deprecations in Joomla. Detailed the deprecation of AbstractView::get() method. Provided alternative code examples for retrieving model data. Explained the benefits of the new approach for IDEs and static analysis. +52/-0

---

💡 PR-Agent usage: Comment /help "your question" on any pull request to receive relevant information

[qodo-code-review]

PR-Agent was enabled for this repository. To continue using it, please link your git user with your CodiumAI identity here.

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

⏱️ Estimated effort to review: 2 🔵🔵⚪⚪⚪

🧪 No relevant tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Documentation Clarity The documentation could benefit from a clear timeline for the deprecation process, including when developers should start migrating their code. Code Example Improvement The new code example could be enhanced by demonstrating error handling and type hinting for better code quality and IDE support.

[qodo-code-review]

PR-Agent was enabled for this repository. To continue using it, please link your git user with your CodiumAI identity here.

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Score
Enhancement	Add explanation for handling multiple models in a view To improve clarity for developers, consider adding a brief explanation of how to handle cases where multiple models are used in a view. This could include an example of how to specify a particular model when calling getModel(). migrations/.52-53/new-deprecations.md [44-47] /** @var ArticlesModel $model */ $model = $this->getModel(); +// For views with multiple models, specify the model name: +// $anotherModel = $this->getModel('AnotherModel'); $this->items = $model->getItems(); $this->pagination = $model->getPagination(); Apply this suggestion Suggestion importance[1-10]: 8 Why: This suggestion enhances the documentation by providing guidance on handling multiple models in a view, which is a common scenario. Including an example improves clarity and usability for developers, making it a highly relevant and practical addition.	8
	Add a note about potential performance implications of the new approach Consider adding a note about the potential performance impact of this change. While the new approach improves code clarity and static analysis, it might introduce a slight performance overhead due to direct method calls instead of using the get() method. This information could be valuable for developers optimizing their applications. migrations/.52-53/new-deprecations.md [40-41] -The downside of this is an indirection which no IDE and static code analyser can understand and which hides errors. The better solution is to call the model directly, making it easy for an IDE to understand the code. The new code should look like this: +The downside of this is an indirection which no IDE and static code analyser can understand and which hides errors. The better solution is to call the model directly, making it easy for an IDE to understand the code. While this approach may introduce a slight performance overhead, the benefits in code clarity and maintainability generally outweigh this concern. The new code should look like this: Apply this suggestion Suggestion importance[1-10]: 7 Why: The suggestion to mention potential performance implications is valuable as it provides developers with a more comprehensive understanding of the trade-offs involved in the new approach. This information can be crucial for those optimizing their applications, making the suggestion relevant and beneficial.	7
Best practice	Add information about error handling with the new approach To make the documentation more comprehensive, consider adding a brief section on error handling. Explain how errors that were previously hidden by the get() method should now be handled when directly calling model methods. migrations/.52-53/new-deprecations.md [40-41] -The downside of this is an indirection which no IDE and static code analyser can understand and which hides errors. The better solution is to call the model directly, making it easy for an IDE to understand the code. The new code should look like this: +The downside of this is an indirection which no IDE and static code analyser can understand and which hides errors. The better solution is to call the model directly, making it easy for an IDE to understand the code. This approach also allows for better error handling, as you can now catch specific exceptions thrown by the model methods. The new code should look like this: Apply this suggestion Suggestion importance[1-10]: 8 Why: The suggestion to include information on error handling is important as it addresses a potential gap in the documentation. By explaining how to handle errors that were previously hidden, it helps developers write more robust and maintainable code, thus significantly enhancing the documentation's value.	8

💡 Need additional feedback ? start a PR chat

[laoneo]

Thanks!