[#14176] - [4.0] Non-HTML view formats as first class citizens
- Closed
- 3 Apr 2018
- Medium
- Build: master
- # 14176
Joomla out of the box already has pretty decent support at the Framework level for non-HTML views and this is used somewhat decently in core. But there are places we can do better. This will require improving the standards for merging code and the documentation on writing extensions, especially plugins.
For 4.0:
- All views should dispatch appropriate plugin events (try using fields with com_content feeds, you can't without a massively hacky solution)
- All core features should architecturally work regardless of view format (we're mostly there now, the data model isn't too bad overall)
- Feature consideration/testing should expand as practical for non-HTML cases (especially important if a webservice architecture lands in core)
Why 4.0? Plugins rightfully assume they only run in an HTML context; aside from system events that's basically the truth. So it would be a B/C break for them to be required to check format/context more carefully.
joomla-cms-bot
- | Labels |
Added:
?
|
||
franz-wohlkoenig
- | Category | ⇒ | Feature Request |
| Status | New | ⇒ | Ready to Commit |
| Status | Ready to Commit | ⇒ | Needs Review |
What would be the required steps to achieve that? I think it is really needed that we stop thinking the world is just HTML.
Non-HTML views need to trigger all of the normal plugin events and plugins need to be updated to account for being triggered from a non-HTML view (like the email cloaking plugin, that shouldn't cloak the email address for non-HTML but it supports a {emailcloak=off} shortcode that would need to be stripped regardless of output format). That's basically the gist of it, but it's something that will require some adequate testing for each change (triggering the events is easy but working through the plugins will probably take a bit more time).
brianteeman
-
I don't see interest here. Everyone's too focused on the HTML producing aspect of Joomla with minimal interest in non-HTML use cases except for the webservices GSoC project. There's a part of me that feels like we're better off dropping non-HTML view support to be honest, but alas, second class non-HTML support is better than nothing.
| Status | Needs Review | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2018-04-03 12:05:09 |
| Closed_By | ⇒ | mbabker | |
| Labels |
Added:
J4 Issue
|
||
+1. Making the core view format (output channel) agnostic would be a big step into the right direction.