FWD » Core Development » User Interface

Some widget attributes require the widget to be realized else an error will be thrown (in fact a set of three). The method canAccess in GenericWidget is being used as a "guard" method to check if the widget is realized (it can force automatic realization based on realizeOnAttributeAccess property which defaults to true).

Changes in widget realization when the wasRealized temporary flag was dropped lead to some regressions - #6038.

The use of the canAccess guard should be reviewed and fix cases where widget realization is not really needed - as for the WIDTH-CHARS property that only needs the widget to be realized if no value was specified for the property.

Marian Edu wrote:

The use of the canAccess guard should be reviewed and fix cases where widget realization is not really needed - as for the WIDTH-CHARS property that only needs the widget to be realized if no value was specified for the property.

What should be done in that case? In SelectionListWidget.getWidthChars just calls canAccess. Should it do a check for if the property doesn't have a value, then set realizeOnAttributeAccess to false before calling canAccess? Or maybe send false as a new parameter to canAccess?

Is this the kind of update you are envisioning? It is successful in my customer's app.

   /**
    * Gets the WIDTH-CHARS writable attribute.
    *
    * @return   The current value of the WIDTH-CHARS attribute.
    */
   @Override
   public decimal getWidthChars()
   {
      decimal retval;
      boolean saveRealize = this.realizeOnAttributeAccess;
      this.realizeOnAttributeAccess = !(getAttr("clientWidthChars", () -> config.clientWidthChars, true) == 
                                      BaseConfig.INV_COORD);          
      if (!canAccess("WIDHTH"))
      {
         retval = new decimal(0);
      }
      else
      {
         retval = super.getWidthChars();
      }
      this.realizeOnAttributeAccess = saveRealize;

      return retval;
   }

Roger Borrello wrote:

Is this the kind of update you are envisioning? It is successful in my customer's app.

[...]

This can solve the issue in SelectionListWidget but size and positioning is probably more generic and handled somewhere in BaseEntity although have to say I'm confused why GenericWidget only throws 'method not implemented' - strange way to (not) implement a contract :(

What I was trying to say is some logic should be probably shifted from the client implementation to the server side - there is a clear relation between width/height characters and pixels (session's pixels per row/column), inner lines/chars needs to know the 'inserts' for each specific widget - can be different depending on widget configuration but still something that can be decided on the server side and implemented accordingly on the client. As it is now it looks like the client side is actually in charge and the server is only notified what the actual values are once the client did the adjustSize logic.