feat: allow overriding namespaced views via app/Views directory

[datamweb]

Description
This PR adds the ability to override namespaced views (typically from modules or packages) by placing a matching file structure within the application's local app/Views directory.

See : https://forum.codeigniter.com/showthread.php?tid=93684&pid=427797#pid427797

Checklist:

• Securely signed commits
• Component(s) with PHPDoc blocks, only if necessary or adds value (without duplication)
• Unit testing, with >80% coverage
• User guide updated
• Conforms to style guide

[neznaika0]

It looks good for modules. Questions:

1. What happens if NS is specified as \Example\Blog\Views\blog_view? Contains Views.
2. Is there a possible collision when NS exists, when the View expects a template from the module modules/Example/, and outputs it from the app/Views ?

[datamweb]

• What happens if NS is specified as \Example\Blog\Views\blog_view? Contains Views.

CodeIgniter will look for: app/Views/Example/Blog/Views/blog_view.php. If the user explicitly includes Views in the call string, they should act accordingly in their override directory structure.

2. Is there a possible collision when NS exists, when the View expects a template from the module modules/Example/, and outputs it from the app/Views ?

Yes, if a file exists in the matching path within app/Views, it will take precedence over the module's file.
This collision is actually the intended behavior (the Override). Since the app/Views directory is user-controlled space, we assume that if a developer creates a directory structure matching a namespace (e.g., app/Views/Example/Blog/), they explicitly intend to override that modules/packages view. It is highly unlikely for such a specific directory structure to exist accidentally.
In any case, this is entirely under the developer’s control and can be managed.

[michalsn]

I'm not sure whether we should add a configuration option for this, allowing users to disable the functionality. The chances of this breaking existing code are small, though.

As for the difference between view('Example\Blog\blog_view') and view('Example\Blog\Views\blog_view'), this is a module developer's decision. We should not attempt to manipulate or normalize it, as that could lead to issues when developers choose more complex or non-standard folder structures.

[datamweb]

I'm not sure whether we should add a configuration option for this, allowing users to disable the functionality. The chances of this breaking existing code are small, though.

We could technically add a flag to app\Config\View.php to toggle this behavior. However, I personally believe it is unnecessary. Since this logic only triggers when a user deliberately creates a matching directory structure in app/Views corresponding to a specific namespace, the probability of an accidental collision is extremely low.

As for the difference between view('Example\Blog\blog_view') and view('Example\Blog\Views\blog_view'), this is a module developer's decision. We should not attempt to manipulate or normalize it, as that could lead to issues when developers choose more complex or non-standard folder structures.

Exactly. The current implementation intentionally avoids any magic stripping of segments like Views. It performs a direct 1-to-1 mapping of the namespace string to the directory path. This ensures predictable behavior regardless of how the module developer structured their views.

[neznaika0]

I've been trying modularity for a long time and working with templates is causing problems. I would not like to develop templates for Bootstrap when the global project theme is written in TailwindCSS. This feature seems to solve this problem - I don't need to create templates for the module.

[neznaika0]

I think it's okay.

[michalsn]

Thank you.

[michalsn]

Thank you @datamweb