Suggested Improvements to Grid functionality

Scriptcase 8 Suggestions
#1

Hi

I have a number of problems with the save grid functionality, which I hope you will consider for future development. It looks like a great idea which is poorly executed, to the point that we have stopped using it. The following items would significantly improve its usability and credibility… (Already e-mailed to dev team as per their request)

  1. Any user can delete a (public) saved grid. Effectively, if you can see the saved grid, you can delete it. It means that your design for public grids is not really practical and I have had to disable it on all my grids. It has caused chaos among my users and a LOT of work trying to regenerate grids that were inadvertently deleted by non-technical users. This is compounded by the fact that the Apply and Delete options are very close together. I have used a by ?user save? using a [usr_login] rule, but it does mean that each user has to create their own saves and there are multiple copies of the same save in existence. Delete should only be available via an authorisation check!

  2. The design of the save screen wastes a lot of space and is UGLY.
    Current design: shows Apply and delete with a line (picture) between them and is very wasteful of space (And looks awful)
    Removing the delete option as well as the picture makes it MUCH neater. NB? It would be further improved by removing the ?Apply? link altogether and making the onclick event apply to the saved grid title text! (You could then use the space on the right for the delete option, for the users you allow to have access to it.)

To achieve the above is really very simple but it requires that you hack the <appname>_grid_save.php file, with something like the following:

//---------In script block around line 760----------------------------

$(document).ready(function() {
$(“a.scGridPageLink:contains(Delete)”).hide();
$(“img”).hide();
});
//--------------------------------------------------------------------

Obviously it means that every time you regenerate the code you have to go back in and reapply this. Effectively making it impractical if you have lots of grids and/or you regenerate code on a regular basis.

This then leaves the problem of creating a capability to delete grids (With some kind of restriction on who can delete).

3. Once you have created a ?global? save (or any other for that matter) you should be able to call it directly from the menu or via an event. This really needs a macro or function which you can call from the main grid php which effectively lets you call something like:
function nm_select_grid(str_path_save, str_display)

Again, I have hacked this myself, by the following:

  • In the menu application, set the itemid as a global variable
  • In the onscriptinit event of the grid?
[LIST=1]
  • test for the itemid and if relevant set a session variable with the nm_select_grid(?lklklj,lklkjkj?) code (derived from the google browser inspector window.)
  • Activate the saved grids with a jQuery .click on the Saves button (this starts the <appname>_saved_grid.php file [/LIST]
    • In the <appname>_saved_grid.php file[LIST=1]
    • Convert the session variable stored previously into a javascript variable (which defines which saved grid you want to run) with something like:
    [/LIST] //----------After session start - line 4---------------------- $outputgrid = $_SESSION['report']; // get php session variable ?> <script> var autogrid = <?php echo json_encode($outputgrid) ?>; //alert(autogrid) </script> <?php //--------------------------------- [LIST=1]
  • Click the relevant ?apply? button using the following jQuery: [/LIST] if (autogrid != '') { // autoclick the requested format $('a.scGridPageLink[onclick="' + autogrid + '"]').click(); // clear the variables so that normal functionality resumes autogrid=''; <?php $_SESSION['report'] =''; ?> }

    Again this hack is not a practical long term solution as it would need to be manually reapplied after each code regeneration.

    4. You should be able to also save the state of the ‘refined search’ parameters with the grid.
    This would allow you to create a very specific output for the user. At the moment, you have to pick the saved grid and then apply the refined search, which is unwieldy.

    5.as far as I can tell you cannot change the css of the saved grid window in the Themes editor. This really should be an option, though if I was desperate, I could jQuery it again.

    In general, these supplementary php files like <appname>_grid_save.php could usefully have an ?override file?. so that you can write code in a file that does not get deleted or overwritten when you generate code. This file could then be included in the main file as standard so that no matter what you regenerate, your javascript/jQuery code will still be included. (a bit like the onscriptinit event). This is common in things like Joomla and Wordpress templates.

    I hope you find this suggestion constructive. I strongly believe that a small amount of development work to add this capability to the code generator would make a massive difference to the grid functionality and avoid the need for multiple grids showing very similar content.

    Regards

    Ian Batey

    • Using the 'save grid'