[#22125] - [4.0] Detection of a global table with "_global_" in JFramework for its system-wide use
- Closed
- 11 Sep 2018
- Medium
- Build: staging
- # 22125
Is your feature request related to a problem? Please describe.
One of the biggest issue I have missed during development of a component is a possibility to use values from a global table. I am aware of plug-ins and hooks, however they are troublesome.
Describe the solution you'd like
I suggest to have following feature:
If the table name is <" prefix ">_global_tableOne, <" prefix ">_global_tableTwo, <" prefix ">_global_tableThree, etc., i.e. if it begins with <" prefix ">global, it becomes available for all components and its field data becomes global field data. These tables becomes system tables that cannot be removed by any component as it may have its use by other components.
In the series of <" prefix ">global, these tables would be available for its use by all components without any further coding in it. I suggest here only to have functions in framework that detects the generic table beginning with <" prefix ">global and offers to all components for its use.
Additional context
Of course, one needs to have a field configuration to locally customize it with the same database. Even then, those fields will be available, instead of having a com_fields components that may make it available.
The advantage is that one could use common data stored in fields instead of a component mapped data.
For e.g. there is <" prefix ">_global_country, <" prefix ">_global_states and <" prefix ">_global_cities, <" prefix ">_global_categories, <" prefix ">_global_subcategories, etc. it could be used by all components, like K2, FlexiContent, Classifieds, Catalogs, etc.
Here, one could use <" prefix ">_global_country at the time of registration by an user. That information remains consistent, when he uses to fill in a form in other areas, like classifieds, etc. Here one sees that we achieve a consistency of data and information used by several components. One could use such data for updating purposes between site and developers too.
joomla-cms-bot
- | Title |
|
||||||
| Labels |
Added:
?
|
||||||
franz-wohlkoenig
- | Title |
|
||||||
| Category | ⇒ | Feature Request |
| Status | New | ⇒ | Discussion |
Closed for the reason stated above.
| Status | Discussion | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2018-09-11 12:58:27 |
| Closed_By | ⇒ | brianteeman |
One of the past lead Developers from Germany was not at all willing to put forward the above suggestion because he found the Group of Developers during the times of 1.5-2.5 very conservative and terrible. About Group mapping, he had fights. Now it is implemented. He exited and terminated his activity because he thought there was very little room for such creativity to be introduced, where there is a lot of stupid barking by others without thoughts. When lead Developer from Germany explained me his idea about certain advantages of "the Framework sensitivity" based on table prefix and what it could achieve, I found it ridicolous that it was never implemented in the past.
I came forward to put this suggestion, and to be honest to write in the bin of Trash, which was very early predicted by him. Let me tell you how and why your guys are terribly conservative and narrow minded. This handling demonstrates how narrow minded and closed you people are.
To begin with, you mention the phrase "an arbitrary name in the API". Here, I had a big laugh.
A table name is in the system is never ever arbitrary. You do not deserve to be a lead developer for that kind of thinking. With this, you demonstrated your very ridiculous approach to handling such feature suggestions.
A term "global" between underscores in the table name simply becomes a signalling handle within the Joomla Framework to serves a specific sensitivity of system actions. Hence, THE CONTRARY IS TRUE. THIS SPECIFIC PREFIX IS NOT ARBITRARY.
"Nothing stops anyone from creating a "global" table, likewise nothing stops anyone from removing it."
Likewise nothing stops you to keep this request open and allow someone to implement, if you want to exercise your right to be narrow-minded and conservative.
Joomla core will not get converted into a garbage core, if this very special feature is embedded into the Framework.
Further ridiculous and vision-less expression is: "the data source cannot be relied upon"
If the Framework provides a fundamental system of prefix based sensitivity, then developers of components begin to follow, then that system may achieve some maturity and order after some time. For example:
If one uses a component having table global_regions, then their geo_IDs becomes standardized not only amongst one joomla installation but also becomes a standard between many sites and components.
For example, if there is a component from JoomlaArt with 100.000 geo_IDs mapped to regions, that becomes a standard to be used by all systems. Even Joomla default could offer such a default standard. Here, one could comment to say that this feature request appeared by lead Developer from Germany because that conservative Group in the past refused to make such thoughts in this directions.
Look at multisite approach. In 2011, there were nasty discussions and a working group was organised. Then things came to a standstill because of these kind of approaches.
Once you have given a re-thought, you could re-open this issue. Either way, I did not care based on the impression from the other person, and even now do not care a damn too.
The German developer read your post and called me foolosh to write this request here. He informed me that there are many other frameworks, where this kind of things are embedded in the Framework, at different levels and different approaches.
In OctoberCMS there is already a system plugin RainLabs for regions, he said, to extend the argument of using certain system tables. Those tables could be used by all components.
That fundamental qualitity and sensitivity of using tables for all components, modiules and plugins is lacking in Joomla Framework.
It shall lack further too, when these kind of handling of thoughts is poured in.
We should not have special handling of database tables based on an arbitrary name in the API.
Nothing stops anyone from creating a "global" table, likewise nothing stops anyone from removing it.
The odds of distributed extensions buying into the use of these "global" tables is IMO going to be slim to none. It's change for the sake of change in their code, and the data source cannot be relied upon. If you want to build "global" tables into your own sites and share data across extensions, you are more than welcome to do so.