search

joomla / Manual

Joomla Developer Documentation
28 stars 57 forks source link

Removing AbstractView::get() #318

Closed Hackwar closed 1 month ago

Hackwar commented 1 month ago

User description

This is the documentation entry for the deprecation in https://github.com/joomla/joomla-cms/pull/44162

PR Type

documentation

Description

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

    codiumai-pr-agent-pro[bot] commented 1 month ago

    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.
    codiumai-pr-agent-pro[bot] commented 1 month ago

    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:

    CategorySuggestion                                                                                                                                    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]](https://github.com/joomla/Manual/pull/318/files#diff-b84ba55110a899374dbd798195ee1df5edcc1e93ad38974213c1b74019e99999R44-R47) ```diff /** @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]](https://github.com/joomla/Manual/pull/318/files#diff-b84ba55110a899374dbd798195ee1df5edcc1e93ad38974213c1b74019e99999R40-R41) ```diff -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]](https://github.com/joomla/Manual/pull/318/files#diff-b84ba55110a899374dbd798195ee1df5edcc1e93ad38974213c1b74019e99999R40-R41) ```diff -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 commented 1 month ago

    Thanks!