Reverse of base.typeinfo.create()?

[Snorri B.]

Hi.

Using base.TypeInfo.create allows you to write a generic function that accepts "any kind" of record (or array). Example:

Code (genero) Select Expand


define myrec record
  a int,
  b int,
  c char
end record

call myfunc(base.typeinfo.create(myrec))
.
.

function  myfunc(p)
define p om.Domnode
-- Do something
end function


So far so good, you can call myfunc with any type of myrec.* without braking anything (myrec could be an array in another function). What I would like to be able to do is to serialize the Domnodes back to variables, something like:

Code (genero) Select Expand


define myrec record
  a int,
  b int,
  c char
end record

call myfunc(base.typeinfo.create(myrec)) RETURNING myrec.*
.
.

function  myfunc(p)
define p om.Domnode
-- Do something
RETURN p.SerializeToVariables()
end function


What do you think? IMO base.typeinfo.create() only does half of the job!


Best regards,
-Snorri

[Snorri B.]

Hi.

Just wandering if somebody from 4js is reading this?

Best regs & marry xmas,
-Snorri

[Sebastien F.]

Hello Snorry,

We read all topics and take all requests into account, but we need to discuss a bit internally before giving an answer.

Maybe we can do something in 2.20, with the new FglRecord class... not sure, need to talk with others.

Could you give us more details about your need?
Why do you want to serialize / unserialize records / arrays?

Happy new year 2009!
Seb

[Snorri B.]

Hi Seb and a happy new year.

The reasons for serializing can be a few. In our application, we store program variables for various reasons, for example Report setup (basically a screen record) or Setup for batch jobs.
Example:

define myrec record
a char, b char, c int
end record

input by name myrec.* without defaults attributes(unbuffered)
on action get_stored_settings call get_stored("thisapp", base.typeinfo.create(myrec)) returning myrec.*
on action store_settings call store_settings("thisapp", base.typeinfo.create(myrec))
end input

I hope you get the idea. The store_settings routine walks thru the domnode and inserts the USER, appname, variable and value into a table. Writing get_stored is trickier, but we do this by getting the name of variables from the domnode, (and counting how many variables need to be returned), reading the stored settings table into an array and then we need to

case number_of _columns
when 1 return a[1]
when 2 return a[1],a[2]
when 3 return a[1],a[2],a[3]
when 4 --- etc. etc
end case

This is however impossible to write if myrec is an array. So basically, allowing serialization of records/arrays would give you the ability to write (complex maybe) generic routines that could return the same structure they are called with.

Does this make sense?

Best regards,
-Snori

Hello Snorry,

We read all topics and take all requests into account, but we need to discuss a bit internally before giving an answer.

Maybe we can do something in 2.20, with the new FglRecord class... not sure, need to talk with others.

Could you give us more details about your need?
Why do you want to serialize / unserialize records / arrays?

Happy new year 2009!
Seb

[Sebastien F.]

Hello Snorri,

Yes I understand the need.
I had a similar suggestion to save/restore search criterion in CONSTRUCT instructions.

Be sure that describing your needs in detail will help to make things happen.

I have just filed a new bug/enhancement (#11726)

Thanks,
Seb

[Reuben B.]

Hi Seb,

I hopefully had a request in the system dating back to the time when I was a customer which was trying to achieve the same end result that Snorri was trying to achieve.  That is storing away current field values, and being able to get those values back and re-apply them.

I was trying to get to a point  (I'll use the expression field_value instead of stored_settings to avoid confusion with the GDC stored settings) of having 2 actions ...

Code (genero) Select Expand

ON ACTION save_field_values
   CALL save_field_values()

ON ACTION get_field_values()
   CALL get_field_values()
... in every INPUT and CONSTRUCT, (I am not sure what my intention was with INPUT ARRAY).  Note that the function calls do not need to reference the variables used in the dialog statement.  If a new field was added I didn't want these function calls to have to be altered. 

To save the current field values 'was' achievable with code similar to ...

Code (genero) Select Expand

LET l_root = ui.Interface.getRootNode()
LET l_xpath = "//Dialog[@active=\"1\"]"
LET l_dialog_list = l_root.selectByPath(l_xpath)
FOR i = 1 To l_dialog_list.getlength()
   LET l_dialog_node = l_dialog_list.item(i)
   LET l_xpath = "//FieldInfo"
   LET l_fieldinfo_list = l_dialog_node.selectByPath(l_xpath)
   FOR j = 1 TO l_fieldinfo_list.getLength()
      LET l_fieldinfo_node = l_fieldinfo_list.item(j)
      LET l_nodeIdRef = l_fieldinfo_node.getAttribute("nodeIdRef")
      LET l_field_node = get_node_by_id(l_nodeIdRef)
      LET l_name = l_field_node.getAttribute("name")
      LET l_value = l_field_node.getAttribute("value")
      CALL add_to_list(l_name, l_value)
   END FOR
END FOR
... note I say 'was', I haven't checked if this still works in 2.1x and multi-dialog in particular.

To read the values and apply them was then going to be something like ...

Code (genero) Select Expand

LET l_root = ui.Interface.getRootNode()
LET l_xpath = "//Dialog[@active=\"1\"]"
LET l_dialog_list = l_root.selectByPath(l_xpath)
FOR i = 1 To l_dialog_list.getlength()
   LET l_dialog_node = l_dialog_list.item(i)
   LET l_xpath = "//FieldInfo"
   LET l_fieldinfo_list = l_dialog_node.selectByPath(l_xpath)
   FOR j = 1 TO l_fieldinfo_list.getLength()
      LET l_fieldinfo_node = l_fieldinfo_list.item(j)
      LET l_nodeIdRef = l_fieldinfo_node.getAttribute("nodeIdRef")
      LET l_field_node = get_node_by_id(l_nodeIdRef)
      LET l_value = read_from_list(l_name)
      CALL l_field_node.setAttribute("name", l_value)
   END FOR
END FOR
CALL ui.Interface.XXX()

... but I found I needed a function (the XXX in the code above) to set the underlying 4GL variables equal to the value attribute I had overwritten in the DOM tree.

If I was looking at this again, I'd have to consider multi-dialog and figure out how to include arrays, both input and display (single and multi-row select) in what is stored away and set back.

Reuben

[Sebastien F.]

Reuben,

This is interesting code... However, I would not recommend to set field values this way, because the reference for field values are the program variables, especially when using the UNBUFFERED mode. So to me this would be a "use at your own risks" code.

I believe that this code was working for CONSTRUCT, since only form field buffers are used in this instruction.

Seb

[Reuben B.]

Seb,

Don't worry, this code never made it to production as it never worked.  We were missing the CALL ui.Interface.XXX() to update the 4GL variables with the value of the corresponding value attribute in the DOM tree.

Without such a routine we had to hand-code the save and get of field values e.g.

INPUT field1, field2, field3 ...

ON ACTION save_field_values
   # some header
   # save field1 value
   # save field2 value
   # save field3 value
   # some trailer

ON ACTION get_field_values
   # some header
   LET field1 = # get saved value for field1
   LET field2 = # get saved value for field2
   LET field3 = # get saved value for field3

... all of which meant that this functionality
a) was only applied to certain screens
b) any change to those screens in terms of fields being added/removed meant the save and get routines had to be edited.

The key thing from Snorris comment was "ability to write (complex maybe) generic routines".  An ISV developer doesn't want to have to hand-code the same thing over and over again.  Snorri was looking for an extension to base.TypeInfo, I was looking for an extension to ui.Interface, to effectively end up with the same generic result, that is to change the value of a variable without necessarily typing that variable into the code.  Maybe we could achieve what we want with LET variable() = value() ?

[Snorri B.]

Reuben, thank you very much for your input.
We started out using a similar method as you but encountered the same problems.
I think we made a point here and regardless of the implementation I think it would be of great benefit to the language to add this feature.
I looked at the fglrecord class 2.20 doc and it seems to have the same limitations (as base.typeinfo), you can pass it to a function, but not return it.

Best regards,
-Snorri

[David H.]

Hi Snorri,

I'm a bit late to this thread but was wondering if you'd looked at the XML Serializer class of the Web Services XML Extension Library. I have no experience of using these classes myself, but in principal I don't see why you could not use them in your BDL app. Or am I missing something here?

xml.Serializer.VariableToDom(var VARIABLE,node xml.DomNode )    

xml.Serializer.DomToVariable(node xml.DomNode,var VARIABLE )

https://4js.com/techdocs/genero/gws/devel/DocRoot/User/WseXmlSerializer.html#SerializerOptions

Regards,

David

[Snorri B.]

Hi David and thanks for your input.

Yes, we thought about using xml.Serializer, and it can be done but it has some unfortunate side effects. First of all, it is not possible to use "normal" record declarations you need to specify XML attributes for the serializer to work like for example attribute(XMLOptional) or XMLName etc. which puts extra burden on the person calling your routine. It also requires additional lines of code and complexity.

Example if base.typeinfo could be used:

define ktolur record
    ktala    varchar(10),
    veflyk  varchar(30),
    drasl dynamic array of record
        d1 char(1),
        d2 char(10)
    end record
  end record

call my_generic_func(base.typeinfo.create(ktolur)) returning ktolur.*
...

Example using the serializer (bold is additional code):

type t_ktolur record
    ktala       varchar(10),
    veflyk  varchar(30),
    drasl dynamic array of record attribute(XMLOptional)
        d1 char(1),
        d2 char(10)
    end record
  end record

define ktolur t_ktolur
define p1, p2 xml.DomNode
call xml.Serializer.VariableToDom(ktolur, p1)
call my_generic_func(p1) returning p2
call xml.Serializer.DomToVariable(p2, ktolur)
...
As you can see, this is much more complex than using base.typeinfo (if that would be possible).

Best regards,
-Snorri

[Reuben B.]

Thanks for the tip also David.  You gave me some false hope but I encountered the fact that the variable needs to be known.  I can't have the variable determined at run-time e.g.

Code (genero) Select Expand

CALL xml.Serializer.DomToVariable(dom, function_to_return_a_variable())

I didn't run into the issue with XML attributes  that Snorri did (I only ran it in 2.20).  This code appeared to run OK

Code (genero) Select Expand

IMPORT xml

# this would probably be in an include file with r,c named more uniquely
DEFINE r,c xml.DomNode
&define CALL_save_variable_to_dom(variable, dom) LET dom = xml.DomDocument.createDocument(#variable) \
                                            LET r = dom.getDocumentElement() \
                                            CALL xml.Serializer.variabletodom(variable, r)

&define CALL_restore_dom_to_variable(dom, variable) LET r = dom.getDocumentElement() \
                                               LET c = r.getLastChild() \
                                               CALL xml.Serializer.domtovariable(c, variable)
                                                                                     
DEFINE mydomdoc xml.DomDocument
DEFINE myrec RECORD
   a INTEGER,
   arr DYNAMIC ARRAY OF RECORD
      x, y INTEGER
   END RECORD
END RECORD

MAIN

   # Populate the record
   LET myrec.a = 1
   LET myrec.arr[1].x = 2
   LET myrec.arr[1].y = 3
   LET myrec.arr[2].x = 4
   LET myrec.arr[2].y = 5
   CALL display_myrec("Initial values")
   
   # Save it away
   CALL_save_variable_to_dom(myrec, mydomdoc)

   # Clear out the variable
   INITIALIZE myrec.* TO NULL
   CALL myrec.arr.clear()
   
   # verify that the record is cleared
   CALL display_myrec("Record has been cleared")
   
   # Get it back
   CALL_restore_dom_to_variable(mydomdoc, myrec)
   
   # verify that the record has been restored
   CALL display_myrec("Record has been restored")
END MAIN

FUNCTION display_myrec(title)
DEFINE title STRING

&define show(p1) DISPLAY #p1 || " = ", p1
   DISPLAY title
   show(myrec.a)
   show(myrec.arr.getlength())
   IF myrec.arr.getLength() > 0 THEN
      show(myrec.arr[2].y)
   END IF
   DISPLAY ""
END FUNCTION

[Neil M.]

I raised this a long time ago from a different angle.

The need was for a dynamic maintenance program, ie the program that became my DBQuery program.

The only thing the DBQuery program really lacks is the ability to UPDATE the records it browses.
The reason I can't do INPUT rec.* FROM rec.* is because for INPUT the field type/size information
is always taken from the runtime system, ( except for CONSTRUCT ) so basically the GDC would treat
all my fields as I'd defined them ( all CHAR(255) ).

Now if I could serialize xml into a record of the correct type of fields then I could do the INPUT and the
GDC would treat all the fields as the correct type and size.

Then basically we'd only ever have to write one maintenance program!

Now that we have the work done for web services for something close to this then hopefully some of the
technical issues involved have been solved. :)