next »

[Huy H.]

We have a very large table with many fields to show that we are looking at redesign.  The trouble with this table is that it scrolls horizontally because it has so many fields.  We've been doing a few things to make it more manageable by customizing the table style.  Eg. frozenTable with leftFrozenColumns.  We also dynamically hide/show fields based on a few standard configuration.

While all this is good, we would like to take it a step further.  While what we're doing works, it does not give the administrator/end user full control to create profiles that work for their specific need.  The ability to hide/show, drag fields around, changing sort order, choosing frozen fields is all control by the frontend client and stored in the registry or local storage.  It does not allow the backend query or control any of these aspects.  For example: I want to allow application administrators to decide in what order the fields should be displayed so that it applies to every user -- I don't think this is possible with static dialog.

Has anyone venture into this sort of domain?  Is this an example where we should be looking at Dynamic dialogs instead?       

[Reuben B.]

Huy,

Many years ago I was involved with an application that was (and is still) used as a POS Terminal in various stores.  Different staff members would use the same PC/terminal throughout the course of the day and what we wanted was for the stored settings to be reset back to a known standard every time a different staff member signed into the application.

The stored settings for the GDC are stored in the registry (older versions of the GDC documentation used to list the registry storage key) and we had the POS application such that an administrator could save away the stored settings to a file via the regedit export commands.  When a staff member signed into the application, we would run regedit to import this file into stored settings.  That worked fine until Microsoft invented UAC and regedit no longer ran silently in the background and instead popped up a dialog for the user to acknowledge. 

I don't recall what happened after that, but with GBC it uses a different method to save stored settings using the local storage of the browser.  If you look inside GBC customisation for a file that has StoredSettings in the name, you will find the methods used to read and write stored settings from/to the local storage database.  To do what you want to do, you could investigate writing a custom front-call that would call these same methods.

What I also recall from that around time was having a discussion with one of our BA and saying you can either allow the 4gl program to control the column order/visibility etc, or you can allow the user to control it.  Where it gets messy is resolving conflicts where the 4gl program is saying do one thing whilst the stored settings is say do another, who has priority?  So then I think a strategy is to set forceDefaultSettings="no" presentation style for the customisable table, and have the 4gl be responsible for showing/hidden column, setting the column width, order etc .  It does imply building up the form dynamically, that does not necessarily mean Dynamic Dialogs but it will be more friendly on the network to use Dynamic Dialogs as you won't be sending unused columns across the network.

Reuben

[Reuben B.]

Huy,

I should add to what I wrote yesterday, where I suggested writing a custom GBC front-call to read/write stored settings, I should add the normal disclaimer of when you get into that depth of customisation you are doing so at your own risk.  It can go one of  three ways ...

• either we like the customisation you make, we decide to incorporate it into the product, then the on-going maintenance becomes our problem and not yours.  This is actually how the "AutoFill all columns", and "Fit to view all columns" options when you right-click in a Table evolved
• we make no changes and your customisation continues to work
• we make changes underneath in a maintenance, or major release, and suddenly your custom front-call that hooks into some GBC javascript doesn't work

... so with this last possibility, the onus is on you for every maintenance/major release you use to test that your customisation still works and if not adapt.  Is a change likely?, lets just say this line "this._storedSettingsKey = "gwc.forms." + formName + ".tables." + tabName;" will have to change one day to cater for the fact you can have the same form name using same table name in different directories and so isn't a unique key as it could be for table stored settings.

So I'd discourage you from having too much of this advanced GBC customisation in production, keep your customisation to the hooks we allow via theme.scss.json etc, but by all means if you think something is possible write the customisation, show it to your support contact, and you never know it might end up in the product like AutoFit all columns, Fit to view all columns.

The same disclaimer applies to Dom Tree manipulation if you are creating forms dynamically as part of a Dynamic Dialog approach, although the form AUI tree is pretty stable and should not change over a maintenance release.

Reuben

[Huy H.]

Thanks for the information Reuben. We are certainly not looking at customizing GBC at this point (probably our last resort if we get there).  But it's good that you mentioned about the AUI tree, I haven't thought of that.  We prefer to stick with static DIALOG if we can because the codeset for this module is huge.  I'll play with the AUI tree to see if we will have any success.