Topic
  • 4 replies
  • Latest Post - ‏2014-05-01T15:34:53Z by David.Durand
David.Durand
David.Durand
16 Posts

Pinned topic Passing Nulls Between RUIs Services & Programs

‏2014-04-29T13:30:57Z |

OK, Since I can't pass nullable fields as an argument to a program with the "?" extension and I can't pass a nullable field with null values to the RUI without it.  What is the best way to handle nulls?  Should I have two records one for the RUI and one for the Program defined and move the data back and forth in the service or is there something else I'm missing?

- Dave

  • markevans
    markevans
    3034 Posts
    ACCEPTED ANSWER

    Re: Passing Nulls Between RUIs Services & Programs

    ‏2014-04-29T15:57:23Z  

    David,

    I will let others weigh in as well, but yes, I believe the answer is to use two records... One to pass to the programs and one to use in the RUIs.   I also tend to think it is better to not use SQLRecords as the "interface" record to the RUI in order to provide some level of separation between the data layer and the presentation/UI layer of an application.

    Mark

  • markevans
    markevans
    3034 Posts

    Re: Passing Nulls Between RUIs Services & Programs

    ‏2014-04-29T15:57:23Z  

    David,

    I will let others weigh in as well, but yes, I believe the answer is to use two records... One to pass to the programs and one to use in the RUIs.   I also tend to think it is better to not use SQLRecords as the "interface" record to the RUI in order to provide some level of separation between the data layer and the presentation/UI layer of an application.

    Mark

  • David.Durand
    David.Durand
    16 Posts

    Re: Passing Nulls Between RUIs Services & Programs

    ‏2014-04-29T16:27:38Z  
    • markevans
    • ‏2014-04-29T15:57:23Z

    David,

    I will let others weigh in as well, but yes, I believe the answer is to use two records... One to pass to the programs and one to use in the RUIs.   I also tend to think it is better to not use SQLRecords as the "interface" record to the RUI in order to provide some level of separation between the data layer and the presentation/UI layer of an application.

    Mark

    Mark,

    I believe you are correct that I'll will need to use two records.  I don't think this is limited to SQLRecords though.  It appears even for basic records there is no way to define a Nullable field that is compatible with a RUI & Program. 

    As I am very new to the way this stuff works, I might be missing something more fundamental as when I should be using a program versus a service.  If I'm using the service as simply a gateway to get to the program this is an issue.  If I do the read & updates in the service I wouldn't have a problem.  I don't expect a tutorial here but if you could point me in the right direction to find guidelines explaining where I should be doing that type of work I'd love to get a better handle on it.

    Thanks,

    - Dave

     

  • dan_darnell
    dan_darnell
    973 Posts

    Re: Passing Nulls Between RUIs Services & Programs

    ‏2014-04-29T18:53:56Z  

    Mark,

    I believe you are correct that I'll will need to use two records.  I don't think this is limited to SQLRecords though.  It appears even for basic records there is no way to define a Nullable field that is compatible with a RUI & Program. 

    As I am very new to the way this stuff works, I might be missing something more fundamental as when I should be using a program versus a service.  If I'm using the service as simply a gateway to get to the program this is an issue.  If I do the read & updates in the service I wouldn't have a problem.  I don't expect a tutorial here but if you could point me in the right direction to find guidelines explaining where I should be doing that type of work I'd love to get a better handle on it.

    Thanks,

    - Dave

     

    Dave,

    I'm not sure exactly what kind of programs we're talking about. When calling external programs (via a callLink in the build descriptor) I often find that I have to do some data mapping. I think it is the nature of the beast since I am often using RUI-compatible data types in the UI that are not compatible with the data types expected on the program call and vice versa.

    Mark goes further to suggest not using SQLRecord record types in the interface between RUI and Service. I often do though -- using non-persistent fields in the record definition ("{persistent = no}" field annotation) where needed on fields to augment stuff that maps to the database. Mark is probably right and a more formal separation of the data layer from the presentation layer is probably a good idea but I just can't stomach the redundancy (more or less creating records that look just like each other except one is an SQLRecord type and the other isn't).

    You say, "If I do the read & updates in the service I wouldn't have a problem." If you mean coding SQL access in your service instead of calling a program to do the data access, I think you are correct. By way of separating application layers, I recommend coding data access in a library rather than directly in a service. This way, the data access code can be leveraged in a service and also elsewhere. In addition, you can then create service functions that call multiple library functions in order to aggregate data needed in a UI.

    There is a really nice tutorial in the RBD help. Search for "Access a database with EGL Rich UI" to find it. (Incidentally, Mark, the tutorial uses the SQLRecord record definitions both in the service tier and in the UI.)

    Hope this helps.

    Dan

     

     

     

     

  • David.Durand
    David.Durand
    16 Posts

    Re: Passing Nulls Between RUIs Services & Programs

    ‏2014-05-01T15:34:53Z  

    Dave,

    I'm not sure exactly what kind of programs we're talking about. When calling external programs (via a callLink in the build descriptor) I often find that I have to do some data mapping. I think it is the nature of the beast since I am often using RUI-compatible data types in the UI that are not compatible with the data types expected on the program call and vice versa.

    Mark goes further to suggest not using SQLRecord record types in the interface between RUI and Service. I often do though -- using non-persistent fields in the record definition ("{persistent = no}" field annotation) where needed on fields to augment stuff that maps to the database. Mark is probably right and a more formal separation of the data layer from the presentation layer is probably a good idea but I just can't stomach the redundancy (more or less creating records that look just like each other except one is an SQLRecord type and the other isn't).

    You say, "If I do the read & updates in the service I wouldn't have a problem." If you mean coding SQL access in your service instead of calling a program to do the data access, I think you are correct. By way of separating application layers, I recommend coding data access in a library rather than directly in a service. This way, the data access code can be leveraged in a service and also elsewhere. In addition, you can then create service functions that call multiple library functions in order to aggregate data needed in a UI.

    There is a really nice tutorial in the RBD help. Search for "Access a database with EGL Rich UI" to find it. (Incidentally, Mark, the tutorial uses the SQLRecord record definitions both in the service tier and in the UI.)

    Hope this helps.

    Dan

     

     

     

     

    Dan, these are internal programs.  My stomach does the same turning with duplicate record definitions. After reading the response from the PMR and seeing that it actually seems to work despite flagging a syntax error makes me think this should be a warning for external programs and be ok for internal programs.  

    I've done a few tests with moving the data to make sure that nothing is squirrely and it seems to be preserving the nulls both ways. A little more testing to make sure it handling all the data types the way I expect.

    It still feels like I'm just learning to crawl with this so thanks to both for your help.

    - Dave