I’ve been battling for a while with the web implementation of Grids in the web client. A couple of the features I would like to see included in a standard client include:

Standard methods that can be overridden to allow full control of what happens when a user clicks an individual row

Full control of cell content - i.e. let us embed HTML objects such as links & images etc…

A few years back we developed standard routines for expanding and shrinking the size of a grid which also managed the layout alterations that were then necessary. Although the users liked this additional control it was only really useful when designing forms that are constrained by size and contained many fields - it didn’t really make the actual operation of filling in the form any easier.

During the end of 2007 we have been developing for a client where extra control of the grid would have made the user experience far simpler so it was time to delve deeper into what goes on inside.  A few hours of investigation and we’ve produced some client-side JScript extensions that covers our needs.  I’m sure they won’t be suitable for all situations due to the additional complexity but when you really need to do something special hopefully these routines may be able to help.

Read the rest of this entry »

At times when developing UI functionality you will want to allow the user the ability to run a server side operation only if certain client side conditions are met.  This can range from tasks such as checking the information entered on a form is sensible and realistic such as checking for a valid postcode or more sophisticated checks such as ensuring all data entered in a grid is valid before carrying out a dependent e-mail operation.

Normally this type of validation is carried out when a form is submitted and we can easily trap these conditions. Return false from a validation script and it will stop the submission and therefore the server side code, however if you try to do something similar from a command button it’s not so simple.

The routine method is to simply not allow the user the option of pressing the command button prior to all conditions being met - these conditions being calculated by a hidden check box (or series) and having the button’s visibility set dependent on these.  i.e. When the conditions are okay the button is visible and  when the conditions are not okay the button is not visible.  Personally, I don’t really like this as it doesn’t give any opportunity for feeding back to the user to show why things may be wrong. From a design perspective it also creates a more cluttered view in the MBPM designer which can then lead to maintenance issues as a system grows.  Also, one last minor and avoidable niggle, it can leave a “hole” in the form’s design.

I think it would be more beneficial to allow the the client-side script to perform processing and validation before deciding if it should hand control on to the server for server-side processing. Luckily this is quite simple to achieve.

To do this follow these 2 steps:

1. When the form loads associate a new event handler with the command button
2. Create the new event handler

When the form loads ensure it calls the initialisation function:

   1: OnLoad=Init ()&Language=JScript

Create the initialisation function:

   1: function Init()

   2: {

   3:     //hook the command button to it's own event handler to allow

   4:     //validation before the server side operation is triggered

   5:     eworkData.FieldByName("btnCmd1").OnClick = btnCmd1Validate;

   6: }

Now create the event handler:

   1: function btnCmd1Validate()

   2: {

   3:     try

   4:     {

   5:         var RESULT = doComplexValidation();

   6: 

   7:         if (RESULT==true)

   8:         {

   9:             ButtonClick(document.getElementById("btnCmd1"));

  10:             alert("Server-side functionality processed");

  11:         }

  12:         else

  13:         {

  14:             alert("Server-side functionality NOT processed");

  15:         }

  16:     }

  17:     catch (ex)

  18:     {

  19:         alert (ex.message);

  20:     }

  21: }

Now when the the command button (btnCmd1) is clicked the new event handler is used.  This allows the function doComplexValidation() to be called which determines if we carry out further processing. If control should be passed back to the server then we call the Metastorm function ButtonClick() passing the command button element itself as the argument to invoke the server-side.

This gives the opportunity for full validation, additional opportunities for user feedback and the potential for taking pre-emptive corrective action should you need to.