Es sagt dem Kernel, dass der Entwickler der Klasse, die das IF implementiert der Meinung ist, dass die Klasse sich einfrieren lassen kann( bzw. ihr innerer Zustand sich mit der ID-Transformation serialisieren und deserialisieren lässt wobei ich glaube, dass damit keine privaten Attribute gemeint sind ).ralf.wenzel hat geschrieben:Nein, leider nicht - weil ich nicht verstehe, was das IF dabei tut.
Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
ralf.wenzel
Code: Alles auswählen.
<asx:abap version="1.0" xmlns:asx="http://www.sap.com/abapxml">
<asx:values>
<MODEL href="#o10"/>
</asx:values>
<asx:heap xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:abap="http://www.sap.com/abapxml/types/built‑in" xmlns:cls="http://www.sap.com/abapxml/classes/global" xmlns:dic="http://www.sap.com/abapxml/types/dictionary">
<prg:DEMO id="o10" xmlns:prg="http://www.sap.com/abapxml/classes/program/ZZENNO189"/>
</asx:heap>
</asx:abap>
Code: Alles auswählen.
<asx:abap version="1.0" xmlns:asx="http://www.sap.com/abapxml">
<asx:values>
<MODEL href="#o10"/>
</asx:values>
<asx:heap xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:abap="http://www.sap.com/abapxml/types/built‑in" xmlns:cls="http://www.sap.com/abapxml/classes/global" xmlns:dic="http://www.sap.com/abapxml/types/dictionary">
<prg:DEMO id="o10" xmlns:prg="http://www.sap.com/abapxml/classes/program/ZZENNO189">
<local.DEMO>
<TEST1>Hallo</TEST1>
<TEST2>Huhu</TEST2>
</local.DEMO>
</prg:DEMO>
</asx:heap>
</asx:abap>
Code: Alles auswählen.
CLASS demo DEFINITION.
PUBLIC SECTION.
INTERFACES if_serializable_object.
DATA test1 TYPE text10.
DATA test2 TYPE text10.
METHODS constructor.
ENDCLASS.
CLASS demo IMPLEMENTATION.
METHOD constructor.
test1 = 'Hallo'.
test2 = 'Huhu'.
ENDMETHOD.
ENDCLASS.
START-OF-SELECTION.
DATA(o_demo) = NEW demo( ).
DATA ser TYPE string.
CALL TRANSFORMATION id
SOURCE model = o_demo
RESULT XML ser.
cl_demo_output=>display_xml( ser ).
Code: Alles auswählen.
DATA cl_class TYPE REF TO zcl_<Class>. "<<dieses Ding hat ein Interface if_serializable_object
DATA new_class TYPE REF TO zcl_<Class>.
DATA va_xml TYPE xstring.
CREATE OBJECT cl_class.
cl_class->set_<irgendwas>().
cl_class->get_<sonstwas>().
CALL TRANSFORMATION id_indent
SOURCE ref = cl_class
RESULT XML va_xml.
* va_xml irgendwo hin speichern z.B mit Export ...
* jetzt wieder holen Import from und eine neue Instanz füllen
CALL TRANSFORMATION id_indent
SOURCE XML va_xml
RESULT ref = new_class.
new_class->get_<sonstwas>(). "<<< hier müsste dann das gleiche wie cl_class->get_<sonstwas>(). kommen
Das war das Entscheidende. Habe ich auch erst letztens gelernt - von einem anderen Kollegen. .ewx hat geschrieben:es ist ein Marker-Interface, das definiert, dass diese Klasse serialisierbar ist.
Folgende Benutzer bedankten sich beim Autor msfox für den Beitrag:
a-dead-trousers
Sehe ich in diesem speziellen Fall aber nicht als Nachteil, da die Serialisierung an den Kernel übertragen wird und somit vom Nicht-Kernel-Entwickler nicht nur "schlecht" sondern gar nicht nachvollziehbar ist. Somit entspricht die ID-Transformation de facto einem ABAP-Befehl, welcher halt als Syntaxmerkmal das Interface erwartet.msfox hat geschrieben:Verschleierung
Die Programm-Logik wird aus dem regulären Quelltext in Frameworks verlagert, die auf der Analyse von Metadaten aufbauen. Das macht sie für Menschen schwer nachvollziehbar.