User tests: Successful: Unsuccessful:
This implements JGrid in the com_content articles view. While this could be merged, a few improvements should still be made. This is mainly to demonstrate how JGrid could be used and how the performance changes regarding this.
Labels |
Added:
?
|
That is not entirely correct. You can modify the $this->table object completely the way you want, add classes, new columns, etc. With some minor modifications to JViewLegacy in the future, you could even simply add new columns to the table via a plugin. This allows a lot more modifications than the previous solution. Existing overrides will work as well as new overrides.
Here is the code that I provided a few years ago to adapt the Hathor override for com_categories categories view:
<?php
$this->table->setActiveRow(0)
->setRowCell('checkbox', '', array('class' => 'checkmark-col'), false)
->setRowCell('title', '', array('class' => 'title'), false)
->setRowCell('status', '', array('class' => 'nowrap state-col'), false)
->setRowCell('ordering', '', array('class' => 'nowrap ordering-col'), false)
->setRowCell('access', '', array('class' => 'access-col'), false)
->setRowCell('language', '', array('class' => 'language-col'), false)
->setRowCell('id', '', array('class' => 'nowrap id-col'), false)
;
echo $this->table;
?>
I don't like that we specify HTML output in our view class. In the CMS we actually go the opposite route and move all HTML creation to either JLayouts or the template files, which I think makes more sense.
I agree with Brian that this makes template overrides much harder. The user would need to know not only PHP commands, he would also have to understand OOP and especially the API of the JGrid class. Which is far above the level of a Joe Average.
it is a proposal how to use this class. There are different ways that we could go with this. However, the idea at the time that I wrote this was, that I could add my own columns to the list views in the backend. To give you the exact situation: I wrote an index based search for a customer (that was during 1.5-times) and they wanted to enable and disable adding an article to the search index per article and also see if it was added in the list view. So I had to hack com_content articles view to make this work. With JGrid, rendering the table is delayed and together with a plugin event in JView, I could access that object in a plugin before it renders the table and add my own column with the respective data.
Another good example would be the "Composable models" by @chrisdavenport. If we would apply this to views, too, we could have a decorator for ordering, one for the access column, etc. and they can add their stuff to JGrid. That would mean, that we could have one generalized list layout for the backend of Joomla in the end. Yes, it makes overrides more complex, especially in the backend, but it would also allow us to implement a complete community support in com_users for example via a plugin.
Oh, and as I hinted at the top, this is not meant to be merged right away. Its a proof of concept to show you what is possible.
So if it is nothing what should be merged I suggest to write a wiki article as a tip how this class can be used.
Closing this one
Status | Pending | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2015-01-07 12:35:12 |
Nice to see quick action. Now if all PRs in our tracker could get such a swift treatment, the backlog would be gone in minutes. In under 4 hours I get responses by 2 PLT members. Considering that my other 20 PRs are waiting for sometimes a year now...
"merged right away" != "not merged at all"
I think it's slightly unfair to close this. Hannes has got feedback to incorporate. Personally I think if we moved the JGrid generating class into the tmpl/default.php file it would be viable.
Personally I think if we moved the JGrid generating class into the tmpl/default.php file it would be viable.
Yeah, that would be better. However I would still not like that we put HTML code into an object only to output it later on again. Sounds a bit silly to me.
It makes overrides still lot more complicate and the code is actually harder to understand.
The only thing I like is the idea of being able to dynamically add or delete columns from a table. I can see the usecase in that.
This PR removes the ability to customise the view with an override.
While an existing override will still work after applying the patch (I think) it prevents the creation of any new override. Well not actually prevent it but there is nothing left to override
This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/5632.