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
Use CMSWebApplicationInterface in controllers #28508
Use CMSWebApplicationInterface in controllers #28508
Conversation
Removing beta blocker actually. Loosening the constraints can be done in any minor version |
Is it not a BC break when the signature of the constructor changes? |
No. As long as it's compatible with the old typehint (which it is - it's a higher level) it's totally b/c |
@mbabker thanks for the review. Do you have any opinion on the Logging part? |
ae52752
to
5018868
Compare
c35ef9b
to
d1eb72b
Compare
@PhilETaylor can you cast a more experienced pair of eyes over this? I’ve done some more refactoring and still not totally sure about the approach here. obviously need to change it to target 4.1 too but will sort that another day. Time for some 😴 |
This comment was marked as abuse.
This comment was marked as abuse.
d1eb72b
to
6d1889e
Compare
I do not see the point that the Controllers and the whole MVC behind it can then be used, as a Console application can never implement |
I'm not sure I really see your point here? My entire driver here is that we are going to have scenarios if console if a first class application where you might have controller tasks which are specifically for a console and shouldn't be exposed to a web application ever and obviously we need to take into account even on shared tasks there might not be an active menu item in those scenarios |
Ok, if you write controllers specifically for console app, then will work. What I did understand was, that all controllers (site/admin) will then work in console apps. |
So the controller has to be aware of the request format (because, for example, the input object is going to be different and likely will have different naming conventions) - your output format is also likely to be different (obviously you rarely want to redirect which is web application specific or display a html view inside the console). Obviously we need to minimise differences as much as practically possible - but there's always going to be some differences. The end goal should be where the state is injected into the Model so that the model eventually becomes largely unaware of application (it's a grand goal that's going to take a long time to reach). |
Totally agree
Something we should consider version 5. |
Can you fix the conflicts here and make it ready for review? Would like to bring this one forward. |
This pull requests has been automatically converted to the PSR-12 coding standard. |
I've changed the basebranch to 4.3-dev, since we wont be merging this into 4.2. |
Wouldn't it possible to introduce a more abstract class that accepts any application and leave |
My aim was to do it a bit differently - most controllers only have a display controller so I wanted to move display into it's own subcontroller of base controller in a future major version (use an empty class in the current version for b/c) Then that leaves the hold/release/check edit ids - they are common to all the child classes - so I was thinking of maybe putting them in a trait???? (less sure but they are all group'd together) Finally there's redirect and checkToken which are basically both proxy methods. I'm not that fussed about just the exceptions for them given they are so small? I mean with all the benefits of hindsight I should have made a BaseWebController or something. But it's still not that clear if it's a good idea for like 2-3 methods. I'm pretty sure I want display controller to be it's own thing. Less sure about how to rework the others tho - happy to take ideas. |
This pull request has been automatically rebased to 5.0-dev. No new features will be merged into Joomla! 4.3 series. Joomla! 4.4 series is a bridge release to make migration from Joomla! 4 to 5 as smooth as possible. |
Thanks, can you please write a manual migration documentation? |
Summary of Changes
Moves Joomla MVC Controllers over to use CMSWebApplicationInterface instead of CMSApplication. This may be of use in the future to console applications who wish to use the Controller system.
CMSWebApplicationInterface
\Joomla\CMS\Factory
to use the app property (especially FormController)Note this is a draft PR because I need to figure out how to resolve the calls togetLogger
in BaseController - as the FIG LoggerInterface is not contained in the CMSApplicationInterface as things stand.Testing Instructions
No changes expected in the web interface. Code review of changes.
Documentation Changes Required
None