Go Back
1 Vote

When generating .dbl files for repository structures using SDI include a field length property


For user experience it is often better to not let a user do something they can't instead of letting them know after the fact. One of these UX 'things' is field lengths. If a Synergy repository field is a D2 we should not let them enter 100 or if a string is A6 not let them enter 7 characters. In the browser we of course can control this with the maxlength attribute. Now we can set this attribute manually but that approach is brittle. 
What would be ideal, in my opinion, is if when the repository structures are converted to Synergy.Net, a readonly field could be generated with that field's maximum length. That field could then be used on the client side to either set maxlength or perform a validation.
So for instance a field named Escp_mths_adv_collect is a D2. That is generated as:

private f_Escp_mths_adv_collect    ,int
;;; <summary>
;;; EADV
;;; </summary>
public property Escp_mths_adv_collect   ,int
method get
proc
    mreturn f_Escp_mths_adv_collect
endmethod
method set
proc
if(f_Escp_mths_adv_collect != value)
begin
m_changed = true 
f_Escp_mths_adv_collect = value
end
endmethod
endproperty


If another field like
public readonly int length_Escp_mths_adv_collect = 2;
were added it could be used client-side to perform validations,

3 Comments | Posted by Erik Read to Synergy .NET, Visual Studio Integration, Repository on 1/6/2022 7:03 PM
Steve Ives
Erik,

I'm not sure what your specific "client side" is, but I'm assuming there is some sort of web service between the two, and based on my understanding of what you guys do, I'm assuming it's some sort of .NET based service. If that is the case then you should look at the System.ComponentModel.DataAnnotations namespace. It contains a bunch of attributes that can be applied to public properties in a data class to define validation rules. For example, for your case of a D2 variable being exposed as an int, and assuming negatives are not allowed, you could do something like this:
  
{Range(0,99,ErrorMessage="Value for Escp_mths_adv_collect must be between 0 and 99")}
public readwrite property Escp_mths_adv_collect, int

In .NET, the web service frameworks can validate this metadata through a mechanism called ModelState. Essentially if any property in passed data is not in compliance with the requirements, an HTTP 400 (bad request) is returned to the client, and the response body contains details of any failures. The client can then consume this information to know what was wrong.

This validation can either be done manually in each method that requires it, or you can add a global filter into the ASP.NET pipeline to automatically apply the behavior to all requests. This is really cool because it means that if the client passes bad data, your web service endpoint never even gets called, and the client gets a meaningful and useful response.

There are lots of these validation attributes, another one is useful when accepting a string that has to fit into a fixed size alpha:
  
{StringLength(20,ErrorMessage="Value for First_name must be 20 characters or less")}
public readwrite property First_name, string

And another REALLY useful one is:
  
{Required(ErrorMessage="Last_name is required")}
public readwrite property Last_name, string

Of course, you can also combine them: 
{Required(ErrorMessage="Last_name is required")}
{StringLength(20,ErrorMessage="Value for Last_name must be 20 characters or less")}
public readwrite property Last_name, string

Hope this helps.

Steve



 

1/7/2022 11:19 PM   0  
Erik Read
Steve, thanks for the answer but it requires 2 things I would like to avoid:
1. Knowledge of the structure. I want a property/field off of the generated structure that I can interrogate at runtime to determine the size of the field.
2. A roundtrip to the web server. If the field size were a part of the generated synergy class, when it was converted to JSON at runtime and sent to browser client, that data would also be included, so on the Angular client I could see, at runtime, that  Escp_mths_adv_collect had a length of 2 and set the html element's maxlen appropriately at runtime.

Of course, we would do the server-side validation as well but it would be a better user experience to have this basic validation in client-side code as well AND not have to manually set each field's maxlen at design time.

Yes...I want it all.

As a side note, the generated XML used to create the .dbl files in visual studio already contains this information:

<?xml version='1.0'?>
<!--Generated by dblnet2xml v12.0.1 on 06 JAN 2022 14:10:34-->
<component name="BrowserInteropTmp" rev="1">
...
  <structure name="Escrow_master_file_prov" size="800">
...
    <field name="Escp_mths_adv_collect" coerce="int" type="decimal" size="2">
      <comment>
        <line1>EADV</line1>
      </comment>
    </field>
 

1/8/2022 1:49 PM   0  
Erik Read
One other issue I just realized with the proposed workaround.
Those dbl files are generated at build time and not checked in in our interop project making modifying them pretty much out of the question.

1/16/2022 8:57 PM   0  
Please log in to comment on this idea.