From: tma Date: Wed, 5 Jul 2006 09:19:32 +0000 (+0000) Subject: remove images in ascii X-Git-Tag: LAST_STABLE_VERSION_21_09_2006_ON_3_2_0~23 X-Git-Url: http://git.salome-platform.org/gitweb/?a=commitdiff_plain;h=36ed6554a73cbbdcf1505c17948166d8083ebe52;p=modules%2Fkernel.git remove images in ascii --- diff --git a/doc/salome/tui/KERNEL/sources/Application-About1.jpg b/doc/salome/tui/KERNEL/sources/Application-About1.jpg deleted file mode 100755 index cf7ab8ba0..000000000 Binary files a/doc/salome/tui/KERNEL/sources/Application-About1.jpg and /dev/null differ diff --git a/doc/salome/tui/KERNEL/sources/application.gif b/doc/salome/tui/KERNEL/sources/application.gif deleted file mode 100644 index 0b05d5c18..000000000 Binary files a/doc/salome/tui/KERNEL/sources/application.gif and /dev/null differ diff --git a/doc/salome/tui/KERNEL/sources/application.jpg b/doc/salome/tui/KERNEL/sources/application.jpg deleted file mode 100755 index a6979ab99..000000000 Binary files a/doc/salome/tui/KERNEL/sources/application.jpg and /dev/null differ diff --git a/doc/salome/tui/KERNEL/sources/html_comments.gif b/doc/salome/tui/KERNEL/sources/html_comments.gif deleted file mode 100755 index f0c0f0b47..000000000 Binary files a/doc/salome/tui/KERNEL/sources/html_comments.gif and /dev/null differ diff --git a/doc/salome/tui/KERNEL/sources/static/Link.gif b/doc/salome/tui/KERNEL/sources/static/Link.gif deleted file mode 100755 index 75330d0c8..000000000 Binary files a/doc/salome/tui/KERNEL/sources/static/Link.gif and /dev/null differ diff --git a/doc/salome/tui/KERNEL/sources/static/SObject.gif b/doc/salome/tui/KERNEL/sources/static/SObject.gif deleted file mode 100755 index 1d4e9cb24..000000000 Binary files a/doc/salome/tui/KERNEL/sources/static/SObject.gif and /dev/null differ diff --git a/doc/salome/tui/KERNEL/sources/static/Study_Struct.gif b/doc/salome/tui/KERNEL/sources/static/Study_Struct.gif deleted file mode 100755 index bc0ce35be..000000000 Binary files a/doc/salome/tui/KERNEL/sources/static/Study_Struct.gif and /dev/null differ diff --git a/doc/salome/tui/KERNEL/sources/static/examples_Life_cycle.html b/doc/salome/tui/KERNEL/sources/static/examples_Life_cycle.html index 8d36282f6..080112eb4 100755 --- a/doc/salome/tui/KERNEL/sources/static/examples_Life_cycle.html +++ b/doc/salome/tui/KERNEL/sources/static/examples_Life_cycle.html @@ -1,116 +1,116 @@ - - - - - - - - Main Page - - - - - - - - - - - - - - -

- - -

Examples

- //There is a CXX example of LifeCycleCORBA using
-
-#include CORBA_CLIENT_HEADER(TestComponent)
-#include "SALOME_NamingService.hxx"
-#include "SALOME_LifeCycleCORBA.hxx"
-
-int main (int argc, char * argv[]){
- try {
-      // Initializing omniORB
-      CORBA::ORB_var orb = CORBA::ORB_init(argc, -argv);
-
-      // Obtain a reference -to the root POA
-      CORBA::Object_var obj = orb->resolve_initial_references("RootPOA") -;
-      PortableServer::POA_var poa = PortableServer::POA::_narrow(obj) -;
-
-      SALOME_NamingService _NS(orb) ;
-
-      SALOME_LifeCycleCORBA _LCC(&_NS) ;
-
-      Engines::Component_var myComponent = _LCC.FindOrLoad_Component("FactoryServerPy","TestComponentPy");
-       if(!CORBA::is_nil(myComponent)){
-          Engines::TestComponent_var -myConcreateComponent = TestComponent::_narrow(myComponent);
-        //do something -what you like with the interface
- ...
-        return 0;
-       }
-    }
- catch(CORBA::COMM_FAILURE& ex){
-      cout<<"Caught system exception COMM_FAILURE --- unable to contact the object.\n";
- }catch(CORBA::SystemException&){
-      cout<<"Caught a CORBA::SystemException.\n";
- }catch(CORBA::Exception&){
-      cout<<"Caught CORBA::Exception.\n";
- }catch(...){
-      cout<<"Caught unknown exception.\n";
- }
- return 1;
-}
-
-#The example may be rewritten on Python like this:
-
-from omniORB import CORBA
-from SALOME_TestComponent import *
-from SALOME_NamingServicePy import *
-from LifeCycleCORBA import *
-
-try:
-    orb = CORBA.ORB_init(sys.argv,CORBA.ORB_ID)
-    _NS = SALOME_NamingService(orb)
-    _LCC = SALOME_LifeCycleCORBA(orb)
-
-     myComponent = _LCC.FindOrLoadComponent("FactoryServerPy","TestComponentPy");
-    myConcreatComponent = myComponent._narrow(TestComponent)
-    if myConcreatComponent is not None :
-        //do something what you like with the -interface
- ...
-         return 0
-    }
-except CosNaming.NamingContext.NotFound, e :
-    print "Caught exception: Naming Service can't found Logger"
-except CORBA.COMM_FAILURE, e:
-    print "Caught CORBA::SystemException CommFailure"
-except CORBA.SystemException, e:
-    print "Caught CORBA::SystemException."
-except CORBA.Exception, e:
-    print "Caught CORBA::Exception."
-except Exception, e:
-    print "Caught unknown exception."
-
-
-
- - + + + + + + + + Main Page + + + + + + + + + + + + + + +

+ + +

Examples

+ //There is a CXX example of LifeCycleCORBA using
+
+#include CORBA_CLIENT_HEADER(TestComponent)
+#include "SALOME_NamingService.hxx"
+#include "SALOME_LifeCycleCORBA.hxx"
+
+int main (int argc, char * argv[]){
+ try {
+      // Initializing omniORB
+      CORBA::ORB_var orb = CORBA::ORB_init(argc, +argv);
+
+      // Obtain a reference +to the root POA
+      CORBA::Object_var obj = orb->resolve_initial_references("RootPOA") +;
+      PortableServer::POA_var poa = PortableServer::POA::_narrow(obj) +;
+
+      SALOME_NamingService _NS(orb) ;
+
+      SALOME_LifeCycleCORBA _LCC(&_NS) ;
+
+      Engines::Component_var myComponent = _LCC.FindOrLoad_Component("FactoryServerPy","TestComponentPy");
+       if(!CORBA::is_nil(myComponent)){
+          Engines::TestComponent_var +myConcreateComponent = TestComponent::_narrow(myComponent);
+        //do something +what you like with the interface
+ ...
+        return 0;
+       }
+    }
+ catch(CORBA::COMM_FAILURE& ex){
+      cout<<"Caught system exception COMM_FAILURE +-- unable to contact the object.\n";
+ }catch(CORBA::SystemException&){
+      cout<<"Caught a CORBA::SystemException.\n";
+ }catch(CORBA::Exception&){
+      cout<<"Caught CORBA::Exception.\n";
+ }catch(...){
+      cout<<"Caught unknown exception.\n";
+ }
+ return 1;
+}
+
+#The example may be rewritten on Python like this:
+
+from omniORB import CORBA
+from SALOME_TestComponent import *
+from SALOME_NamingServicePy import *
+from LifeCycleCORBA import *
+
+try:
+    orb = CORBA.ORB_init(sys.argv,CORBA.ORB_ID)
+    _NS = SALOME_NamingService(orb)
+    _LCC = SALOME_LifeCycleCORBA(orb)
+
+     myComponent = _LCC.FindOrLoadComponent("FactoryServerPy","TestComponentPy");
+    myConcreatComponent = myComponent._narrow(TestComponent)
+    if myConcreatComponent is not None :
+        //do something what you like with the +interface
+ ...
+         return 0
+    }
+except CosNaming.NamingContext.NotFound, e :
+    print "Caught exception: Naming Service can't found Logger"
+except CORBA.COMM_FAILURE, e:
+    print "Caught CORBA::SystemException CommFailure"
+except CORBA.SystemException, e:
+    print "Caught CORBA::SystemException."
+except CORBA.Exception, e:
+    print "Caught CORBA::Exception."
+except Exception, e:
+    print "Caught unknown exception."
+
+
+
+ + diff --git a/doc/salome/tui/KERNEL/sources/static/examples_Study.html b/doc/salome/tui/KERNEL/sources/static/examples_Study.html index 31ccaffa5..859f6297f 100755 --- a/doc/salome/tui/KERNEL/sources/static/examples_Study.html +++ b/doc/salome/tui/KERNEL/sources/static/examples_Study.html @@ -1,790 +1,790 @@ - - - - - - - - Main Page - - - - - - - - - - - - - - -

- - -

Examples

-
-
- -

    Interfaces:
-
- SALOMEDS::Study
-     SALOMEDS::StudyBuilder
-       SALOMEDS::StudyManager
-     SALOMEDS::SObject
-    SALOMEDS::SComponent
- SALOMEDS::SComponentIterator
- SALOMEDS::ChildIterator
- SALOMEDS::AttributeComment
-
-

-
-
-
- -

SALOMEDS::Study interface
-
- -

-
- -

SComponent FindComponent( -in string aComponentName )
-
- Find GEOMETRY component in the opened study by its name:
-
-     str= os.getenv("TmpDir")
-     if str == None:
-         str = "/tmp"
-     file = str+"/test.hdf"
-
-     openedStudy=batchmode_geompy.myStudyManager.Open(file)
-
-     father = openedStudy.FindComponent("GEOM")
-     if father is None:
-         raise RuntimeError, "Geom - component is not found! Wrong study is opened."
-
-
-

- -

SObject FindObject ( in string -anObjectName )
-
- Find the SObject of the box by its NameAttribute "box":
-

- -

box = openedStudy.FindObject("box")
- if box is None :
- raise RuntimeError, "box was not found! Wrong -study is opened."
-
-
- SObject FindObjectID - ( in ID aObjectID -)
- #result: "/User data/Case1".
- Find - the SObject of the box by its ID "0:1:1:2":
-
-

- -

box =openedStudy.FindObjectID("0:1:1:2")
-

- -

if box is None :
-     raise RuntimeError, "box was not found! Wrong -ID is used."
-
-
- SObject FindObjectIOR - ( in ID aObjectIOR -)
-
- Find the SObject of the result on imported MED file -by it's IOR:
-
- theResult = myVisu.ImportFile(medFile)
- aSObj = myStudy.FindObjectIOR(theResult.GetID())
-
-
- SObject - FindObjectByPath ( in string thePath )
-
- Find SObject by path to it:
-
- # create new auxiliary component
- aComponent = myStudyBuilder.NewComponent("Virtual Component")
-
- # create auxiliary subtree
- aPath = "/Virtual Component/Case1"
- myStudyBuilder.AddDirectory(aPath)
-
- aSObj = myStudy.FindObjectByPath(aPath)
-
-
- void SetContext ( in string thePath) / - string GetContext ()
-
- Set context of the study to the created case and get it for printing:
-
- aComponent = myStudyBuilder.NewComponent("User data")
- anAttr = aBuilder.FindOrCreateAttribute(aComponent, "AttributeName")
- anAttrName = anAttr._narrow(SALOMEDS.AttributeName)
- anAttrName.SetValue("User data")
-
- #Add a new case 'Case1' to the component 'User data'
- aBuilder.AddDirectory("/User data/Case1")
-
- #Set a study context to '/User data/Case1'
- aStudy.SetContext("/User data/Case1")
-
- #Print the current study context
- print aStudy.GetContext()
-
- #result: "/User data/Case1".
-
-
- ChildIterator - NewChildIterator ( in SObject aSO )
-
- Import med file and print all mesh names that this file includes -(mesh is a child of the result of imported file):
-
- # define file name
- aFileName = datadir + "fra.med"
-
- # import file in visu module and get result
- theVisu = batchmode_visu.myVisu
- aResult = theVisu.ImportFile(aFileName)
- if aResult is None : raise RuntimeError, "Error"
- else : print "OK"
-
- # get current study and its' SObject       -
- myLocalStudy = theVisu.GetCurrentStudy()
- aSObj = myLocalStudy.FindObjectIOR(aResult.GetID())
- if aSObj is None : raise RuntimeError, "Error"
- else : print "OK"
-
- # create iterator by SObject of the current study
- aMeshIter = myLocalStudy.NewChildIterator(aSObj);
-
- # iterating in the current study (with the help of created iterator) -to find all mesh names
- while aMeshIter.More() :
-         aMeshSObj = aMeshIter.Value()
-         aMeshIter.Next()
-         anAttr = aMeshSObj.FindAttribute("AttributeName")[1]
-         if anAttr is None :
-             aMeshSObj - = aMeshIter.Value()
-             aMeshIter.Next()
-             anAttr - = aMeshSObj.FindAttribute("AttributeName")[1]
-         anAttr = anAttr._narrow(SALOMEDS.AttributeName);
-         aMeshName = anAttr.Value()
-         print " ", aMeshName
-
-
- SComponentIterator -NewComponentIterator ()
-
- Find the number an names of all components in the study:
-
- aCompItr = myStudy.NewComponentIterator()
-
- compNb = 0
- while aCompItr.More():
-     aComp = aCompItr.Value()
-     aName = aComp.ComponentDataType()
-     print "Component name = ", aName
-     compNb += 1
-     aCompItr.Next()
-
-
- StudyBuilder -NewBuilder ()
-

-
- Create a new StudyBuilder (uses to add or modify an object in the -study ):
-
- myBuilder = myStudy.NewBuilder()
-
-
- AttributeStudyProperties -GetProperties ()
-
- Get the attribute, which contains the properties of the study, and -change properties of the study by changing it:
-
- aProperties = myStudy.GetProperties()
- if aProperties == None :
-     raise RuntimeError, "Can't create AttributeStudyProperties -attribute"
- aProperties = aProperties._narrow(SALOMEDS.AttributeStudyProperties)
-
- A = aProperties
-
- # print stydy properties
- print "A.GetUserName()= ", A.GetUserName()
- res,mm,hh,dd,mnth,yy=A.GetCreationDate()
- print "A.GetCreationDate() = ", mm,hh,dd,mnth,yy
- print "A.GetCreationMode() = ", A.GetCreationMode()
- print "A.IsModified() = ", A.IsModified()
- print "A.IsLocked() = ", A.IsLocked()
-
- # change the properties of the study
- if A.IsLocked() == 0 :
-     A.SetUserName("tester"); print 'A.SetUserName("tester"), -A.GetUserName() = ', A.GetUserName()
-     A.SetCreationDate(11,11,11,11,2002); print 'A.SetCreationDate(11,11,11,11,2002), -A.GetCreationDate() =', A.GetCreationDate()
-     print "A.IsModified() = ", A.IsModified()
- A.SetLocked(1)
-
-
- boolean IsModified ()
-
- Find if study is modified:
-
- IsModified = myStudy.IsModified()
-
- if IsModified == 1:
-     print "The study is modified and not saved"
-
-
- boolean IsEmpty ()
-
- Find if study is empty:
-
- IsEmpty = myStudy.IsEmpty()
-
- if IsEmpty == 1:
-     print "The study is empty"
-
-
-
-
- -

SALOMEDS::StudyBuilder -interface
-

-
-
-
- SComponent -NewComponent ( in string ComponentDataType )
-
- Create Geometry SComponent:
-
- myBuilder = myStudy.NewBuilder()
- father = myBuilder.NewComponent("GEOM")
-
-
- void DefineComponentInstance ( in SComponent aComponent, -in Object ComponentIOR )
-
- Define the instance to the created geometry component:
-
- # find geom component
- myLCC = batchmode_salome.lcc
- geom = myLCC.FindOrLoadComponent("FactoryServer", "Geometry")
- geom = geom._narrow(GEOM.GEOM_Gen)
- geom.GetCurrentStudy(myStudyId)
-
- myBuilder = myStudy.NewBuilder()
-
- father = myBuilder.NewComponent("GEOM")
- myBuilder.DefineComponentInstance(father,geom)
-
-
- SObject -NewObject ( in SObject theFatherObject -)
-
- Create box and add it to study:
-
- from batchmode_geompy import *
-
- # create a box
- box = geom.MakeBox(0,0,0,100,100,150)
-
- ior = orb.object_to_string(box)
- box._set_Name(ior)
-
- # create Geometry SComponent
- father = myBuilder.NewComponent("GEOM")
- A1 = myBuilder.FindOrCreateAttribute(father, "AttributeName");
- FName = A1._narrow(SALOMEDS.AttributeName)
- FName.SetValue("Geometry")
- myBuilder.DefineComponentInstance(father,geom)
-
- # add box to Study
- myBuilder.NewCommand()
- newObj = myBuilder.NewObject(father)
- A1 = myBuilder.FindOrCreateAttribute(newObj, "AttributeIOR");
- ObjIOR = A1._narrow(SALOMEDS.AttributeIOR)
- ObjIOR.SetValue(ior)
- A2 = myBuilder.FindOrCreateAttribute(newObj, "AttributeName");
- ObjName = A2._narrow(SALOMEDS.AttributeName)
- ObjName.SetValue("Common_operation")
- id = newObj.GetID()
- box._set_StudyShapeId(id)
- myBuilder.CommitCommand()
-
-
- void RemoveObject ( in SObject anObject )
-
- # Remove CutPlanes SObject from the StudyBuilder (delete cutplanes):
-
- SObj=myStudy.FindObjectIOR(cutplanes.GetID())
- myBuilder = newStudy.NewBuilder()
- myBuilder.RemoveObject(SObj)
-
-
- void LoadWith ( in SComponent sco, in -Driver Engine -) raises (SALOME::SALOME_Exception)
-
- # Load Visu component:
-
- myBuilder = openedStudy.NewBuilder()
- SCom=openedStudy.FindComponent("VISU")
- myBuilder.LoadWith(SCom ,myVisu)
-
-
- GenericAttribute -FindOrCreateAttribute ( in SObject anObject, -in string aTypeOfAttribute)
-
- Create AttributeName attribute for created component an set value -to it:
-
- myBuilder = myStudy.NewBuilder()
- aComponent = myBuilder.NewComponent("User data")
-
- anAttr = myBuilder.FindOrCreateAttribute(aComponent, "AttributeName")
-
- anAttrName = anAttr._narrow(SALOMEDS.AttributeName)
- anAttrName.SetValue("User data")
-
-
- boolean FindAttribute ( in SObject anObject, out GenericAttribute -anAttribute, in string aTypeOfAttribute )
-
- Find AttributeName attribute of the field and print the -field name:
-
- aFieldSObj = myStudy.FindObject("Head, -")
-
- myStudyBuilder.FindAttribute( aFieldSObj, anAttr, "AttributeName")
- if res == 0:
-     raise RuntimeError, "Error: Attribute not -found"
-
- anAttr = anAttr._narrow(SALOMEDS.AttributeName);
- aFieldName = anAttr.Value()
- print "      ", aFieldName
-
-
- void RemoveAttribute ( in SObject anObject, in -string aTypeOfAttribute )
-
- Remove AttributeSelectable attribute of the field SObject:
-
- aFieldSObj = myStudy.FindObject("Head, -")
-
- myStudyBuilder.RemoveAttribute( aFieldSObj, "AttributeSelectable")
-
-
- void Addreference ( in SObject -anObject, in SObject theReferencedObject -)
-
- Create a reference between created SObject and the existing field:
-
- aFieldSObj = myStudy.FindObject("Head, -")
- aNewSObj = myBuilder.NewObject(myVisu)
-
- myBuilder.Addreference(aFieldSObj, aNewSObj)
-
-
- void -NewCommand ()
-
- Create new command wich containes actions for changing the -properties of the study:
-
- A = myStudy.GetProperties()
- A = aProperties._narrow(SALOMEDS.AttributeStudyProperties)
-
- myBuilder = myStudy.NewBuilder()
-
- myBuilder.NewCommand() # creates a new command
-
- # change the properties of the study
- if A.IsLocked() == 0 :
-     A.SetUserName("tester"); print 'A.SetUserName("tester"), -A.GetUserName() = ', A.GetUserName()
-     A.SetCreationDate(11,11,11,11,2002); print 'A.SetCreationDate(11,11,11,11,2002), -A.GetCreationDate() =', A.GetCreationDate()
-     print "A.IsModified() = ", A.IsModified()
- A.SetLocked(1)
-
- myBuilder.CommitCommand() # commits all actions declared -within the created command
-
-
- void CommitCommand()
-
- See the end of the previous example
-
-
- void AbortCommand ()
-
- Create new command wich containes actions for changing -the properties of the study, cancel all declared actions:
-
- A = myStudy.GetProperties()
- A = aProperties._narrow(SALOMEDS.AttributeStudyProperties)
-
- myBuilder = myStudy.NewBuilder()
-
- myBuilder.NewCommand() # creates a new command
-
- # change the properties of the study
- if A.IsLocked() == 0 :
-     A.SetUserName("tester"); print 'A.SetUserName("tester"), -A.GetUserName() = ', A.GetUserName()
-     A.SetCreationDate(11,11,11,11,2002); print 'A.SetCreationDate(11,11,11,11,2002), -A.GetCreationDate() =', A.GetCreationDate()
-     print "A.IsModified() = ", A.IsModified()
- A.SetLocked(1)
-
- myBuilder.AbortCommand() # abort all actions declared -within the created command
-
-
- void Undo () raises (LockProtection) -,
- void Redo () raises (LockProtection)
-
- Create new command wich containes actions for changing -the properties of the study,
- cancel all declared actions and then redo it with the help of undo/redo -mechanism:
-
- A = myStudy.GetProperties()
- A = aProperties._narrow(SALOMEDS.AttributeStudyProperties)
-
- myBuilder = myStudy.NewBuilder()
-
- myBuilder.NewCommand() # creates a new command
-
- # change the properties of the study
- if A.IsLocked() == 0 :
-     A.SetUserName("tester"); print 'A.SetUserName("tester"), -A.GetUserName() = ', A.GetUserName()
-     A.SetCreationDate(11,11,11,11,2002); print 'A.SetCreationDate(11,11,11,11,2002), -A.GetCreationDate() =', A.GetCreationDate()
-     print "A.IsModified() = ", A.IsModified()
- A.SetLocked(1)
-
- myBuilder.CommitCommand() # commits all actions declared -within the created command
-
- myBuilder.Undo() # cancels all actions of the command
-
- myBuilder.Redo() # redoes all actions of the command
-
-
-
- -

SALOMEDS::StudyManager -interface
-

-
-
-
- Study -NewStudy ( in string study_name )
-
- Create the study with the name "Test_Study":
-
- myNewStudy = myStudyManager.NewStudy("Test_Study")
-
-
- Study Open -( in URL -aStudyUrl ) raises (SALOME::SALOME_Exception)
-
- Open the study saved in the HDF file:
-
- file = 'saved_study.hdf'
-
- openedStudy=myStudyManager.Open(file)
-
- if openedStudy == None:
- raise RuntimeError, "Can't open saved study!"
-
-
- void Save (in Study aStudy, in boolean -theMultifile )
-
- Open study, import med file into it and save with the old -path and filename:
-
- file = "saved_study.hdf"
- myMedFile ="medfile.med"
-
- openedStudy=myStudyManager.Open(file)
-
- myVisu.SetCurrentStudy(openedStudy)
- myResult = myVisu.ImportFile(myMedFile)
-
- myStudyManager.Save(openedStudy, 0)
-
-
- void SaveAs ( in URL -aUrl, in Study aStudy, - in boolean theMultifile -)
-
- Open study from the file and resave it in several files (using -Multifile option while saving)
-
- file = "saved_study.hdf"
- newfile = "resaved_study.hdf"
-
- openedStudy=myStudyManager.Open(file)
- myStudyManager.SaveAs(newfile, openedStudy, 1)
-
-
- void Close ( in Study aStudy )
-
- Close just opened study:
-
- file = "saved_study.hdf"
-
- openedStudy=myStudyManager.Open(file)
- myStudyManager.Close(openedStudy)
-
-
-
- -

SALOMEDS::SObject interface
-

-
-
-
- ID GetID ()
-
- Create new SObject and get its ID:
-
- mySObj = myBuilder.NewObject(myFather)
-
- myID = mySObj.GetID()
-
-
- SComponent -GetFatherComponent ()
-
- Get father component of the SObject:
-
- myFather = mySObj.GetFatherComponent();
-
-
- boolean FindAttribute ( out GenericAttribute anAttribute, -in string aTypeOfAttribute )
-
- Find the AttributeName attribute of the field:
-
- aFieldSObj = myStudy.FindObject("Head, -")
-
- res = aFieldSObj.FindAttribute( anAttr, "AttributeName")
- if res == 0:
- raise RuntimeError, "Error: Attribute not -found"
-
-
- ListOfAttributes -GetAllAttributes ()
-
- Get list of all attributes of the SObject, find the number of attributes:
-
- attrs = mySObj.GetAllAttributes()
- aLen = len(attrs) # number of attributes
-
-
-
-
- -

SALOMEDS::SComponent interface
-

-
-
-
- string ComponentDataType ()
-
- Print names of all components wich -the study contains:
-
- aCompItr = myStudy.NewComponentIterator()
-
- while aCompItr.More():
-     aComp = aCompItr.Value()
-     aName = aComp.ComponentDataType()
-     print "Component name = ", aName
-     aCompItr.Next()
-
-
- Other methods are inherited.
-
-
-
-
- -

SALOMEDS::SComponentIterator - interface
-

-
-
-
- boolean More (), void Next (), SComponent Value -()
-
- See another -example
-
-
-
- -

SALOMEDS::ChildIterator - interface
-

-
-
-
- boolean More () , void Next (), SObject Value ()
-
- Print all mesh names of imported MED file with the help of ChildIterator:
-
- aResult = myVisu.ImportFile("MedFile.med")
-
- myStudy = theVisu.GetCurrentStudy()
- aSObj = myLocalStudy.FindObjectIOR(aResult.GetID())
-
- aMeshIter = myLocalStudy.NewChildIterator(aSObj); # creating new -child iterator
-
- while aMeshIter.More() : -             -           # check if one more -child level exists.
-         aMeshSObj = aMeshIter.Value() -             -        # returns the SObject corresponding -to the current object found by the iterator.
-         aMeshIter.Next() - - - # passes the iterator to the next level.
-         anAttr = aMeshSObj.FindAttribute("AttributeName")[1]
-         if anAttr is None :
-                 -aMeshSObj = aMeshIter.Value()
-               - aMeshIter.Next()
-                 -anAttr = aMeshSObj.FindAttribute("AttributeName")[1]
-         anAttr = anAttr._narrow(SALOMEDS.AttributeName);
-         aMeshName = anAttr.Value()
-         print " ", aMeshName
-
-
-
- -

SALOMEDS::AttributeComment - interface
-

-
-
- string Value (), void SetValue ( in string value )
-
- Find the AttributeComment attribute of the "Head" field in the study, -print it, then change it to "My Comment" string:
-
- aFieldSObj = myStudy.FindObject("Head, -")
- anAttr = aFieldSObj.FindAttribute("AttributeComment")[1]
- -anAttr = anAttr._narrow(SALOMEDS.AttributeComment);
- -aFieldComment = anAttr.Value()
-
- print "AttributeComment", anAttr
-
- anAttr.SetValue ("My Comment")
- -

-
- - + + + + + + + + Main Page + + + + + + + + + + + + + + +

+ + +

Examples

+
+
+ +

    Interfaces:
+
+ SALOMEDS::Study
+     SALOMEDS::StudyBuilder
+       SALOMEDS::StudyManager
+     SALOMEDS::SObject
+    SALOMEDS::SComponent
+ SALOMEDS::SComponentIterator
+ SALOMEDS::ChildIterator
+ SALOMEDS::AttributeComment
+
+

+
+
+
+ +

SALOMEDS::Study interface
+
+ +

+
+ +

SComponent FindComponent( +in string aComponentName )
+
+ Find GEOMETRY component in the opened study by its name:
+
+     str= os.getenv("TmpDir")
+     if str == None:
+         str = "/tmp"
+     file = str+"/test.hdf"
+
+     openedStudy=batchmode_geompy.myStudyManager.Open(file)
+
+     father = openedStudy.FindComponent("GEOM")
+     if father is None:
+         raise RuntimeError, "Geom + component is not found! Wrong study is opened."
+
+
+

+ +

SObject FindObject ( in string +anObjectName )
+
+ Find the SObject of the box by its NameAttribute "box":
+

+ +

box = openedStudy.FindObject("box")
+ if box is None :
+ raise RuntimeError, "box was not found! Wrong +study is opened."
+
+
+ SObject FindObjectID + ( in ID aObjectID +)
+ #result: "/User data/Case1".
+ Find + the SObject of the box by its ID "0:1:1:2":
+
+

+ +

box =openedStudy.FindObjectID("0:1:1:2")
+

+ +

if box is None :
+     raise RuntimeError, "box was not found! Wrong +ID is used."
+
+
+ SObject FindObjectIOR + ( in ID aObjectIOR +)
+
+ Find the SObject of the result on imported MED file +by it's IOR:
+
+ theResult = myVisu.ImportFile(medFile)
+ aSObj = myStudy.FindObjectIOR(theResult.GetID())
+
+
+ SObject + FindObjectByPath ( in string thePath )
+
+ Find SObject by path to it:
+
+ # create new auxiliary component
+ aComponent = myStudyBuilder.NewComponent("Virtual Component")
+
+ # create auxiliary subtree
+ aPath = "/Virtual Component/Case1"
+ myStudyBuilder.AddDirectory(aPath)
+
+ aSObj = myStudy.FindObjectByPath(aPath)
+
+
+ void SetContext ( in string thePath) / + string GetContext ()
+
+ Set context of the study to the created case and get it for printing:
+
+ aComponent = myStudyBuilder.NewComponent("User data")
+ anAttr = aBuilder.FindOrCreateAttribute(aComponent, "AttributeName")
+ anAttrName = anAttr._narrow(SALOMEDS.AttributeName)
+ anAttrName.SetValue("User data")
+
+ #Add a new case 'Case1' to the component 'User data'
+ aBuilder.AddDirectory("/User data/Case1")
+
+ #Set a study context to '/User data/Case1'
+ aStudy.SetContext("/User data/Case1")
+
+ #Print the current study context
+ print aStudy.GetContext()
+
+ #result: "/User data/Case1".
+
+
+ ChildIterator + NewChildIterator ( in SObject aSO )
+
+ Import med file and print all mesh names that this file includes +(mesh is a child of the result of imported file):
+
+ # define file name
+ aFileName = datadir + "fra.med"
+
+ # import file in visu module and get result
+ theVisu = batchmode_visu.myVisu
+ aResult = theVisu.ImportFile(aFileName)
+ if aResult is None : raise RuntimeError, "Error"
+ else : print "OK"
+
+ # get current study and its' SObject       +
+ myLocalStudy = theVisu.GetCurrentStudy()
+ aSObj = myLocalStudy.FindObjectIOR(aResult.GetID())
+ if aSObj is None : raise RuntimeError, "Error"
+ else : print "OK"
+
+ # create iterator by SObject of the current study
+ aMeshIter = myLocalStudy.NewChildIterator(aSObj);
+
+ # iterating in the current study (with the help of created iterator) +to find all mesh names
+ while aMeshIter.More() :
+         aMeshSObj = aMeshIter.Value()
+         aMeshIter.Next()
+         anAttr = aMeshSObj.FindAttribute("AttributeName")[1]
+         if anAttr is None :
+             aMeshSObj + = aMeshIter.Value()
+             aMeshIter.Next()
+             anAttr + = aMeshSObj.FindAttribute("AttributeName")[1]
+         anAttr = anAttr._narrow(SALOMEDS.AttributeName);
+         aMeshName = anAttr.Value()
+         print " ", aMeshName
+
+
+ SComponentIterator +NewComponentIterator ()
+
+ Find the number an names of all components in the study:
+
+ aCompItr = myStudy.NewComponentIterator()
+
+ compNb = 0
+ while aCompItr.More():
+     aComp = aCompItr.Value()
+     aName = aComp.ComponentDataType()
+     print "Component name = ", aName
+     compNb += 1
+     aCompItr.Next()
+
+
+ StudyBuilder +NewBuilder ()
+

+
+ Create a new StudyBuilder (uses to add or modify an object in the +study ):
+
+ myBuilder = myStudy.NewBuilder()
+
+
+ AttributeStudyProperties +GetProperties ()
+
+ Get the attribute, which contains the properties of the study, and +change properties of the study by changing it:
+
+ aProperties = myStudy.GetProperties()
+ if aProperties == None :
+     raise RuntimeError, "Can't create AttributeStudyProperties +attribute"
+ aProperties = aProperties._narrow(SALOMEDS.AttributeStudyProperties)
+
+ A = aProperties
+
+ # print stydy properties
+ print "A.GetUserName()= ", A.GetUserName()
+ res,mm,hh,dd,mnth,yy=A.GetCreationDate()
+ print "A.GetCreationDate() = ", mm,hh,dd,mnth,yy
+ print "A.GetCreationMode() = ", A.GetCreationMode()
+ print "A.IsModified() = ", A.IsModified()
+ print "A.IsLocked() = ", A.IsLocked()
+
+ # change the properties of the study
+ if A.IsLocked() == 0 :
+     A.SetUserName("tester"); print 'A.SetUserName("tester"), +A.GetUserName() = ', A.GetUserName()
+     A.SetCreationDate(11,11,11,11,2002); print 'A.SetCreationDate(11,11,11,11,2002), +A.GetCreationDate() =', A.GetCreationDate()
+     print "A.IsModified() = ", A.IsModified()
+ A.SetLocked(1)
+
+
+ boolean IsModified ()
+
+ Find if study is modified:
+
+ IsModified = myStudy.IsModified()
+
+ if IsModified == 1:
+     print "The study is modified and not saved"
+
+
+ boolean IsEmpty ()
+
+ Find if study is empty:
+
+ IsEmpty = myStudy.IsEmpty()
+
+ if IsEmpty == 1:
+     print "The study is empty"
+
+
+
+
+ +

SALOMEDS::StudyBuilder +interface
+

+
+
+
+ SComponent +NewComponent ( in string ComponentDataType )
+
+ Create Geometry SComponent:
+
+ myBuilder = myStudy.NewBuilder()
+ father = myBuilder.NewComponent("GEOM")
+
+
+ void DefineComponentInstance ( in SComponent aComponent, +in Object ComponentIOR )
+
+ Define the instance to the created geometry component:
+
+ # find geom component
+ myLCC = batchmode_salome.lcc
+ geom = myLCC.FindOrLoadComponent("FactoryServer", "Geometry")
+ geom = geom._narrow(GEOM.GEOM_Gen)
+ geom.GetCurrentStudy(myStudyId)
+
+ myBuilder = myStudy.NewBuilder()
+
+ father = myBuilder.NewComponent("GEOM")
+ myBuilder.DefineComponentInstance(father,geom)
+
+
+ SObject +NewObject ( in SObject theFatherObject +)
+
+ Create box and add it to study:
+
+ from batchmode_geompy import *
+
+ # create a box
+ box = geom.MakeBox(0,0,0,100,100,150)
+
+ ior = orb.object_to_string(box)
+ box._set_Name(ior)
+
+ # create Geometry SComponent
+ father = myBuilder.NewComponent("GEOM")
+ A1 = myBuilder.FindOrCreateAttribute(father, "AttributeName");
+ FName = A1._narrow(SALOMEDS.AttributeName)
+ FName.SetValue("Geometry")
+ myBuilder.DefineComponentInstance(father,geom)
+
+ # add box to Study
+ myBuilder.NewCommand()
+ newObj = myBuilder.NewObject(father)
+ A1 = myBuilder.FindOrCreateAttribute(newObj, "AttributeIOR");
+ ObjIOR = A1._narrow(SALOMEDS.AttributeIOR)
+ ObjIOR.SetValue(ior)
+ A2 = myBuilder.FindOrCreateAttribute(newObj, "AttributeName");
+ ObjName = A2._narrow(SALOMEDS.AttributeName)
+ ObjName.SetValue("Common_operation")
+ id = newObj.GetID()
+ box._set_StudyShapeId(id)
+ myBuilder.CommitCommand()
+
+
+ void RemoveObject ( in SObject anObject )
+
+ # Remove CutPlanes SObject from the StudyBuilder (delete cutplanes):
+
+ SObj=myStudy.FindObjectIOR(cutplanes.GetID())
+ myBuilder = newStudy.NewBuilder()
+ myBuilder.RemoveObject(SObj)
+
+
+ void LoadWith ( in SComponent sco, in +Driver Engine +) raises (SALOME::SALOME_Exception)
+
+ # Load Visu component:
+
+ myBuilder = openedStudy.NewBuilder()
+ SCom=openedStudy.FindComponent("VISU")
+ myBuilder.LoadWith(SCom ,myVisu)
+
+
+ GenericAttribute +FindOrCreateAttribute ( in SObject anObject, +in string aTypeOfAttribute)
+
+ Create AttributeName attribute for created component an set value +to it:
+
+ myBuilder = myStudy.NewBuilder()
+ aComponent = myBuilder.NewComponent("User data")
+
+ anAttr = myBuilder.FindOrCreateAttribute(aComponent, "AttributeName")
+
+ anAttrName = anAttr._narrow(SALOMEDS.AttributeName)
+ anAttrName.SetValue("User data")
+
+
+ boolean FindAttribute ( in SObject anObject, out GenericAttribute +anAttribute, in string aTypeOfAttribute )
+
+ Find AttributeName attribute of the field and print the +field name:
+
+ aFieldSObj = myStudy.FindObject("Head, -")
+
+ myStudyBuilder.FindAttribute( aFieldSObj, anAttr, "AttributeName")
+ if res == 0:
+     raise RuntimeError, "Error: Attribute not +found"
+
+ anAttr = anAttr._narrow(SALOMEDS.AttributeName);
+ aFieldName = anAttr.Value()
+ print "      ", aFieldName
+
+
+ void RemoveAttribute ( in SObject anObject, in +string aTypeOfAttribute )
+
+ Remove AttributeSelectable attribute of the field SObject:
+
+ aFieldSObj = myStudy.FindObject("Head, -")
+
+ myStudyBuilder.RemoveAttribute( aFieldSObj, "AttributeSelectable")
+
+
+ void Addreference ( in SObject +anObject, in SObject theReferencedObject +)
+
+ Create a reference between created SObject and the existing field:
+
+ aFieldSObj = myStudy.FindObject("Head, -")
+ aNewSObj = myBuilder.NewObject(myVisu)
+
+ myBuilder.Addreference(aFieldSObj, aNewSObj)
+
+
+ void +NewCommand ()
+
+ Create new command wich containes actions for changing the +properties of the study:
+
+ A = myStudy.GetProperties()
+ A = aProperties._narrow(SALOMEDS.AttributeStudyProperties)
+
+ myBuilder = myStudy.NewBuilder()
+
+ myBuilder.NewCommand() # creates a new command
+
+ # change the properties of the study
+ if A.IsLocked() == 0 :
+     A.SetUserName("tester"); print 'A.SetUserName("tester"), +A.GetUserName() = ', A.GetUserName()
+     A.SetCreationDate(11,11,11,11,2002); print 'A.SetCreationDate(11,11,11,11,2002), +A.GetCreationDate() =', A.GetCreationDate()
+     print "A.IsModified() = ", A.IsModified()
+ A.SetLocked(1)
+
+ myBuilder.CommitCommand() # commits all actions declared +within the created command
+
+
+ void CommitCommand()
+
+ See the end of the previous example
+
+
+ void AbortCommand ()
+
+ Create new command wich containes actions for changing +the properties of the study, cancel all declared actions:
+
+ A = myStudy.GetProperties()
+ A = aProperties._narrow(SALOMEDS.AttributeStudyProperties)
+
+ myBuilder = myStudy.NewBuilder()
+
+ myBuilder.NewCommand() # creates a new command
+
+ # change the properties of the study
+ if A.IsLocked() == 0 :
+     A.SetUserName("tester"); print 'A.SetUserName("tester"), +A.GetUserName() = ', A.GetUserName()
+     A.SetCreationDate(11,11,11,11,2002); print 'A.SetCreationDate(11,11,11,11,2002), +A.GetCreationDate() =', A.GetCreationDate()
+     print "A.IsModified() = ", A.IsModified()
+ A.SetLocked(1)
+
+ myBuilder.AbortCommand() # abort all actions declared +within the created command
+
+
+ void Undo () raises (LockProtection) +,
+ void Redo () raises (LockProtection)
+
+ Create new command wich containes actions for changing +the properties of the study,
+ cancel all declared actions and then redo it with the help of undo/redo +mechanism:
+
+ A = myStudy.GetProperties()
+ A = aProperties._narrow(SALOMEDS.AttributeStudyProperties)
+
+ myBuilder = myStudy.NewBuilder()
+
+ myBuilder.NewCommand() # creates a new command
+
+ # change the properties of the study
+ if A.IsLocked() == 0 :
+     A.SetUserName("tester"); print 'A.SetUserName("tester"), +A.GetUserName() = ', A.GetUserName()
+     A.SetCreationDate(11,11,11,11,2002); print 'A.SetCreationDate(11,11,11,11,2002), +A.GetCreationDate() =', A.GetCreationDate()
+     print "A.IsModified() = ", A.IsModified()
+ A.SetLocked(1)
+
+ myBuilder.CommitCommand() # commits all actions declared +within the created command
+
+ myBuilder.Undo() # cancels all actions of the command
+
+ myBuilder.Redo() # redoes all actions of the command
+
+
+
+ +

SALOMEDS::StudyManager +interface
+

+
+
+
+ Study +NewStudy ( in string study_name )
+
+ Create the study with the name "Test_Study":
+
+ myNewStudy = myStudyManager.NewStudy("Test_Study")
+
+
+ Study Open +( in URL +aStudyUrl ) raises (SALOME::SALOME_Exception)
+
+ Open the study saved in the HDF file:
+
+ file = 'saved_study.hdf'
+
+ openedStudy=myStudyManager.Open(file)
+
+ if openedStudy == None:
+ raise RuntimeError, "Can't open saved study!"
+
+
+ void Save (in Study aStudy, in boolean +theMultifile )
+
+ Open study, import med file into it and save with the old +path and filename:
+
+ file = "saved_study.hdf"
+ myMedFile ="medfile.med"
+
+ openedStudy=myStudyManager.Open(file)
+
+ myVisu.SetCurrentStudy(openedStudy)
+ myResult = myVisu.ImportFile(myMedFile)
+
+ myStudyManager.Save(openedStudy, 0)
+
+
+ void SaveAs ( in URL +aUrl, in Study aStudy, + in boolean theMultifile +)
+
+ Open study from the file and resave it in several files (using +Multifile option while saving)
+
+ file = "saved_study.hdf"
+ newfile = "resaved_study.hdf"
+
+ openedStudy=myStudyManager.Open(file)
+ myStudyManager.SaveAs(newfile, openedStudy, 1)
+
+
+ void Close ( in Study aStudy )
+
+ Close just opened study:
+
+ file = "saved_study.hdf"
+
+ openedStudy=myStudyManager.Open(file)
+ myStudyManager.Close(openedStudy)
+
+
+
+ +

SALOMEDS::SObject interface
+

+
+
+
+ ID GetID ()
+
+ Create new SObject and get its ID:
+
+ mySObj = myBuilder.NewObject(myFather)
+
+ myID = mySObj.GetID()
+
+
+ SComponent +GetFatherComponent ()
+
+ Get father component of the SObject:
+
+ myFather = mySObj.GetFatherComponent();
+
+
+ boolean FindAttribute ( out GenericAttribute anAttribute, +in string aTypeOfAttribute )
+
+ Find the AttributeName attribute of the field:
+
+ aFieldSObj = myStudy.FindObject("Head, -")
+
+ res = aFieldSObj.FindAttribute( anAttr, "AttributeName")
+ if res == 0:
+ raise RuntimeError, "Error: Attribute not +found"
+
+
+ ListOfAttributes +GetAllAttributes ()
+
+ Get list of all attributes of the SObject, find the number of attributes:
+
+ attrs = mySObj.GetAllAttributes()
+ aLen = len(attrs) # number of attributes
+
+
+
+
+ +

SALOMEDS::SComponent interface
+

+
+
+
+ string ComponentDataType ()
+
+ Print names of all components wich +the study contains:
+
+ aCompItr = myStudy.NewComponentIterator()
+
+ while aCompItr.More():
+     aComp = aCompItr.Value()
+     aName = aComp.ComponentDataType()
+     print "Component name = ", aName
+     aCompItr.Next()
+
+
+ Other methods are inherited.
+
+
+
+
+ +

SALOMEDS::SComponentIterator + interface
+

+
+
+
+ boolean More (), void Next (), SComponent Value +()
+
+ See another +example
+
+
+
+ +

SALOMEDS::ChildIterator + interface
+

+
+
+
+ boolean More () , void Next (), SObject Value ()
+
+ Print all mesh names of imported MED file with the help of ChildIterator:
+
+ aResult = myVisu.ImportFile("MedFile.med")
+
+ myStudy = theVisu.GetCurrentStudy()
+ aSObj = myLocalStudy.FindObjectIOR(aResult.GetID())
+
+ aMeshIter = myLocalStudy.NewChildIterator(aSObj); # creating new +child iterator
+
+ while aMeshIter.More() : +             +           # check if one more +child level exists.
+         aMeshSObj = aMeshIter.Value() +             +        # returns the SObject corresponding +to the current object found by the iterator.
+         aMeshIter.Next() + + + # passes the iterator to the next level.
+         anAttr = aMeshSObj.FindAttribute("AttributeName")[1]
+         if anAttr is None :
+                 +aMeshSObj = aMeshIter.Value()
+               + aMeshIter.Next()
+                 +anAttr = aMeshSObj.FindAttribute("AttributeName")[1]
+         anAttr = anAttr._narrow(SALOMEDS.AttributeName);
+         aMeshName = anAttr.Value()
+         print " ", aMeshName
+
+
+
+ +

SALOMEDS::AttributeComment + interface
+

+
+
+ string Value (), void SetValue ( in string value )
+
+ Find the AttributeComment attribute of the "Head" field in the study, +print it, then change it to "My Comment" string:
+
+ aFieldSObj = myStudy.FindObject("Head, -")
+ anAttr = aFieldSObj.FindAttribute("AttributeComment")[1]
+ +anAttr = anAttr._narrow(SALOMEDS.AttributeComment);
+ +aFieldComment = anAttr.Value()
+
+ print "AttributeComment", anAttr
+
+ anAttr.SetValue ("My Comment")
+ +

+
+ + diff --git a/doc/salome/tui/KERNEL/sources/static/mapping.html b/doc/salome/tui/KERNEL/sources/static/mapping.html index 21ead079f..f3f0a3f53 100755 --- a/doc/salome/tui/KERNEL/sources/static/mapping.html +++ b/doc/salome/tui/KERNEL/sources/static/mapping.html @@ -1,329 +1,329 @@ - - - - - - Main Page - - - - - - - - - - -

- -

-Mapping of IDL definitions to Python language.

- -

-Introduction

-SALOME is a distributed client/server application using the Common -Object Request Broker Architecture (CORBA). CORBA architecture uses the -Interface Definition Language (IDL), which specifies interfaces between -CORBA objects. So with help of IDL CORBA's language independence is ensured -. Because interfaces described in IDL can be mapped to the most of currently -used programming languages, CORBA applications and components are thus -independent of the language(s) used to implement them. In other words, -a client written in C++ can communicate with a server written in Java, -which in turn can communicate with another server written in COBOL, and -so forth. -

One important thing to remember about IDL is that it is not an implementation -language. That is, applications can't be written in IDL. The sole purpose -of IDL is to define interfaces; providing implementations for these interfaces -is performed using some other language. -

This page contains an abridged reference manual for mapping of IDL definitions -to Python language. It will be useful for Python programmers who are not -familiar with IDL language. All examples are taken from SALOME source -files. The complete version of Python Language Mapping Specification can -be found here. -
-

CONTENTS: -

-Using Scoped Names
-Mapping for Template and Array Types
-Mapping for Objects and Operations
-Narrowing Object References
-Mapping for Exceptions
-Mapping for Enumeration Types
-Mapping for Structured Types

-
- -

-Using Scoped Names

-Python implements a module concept that is similar to the IDL scoping mechanisms, -except that it does not allow for nested modules. In addition, Python requires -each object to be implemented in a module; globally visible objects are -not supported. -

Because of these constraints, scoped names are translated into Python -using the following rules: -

An IDL module mapped into a Python module. Modules containing modules -are mapped to packages (i.e., directories with an __init__ module -containing all definitions excluding the nested modules). An implementation -can chose to map toplevel definitions (including the module CORBA) to modules -in an implementationdefined package, to allow concurrent installations -of different CORBA runtime libraries. In that case, the implementation -must provide additional modules so that toplevel modules can be used without -importing them from a package. -

For all other scopes, a Python class is introduced that contains all -the definitions inside this scope. -

Other global definitions (except modules) appear in a module whose -name is implementation dependent. Implementations are encouraged to use -the name of the IDL file when defining the name of that module. -

For instance, -

module SALOMEDS {
- interface StudyManager {
-  void  Close(in Study aStudy);
- };
-};

-would introduce a module SALOMEDS.py, which contains the following definitions: -

# module SALOMEDS.py
-class StudyManager:
-  def _Close(self,aStudy):
-   pass #interfaces are discussed later

-To avoid conflicts, IDL names that are also Python identifiers are prefixed -with an underscore (_). -

Back to the contents -

-Mapping for Template and Array Types

-Both the bounded and the unbounded string type of IDL are mapped to the -Python string type. Wide strings are represented by an implementation-defined -type with the following properties: -

For the wide string X and the integer n, X[n] returns the nth character, -which is a wide string of length 1. -

len(X) returns the number of characters of wide string X. -

CORBA.wstr(c) returns a wide character with the code point c in an -implementation-defined encoding. -

X+Y returns the concatenation of wide strings X and Y. -

CORBA.word(CORBA.wstr(c)) == c -

The sequence template is mapped to sequence objects (e.g., tuples or -lists). Applications should not assume that values of a sequence type are -mutable. Sequences and arrays of octets and characters are mapped to the -string type for efficiency reasons. -

For example, given the IDL definitions -

module SALOMEDS {
-  typedef sequence <string> StringSeq;
-   
-   interface AttributeTableOfInteger : GenericAttribute {
-
-    void SetRowTitles(in StringSeq theTitles) raises(IncorrectArgumentLength);
- };
-};

-a client could invoke the operation -

print My_AttributeTableOfInteger.SetRowTitles(["X","F"])

-Array types are mapped like sequence templates. The application in this -example also expects an IncorrectArgumentLength exception if it passes -sequences that violate the bounds constraint or arrays of wrong size. -

Another example with arrays. The following IDL definition -

module SALOMEDS {
- typedef sequence<GenericAttribute> ListOfAttributes;
- interface SObject {
-  ListOfAttributes     GetAllAttributes();
- };
-};

-is equal to -

import SALOMEDS
-
-attributes=[]
- 
-attributes = My_SObject.GetAllAttributes()
-
-length = len(attributes)
-
-print "Attributes number = ", length
-print attributes

-Back to the contents -

-Mapping for Objects and Operations

-A CORBA object reference is represented as a Python object at run-time. -This object provides all the operations that are available on the interface -of the object. Although this specification does not mandate the use of -classes for stub objects, the following discussion uses classes to indicate -the interface. -

The nil object is represented by None. -

If an operation expects parameters of the IDL Object type, any Python -object representing an object reference might be passed as actual argument. -

If an operation expects a parameter of an abstract interface, either -an object implementing that interface, or a value supporting this interface -may be passed as actual argument. The semantics of abstract values then -define whether the argument is passed by value or by reference. -

Operations of an interface map to methods available on the object references. -Parameters with a parameter attribute of in or inout are -passed from left to right tothe method, skipping out parameters. -The return value of a method depends on the number of out parameters -and the return type. If the operation returns a value, this value forms -the first result value. All inout or out parameters -form consecutive result values. The method result depends then on -the number of result values: -

If there is no result value, the method returns None. -

If there is exactly one result value, it is returned as a single -value. -

If there is more than one result value, all of them are packed -into a tuple, and this tuple is returned. -

Assuming the IDL definition -

module SALOMEDS{
- interface StudyBuilder{
-  boolean FindAttribute  ( in SObject anObject, 
-                           out GenericAttribute anAttribute, 
-                           in string aTypeOfAttribute );
- };
-};

-a client could write -

from SALOMEDS import StudyBuilder;
-my_StudyBuilder=...
-  
-  res,A=my_StudyBuilder.FindAttribute(Sobj, "AttributeSequenceOfReal")

-In this example A corresponds to the return value anAttribute -and res to the boolean return value. -

If an interface defines an attribute name, for example, the attribute -is mapped into an operation _get_name. If the attribute is not readonly, -there is an additional operation _set_name. -

The IDL definition -

module SALOMEDS{
- interface Study{
-  attribute string Name;
- };
-};

-is equal to the following -

from SALOMEDS import Study
-My_Study=...
-  Name=My_Study._get_name();
-  Name=My_Study._set_name();

-Back to the contents -

-Narrowing Object References

-Python objects returned from CORBA operations or pseudo-operations (such -as string_to_object) might have a dynamic type, which is more specific -than the static type as defined in the operation signature. -

Since there is no efficient and reliable way of automatically creating -the most specific type, explicit narrowing is necessary. To narrow an object -reference A to an interface class AttributeSequenceOfReal, -the client can use the following operation -

A = A._narrow(SALOMEDS.AttributeSequenceOfReal)

-Back to the contents -

-Mapping for Exceptions

-An IDL exception is translated into a Python class derived from CORBA.UserException. -System exceptions are derived from CORBA.SystemException. Both base classes -are derived from CORBA.Exception. The parameters of the exception are mapped -in the same way as the fields of a struct definition. When raising an exception, -a new instance of the class is created; the constructor expects the exception -parameters. For example, the definition -

module SALOMEDS{
- interface StudyBuilder{
-  exception LockProtection {};
-  void CommitCommand() raises(LockProtection);
- };
-};

-could be used caught as -

from SALOMEDS import StudyBuilder;
-my_StudyBuilder=...
-try:
-  my_StudyBuilder.CommitCommand();
-except StudyBuilder.LockProtection,value:
-  print "Error! Study is locked for modifications"

- -

Back to the contents -

-Mapping for Enumeration Types

-An enumeration is mapped into a number of constant objects in the name -space where the enumeration is defined. An application may only test for -equivalence of two enumeration values, and not assume that they behave -like numbers. For example, the definition -

module VISU {
- interface PrsObject{
- 
-  enum PrsObjType{ TCURVE, TTABLE, TMESH, TCONTAINER,
-                   TSCALARMAP, TISOSURFACE, TDEFORMEDSHAPE,
-                   TCUTPLANES, TVECTORS };
- };
-};

-introduces the objects -

from VISU import PrsObject
-VISU.PrsObjType.TCURVE,VISU.PrsObjType.TTABLE,VISU.PrsObjType.TMESH,VISU.PrsObjType.TCONTAINER,
-VISU.PrsObjType.TSCALARMAP,VISU.PrsObjType.TISOSURFACE,VISU.PrsObjType.TDEFORMEDSHAPE,VISU.PrsObjType.TCUTPLANES,
-VISU.PrsObjType.TVECTORS

-Back to the contents -

-Mapping for Structured Types

-An IDL struct definition is mapped into a Python class or type. For each -field in the struct, there is a corresponding attribute in the class with -the same name as the field. The constructor of the class expects the field -values, from left to right. For example, the IDL definition -

struct SDate {
-               short Second;
-               short Minute;
-               short Hour;
-               short Day;
-               short Month;
-               short Year;
-             };

-could be used in the Python statements -

Date=SDate(30, 12, 15, 26, 1, 79)
-print Date.Second,Date.Minute,Date.Hour,Date.Day,Date.Month,Date.Year

- -

-Back to the contents

- - - - + + + + + + Main Page + + + + + + + + + + +

+ +

+Mapping of IDL definitions to Python language.

+ +

+Introduction

+SALOME is a distributed client/server application using the Common +Object Request Broker Architecture (CORBA). CORBA architecture uses the +Interface Definition Language (IDL), which specifies interfaces between +CORBA objects. So with help of IDL CORBA's language independence is ensured +. Because interfaces described in IDL can be mapped to the most of currently +used programming languages, CORBA applications and components are thus +independent of the language(s) used to implement them. In other words, +a client written in C++ can communicate with a server written in Java, +which in turn can communicate with another server written in COBOL, and +so forth. +

One important thing to remember about IDL is that it is not an implementation +language. That is, applications can't be written in IDL. The sole purpose +of IDL is to define interfaces; providing implementations for these interfaces +is performed using some other language. +

This page contains an abridged reference manual for mapping of IDL definitions +to Python language. It will be useful for Python programmers who are not +familiar with IDL language. All examples are taken from SALOME source +files. The complete version of Python Language Mapping Specification can +be found here. +
+

CONTENTS: +

+Using Scoped Names
+Mapping for Template and Array Types
+Mapping for Objects and Operations
+Narrowing Object References
+Mapping for Exceptions
+Mapping for Enumeration Types
+Mapping for Structured Types

+
+ +

+Using Scoped Names

+Python implements a module concept that is similar to the IDL scoping mechanisms, +except that it does not allow for nested modules. In addition, Python requires +each object to be implemented in a module; globally visible objects are +not supported. +

Because of these constraints, scoped names are translated into Python +using the following rules: +

An IDL module mapped into a Python module. Modules containing modules +are mapped to packages (i.e., directories with an __init__ module +containing all definitions excluding the nested modules). An implementation +can chose to map toplevel definitions (including the module CORBA) to modules +in an implementationdefined package, to allow concurrent installations +of different CORBA runtime libraries. In that case, the implementation +must provide additional modules so that toplevel modules can be used without +importing them from a package. +

For all other scopes, a Python class is introduced that contains all +the definitions inside this scope. +

Other global definitions (except modules) appear in a module whose +name is implementation dependent. Implementations are encouraged to use +the name of the IDL file when defining the name of that module. +

For instance, +

module SALOMEDS {
+ interface StudyManager {
+  void  Close(in Study aStudy);
+ };
+};

+would introduce a module SALOMEDS.py, which contains the following definitions: +

# module SALOMEDS.py
+class StudyManager:
+  def _Close(self,aStudy):
+   pass #interfaces are discussed later

+To avoid conflicts, IDL names that are also Python identifiers are prefixed +with an underscore (_). +

Back to the contents +

+Mapping for Template and Array Types

+Both the bounded and the unbounded string type of IDL are mapped to the +Python string type. Wide strings are represented by an implementation-defined +type with the following properties: +

For the wide string X and the integer n, X[n] returns the nth character, +which is a wide string of length 1. +

len(X) returns the number of characters of wide string X. +

CORBA.wstr(c) returns a wide character with the code point c in an +implementation-defined encoding. +

X+Y returns the concatenation of wide strings X and Y. +

CORBA.word(CORBA.wstr(c)) == c +

The sequence template is mapped to sequence objects (e.g., tuples or +lists). Applications should not assume that values of a sequence type are +mutable. Sequences and arrays of octets and characters are mapped to the +string type for efficiency reasons. +

For example, given the IDL definitions +

module SALOMEDS {
+  typedef sequence <string> StringSeq;
+   
+   interface AttributeTableOfInteger : GenericAttribute {
+
+    void SetRowTitles(in StringSeq theTitles) raises(IncorrectArgumentLength);
+ };
+};

+a client could invoke the operation +

print My_AttributeTableOfInteger.SetRowTitles(["X","F"])

+Array types are mapped like sequence templates. The application in this +example also expects an IncorrectArgumentLength exception if it passes +sequences that violate the bounds constraint or arrays of wrong size. +

Another example with arrays. The following IDL definition +

module SALOMEDS {
+ typedef sequence<GenericAttribute> ListOfAttributes;
+ interface SObject {
+  ListOfAttributes     GetAllAttributes();
+ };
+};

+is equal to +

import SALOMEDS
+
+attributes=[]
+ 
+attributes = My_SObject.GetAllAttributes()
+
+length = len(attributes)
+
+print "Attributes number = ", length
+print attributes

+Back to the contents +

+Mapping for Objects and Operations

+A CORBA object reference is represented as a Python object at run-time. +This object provides all the operations that are available on the interface +of the object. Although this specification does not mandate the use of +classes for stub objects, the following discussion uses classes to indicate +the interface. +

The nil object is represented by None. +

If an operation expects parameters of the IDL Object type, any Python +object representing an object reference might be passed as actual argument. +

If an operation expects a parameter of an abstract interface, either +an object implementing that interface, or a value supporting this interface +may be passed as actual argument. The semantics of abstract values then +define whether the argument is passed by value or by reference. +

Operations of an interface map to methods available on the object references. +Parameters with a parameter attribute of in or inout are +passed from left to right tothe method, skipping out parameters. +The return value of a method depends on the number of out parameters +and the return type. If the operation returns a value, this value forms +the first result value. All inout or out parameters +form consecutive result values. The method result depends then on +the number of result values: +

If there is no result value, the method returns None. +

If there is exactly one result value, it is returned as a single +value. +

If there is more than one result value, all of them are packed +into a tuple, and this tuple is returned. +

Assuming the IDL definition +

module SALOMEDS{
+ interface StudyBuilder{
+  boolean FindAttribute  ( in SObject anObject, 
+                           out GenericAttribute anAttribute, 
+                           in string aTypeOfAttribute );
+ };
+};

+a client could write +

from SALOMEDS import StudyBuilder;
+my_StudyBuilder=...
+  
+  res,A=my_StudyBuilder.FindAttribute(Sobj, "AttributeSequenceOfReal")

+In this example A corresponds to the return value anAttribute +and res to the boolean return value. +

If an interface defines an attribute name, for example, the attribute +is mapped into an operation _get_name. If the attribute is not readonly, +there is an additional operation _set_name. +

The IDL definition +

module SALOMEDS{
+ interface Study{
+  attribute string Name;
+ };
+};

+is equal to the following +

from SALOMEDS import Study
+My_Study=...
+  Name=My_Study._get_name();
+  Name=My_Study._set_name();

+Back to the contents +

+Narrowing Object References

+Python objects returned from CORBA operations or pseudo-operations (such +as string_to_object) might have a dynamic type, which is more specific +than the static type as defined in the operation signature. +

Since there is no efficient and reliable way of automatically creating +the most specific type, explicit narrowing is necessary. To narrow an object +reference A to an interface class AttributeSequenceOfReal, +the client can use the following operation +

A = A._narrow(SALOMEDS.AttributeSequenceOfReal)

+Back to the contents +

+Mapping for Exceptions

+An IDL exception is translated into a Python class derived from CORBA.UserException. +System exceptions are derived from CORBA.SystemException. Both base classes +are derived from CORBA.Exception. The parameters of the exception are mapped +in the same way as the fields of a struct definition. When raising an exception, +a new instance of the class is created; the constructor expects the exception +parameters. For example, the definition +

module SALOMEDS{
+ interface StudyBuilder{
+  exception LockProtection {};
+  void CommitCommand() raises(LockProtection);
+ };
+};

+could be used caught as +

from SALOMEDS import StudyBuilder;
+my_StudyBuilder=...
+try:
+  my_StudyBuilder.CommitCommand();
+except StudyBuilder.LockProtection,value:
+  print "Error! Study is locked for modifications"

+ +

Back to the contents +

+Mapping for Enumeration Types

+An enumeration is mapped into a number of constant objects in the name +space where the enumeration is defined. An application may only test for +equivalence of two enumeration values, and not assume that they behave +like numbers. For example, the definition +

module VISU {
+ interface PrsObject{
+ 
+  enum PrsObjType{ TCURVE, TTABLE, TMESH, TCONTAINER,
+                   TSCALARMAP, TISOSURFACE, TDEFORMEDSHAPE,
+                   TCUTPLANES, TVECTORS };
+ };
+};

+introduces the objects +

from VISU import PrsObject
+VISU.PrsObjType.TCURVE,VISU.PrsObjType.TTABLE,VISU.PrsObjType.TMESH,VISU.PrsObjType.TCONTAINER,
+VISU.PrsObjType.TSCALARMAP,VISU.PrsObjType.TISOSURFACE,VISU.PrsObjType.TDEFORMEDSHAPE,VISU.PrsObjType.TCUTPLANES,
+VISU.PrsObjType.TVECTORS

+Back to the contents +

+Mapping for Structured Types

+An IDL struct definition is mapped into a Python class or type. For each +field in the struct, there is a corresponding attribute in the class with +the same name as the field. The constructor of the class expects the field +values, from left to right. For example, the IDL definition +

struct SDate {
+               short Second;
+               short Minute;
+               short Hour;
+               short Day;
+               short Month;
+               short Year;
+             };

+could be used in the Python statements +

Date=SDate(30, 12, 15, 26, 1, 79)
+print Date.Second,Date.Minute,Date.Hour,Date.Day,Date.Month,Date.Year

+ +

+Back to the contents

+ + + + diff --git a/doc/salome/tui/KERNEL/sources/static/ns_f3-1.jpg b/doc/salome/tui/KERNEL/sources/static/ns_f3-1.jpg deleted file mode 100755 index fd4f45602..000000000 Binary files a/doc/salome/tui/KERNEL/sources/static/ns_f3-1.jpg and /dev/null differ diff --git a/doc/salome/tui/KERNEL/sources/static/overview_Kernel.html b/doc/salome/tui/KERNEL/sources/static/overview_Kernel.html index 144d3c341..7f64f4369 100755 --- a/doc/salome/tui/KERNEL/sources/static/overview_Kernel.html +++ b/doc/salome/tui/KERNEL/sources/static/overview_Kernel.html @@ -1,191 +1,191 @@ - - - - - - Main Page - - - - - - - - - - - -

- - -

General overview -

- -
-
1. Introduction
-
2. Basic principles
- -
3. Services and features of the SALOME kernel module
-
-
3.1 Session service
-
3.2 Registry service
-
3.3 Notification service
-
3.4 Module catalog service
-
3.5 Data type catalog
-
3.6 Resource catalog
-
3.7 Engine
-
-
3.7.1 Component class
-
3.7.2 Container class
-
-
-
-
-

1. Introduction

The kernel corresponds to the minimal set of services required for the use of SALOME components (Supervisor, IAPP). -The kernel is also used by application software components (solver) and their container. -The kernel is associated to a unique user who can launch only one kernel at once. -The kernel is launched and destroyed by voluntary actions of the user. These functions are realized via the -use of scripts.

The list of the kernel services related to communication issues is:

The Naming service
The Session service
The Life Cycle service
The Registry service
The Notification service

This list is enlarged with CORBA independent services :

- -

The module catalog service
The Data Type Catalog service
The resource catalog service

SALOME kernel module also encapsulates the Engine -Back to the contents -

2. Basic principles

The SALOME user's desktop is a process on a machine. This process includes:

A graphic interface (based on Qt),
A text interface (Python interpreter),
A 3D visualization window shared by components.

SALOME Modules decompose into an interface (widgets GUI, text mode TUI, 3D visualization V3D) and -an engine.

The description of a module and its components is obtained by consulting the module catalog.

The interface is dynamically loaded in the process of the SALOME user's desktop. The engine is a CORBA -server launched either on the local machine or on the distant machine.

The engine (CORBA server) is created by a factory (or container). -This factory is also a CORBA server. Several containers can be present on a machine. -Some containers are specialized for types of components requiring a specific management. -For example, a specific container is required for components performing parallel calculations. -The engine includes at least a dynamically linked library in the container process. -This library is the implementation of the CORBA server associated to the engine. -If the engine is built from a pre-existent executable code, the library is simply a wrapper of the encapsulated code. -It launches the code in a separate process. Wherever possible, the code is included into the dynamic library. -

The container is one of the kernel services. If one needs to create a container on a distant machine, one creates a process resuming a part of the kernel services. The kernel can create other containers on distant machines via the trader (rsh). All the containers and the kernel share the same CORBA naming service with which they register.

The user reaches the functions of various SALOME'S components, either in graphic interactive mode (GUI) or in command mode ( TUI), via a Python interpreter.

-Back to the contents - -

3. Services and features of the SALOME kernel module

This section gives a brief overview of the services composing the kernel module. - The Life Cycle and Naming - services are described in separate chapters of this reference manual.

- -

3.1 Session service

SALOME session describes the period starting from the kernel creation and - ending with its destruction. During this period the user can connect the session - and disconnect from it without ending this session. One connection log could - be written. A priori, no information resulting from another (past) session can - be used by the current session.

Implementation of this service in SALOME application is provided by the class -Session encapsulated in the package -SALOME.

- -

3.2 Registry service

The active component registry should contain:

- -

The list of the active components
The list of the active containers during a SALOME session.

It should allow the state of a session. It also should allow to know if session can be stopped.

The API reference for this service is not included in the current version of the reference manual.

- -

3.3 Notification service

The notification service is a kernel function which allows exchanging of events between CORBA objects.

In comparison with traditional CORBA event service, SALOME notification service allows to:

Filter the events,
Structure the events,
Establish quality policies of services,
Subscribe to various event channels.

The API reference for this service is not included in the current version of the reference - manual.

- -

3.4 Module catalog service

There are two module catalogs in SALOME application:

General module catalog : This first catalog is common to all SALOME users once the the platform is installed (for example for a particular company or a service). This catalog will be managed by the integrator or the administrator of the platform, -
Personal module catalog : A specific catalog for every user (possibly empty). This catalog should notably allow the developers to test a new component before integrating it into the general catalog. -

The objective of these two module catalogs is to:

List the available modules; -
Allow the addition, the modification and the deletion of a module in catalogs; -
Look for a module and\or a service fulfilling some given criteria (in catalogs); -

Implementation of this service in SALOME application is provided by two classes -ModuleCatalogand AComponent encapsulated in the package -SALOME_ModuleCatalog.

- -

3.5 Data type catalog

- -

The data exchanged between components services have definite types. During description of input, output, and -configuration parameters of components in the module catalog, the -definition of the parameters types is taken from data type catalog. During the editing of execution of -graphs, it is necessary to check that the connections output-input parameters are of compatible -types.

The data types correspond to CORBA object classes, including attributes and access methods (defined by their IDL). -These types can be created by specialization of generic data types.

The purpose of the data type catalog is to:

List the available data types in the catalog; -
Browse the type hierarchy to check the compatibility of types (specialized output toward generic input); -
Allow the addition, the modification and the deletion of a data type in the catalog; -

The API reference for this service is not included in the current version of the reference - manual.

3.6 Resource catalog

- -

This catalog describes machines, possible types of container on a machine, resources of machines... This catalog is used by the SALOME LifeCycle service.

The API reference for this service is not included in the current version of the reference - manual.

- -

3.7 Engine

The engine represents a shared library which can be dynamically loaded by a container. The container can load this library, -given an interface name and an implementation -name. The container dynamically resolves an extern_C function in the library, -which constructs the CORBA Engine servant object.

The SALOME engine in - the current version of the application is implemented - as Engines package of interfaces. It encapsulates two classes: Component, Container.

The API refernce for Engines package can be found here. -

3.7.1 Component class

This class is used for interaction between the container and the component and between the components inside the container. -

The API reference for this class can be found here.

- -

3.7.2 Container class

This class provides a set of methods which are necessary for definition of the process of loading and registration of new components in SALOME application.

The API reference for this class can be found here.

- -Back to the contents - - + + + + + + Main Page + + + + + + + + + + + +

+ + +

General overview +

+ +
+
1. Introduction
+
2. Basic principles
+ +
3. Services and features of the SALOME kernel module
+
+
3.1 Session service
+
3.2 Registry service
+
3.3 Notification service
+
3.4 Module catalog service
+
3.5 Data type catalog
+
3.6 Resource catalog
+
3.7 Engine
+
+
3.7.1 Component class
+
3.7.2 Container class
+
+
+
+
+

1. Introduction

The kernel corresponds to the minimal set of services required for the use of SALOME components (Supervisor, IAPP). +The kernel is also used by application software components (solver) and their container. +The kernel is associated to a unique user who can launch only one kernel at once. +The kernel is launched and destroyed by voluntary actions of the user. These functions are realized via the +use of scripts.

The list of the kernel services related to communication issues is:

The Naming service
The Session service
The Life Cycle service
The Registry service
The Notification service

This list is enlarged with CORBA independent services :

+ +

The module catalog service
The Data Type Catalog service
The resource catalog service

SALOME kernel module also encapsulates the Engine +Back to the contents +

2. Basic principles

The SALOME user's desktop is a process on a machine. This process includes:

A graphic interface (based on Qt),
A text interface (Python interpreter),
A 3D visualization window shared by components.

SALOME Modules decompose into an interface (widgets GUI, text mode TUI, 3D visualization V3D) and +an engine.

The description of a module and its components is obtained by consulting the module catalog.

The interface is dynamically loaded in the process of the SALOME user's desktop. The engine is a CORBA +server launched either on the local machine or on the distant machine.

The engine (CORBA server) is created by a factory (or container). +This factory is also a CORBA server. Several containers can be present on a machine. +Some containers are specialized for types of components requiring a specific management. +For example, a specific container is required for components performing parallel calculations. +The engine includes at least a dynamically linked library in the container process. +This library is the implementation of the CORBA server associated to the engine. +If the engine is built from a pre-existent executable code, the library is simply a wrapper of the encapsulated code. +It launches the code in a separate process. Wherever possible, the code is included into the dynamic library. +

The user reaches the functions of various SALOME'S components, either in graphic interactive mode (GUI) or in command mode ( TUI), via a Python interpreter.

+Back to the contents + +

3. Services and features of the SALOME kernel module

This section gives a brief overview of the services composing the kernel module. + The Life Cycle and Naming + services are described in separate chapters of this reference manual.

+ +

3.1 Session service

SALOME session describes the period starting from the kernel creation and + ending with its destruction. During this period the user can connect the session + and disconnect from it without ending this session. One connection log could + be written. A priori, no information resulting from another (past) session can + be used by the current session.

Implementation of this service in SALOME application is provided by the class +Session encapsulated in the package +SALOME.

+ +

3.2 Registry service

The active component registry should contain:

+ +

The list of the active components
The list of the active containers during a SALOME session.

It should allow the state of a session. It also should allow to know if session can be stopped.

The API reference for this service is not included in the current version of the reference manual.

+ +

3.3 Notification service

The notification service is a kernel function which allows exchanging of events between CORBA objects.

In comparison with traditional CORBA event service, SALOME notification service allows to:

Filter the events,
Structure the events,
Establish quality policies of services,
Subscribe to various event channels.

The API reference for this service is not included in the current version of the reference + manual.

+ +

3.4 Module catalog service

There are two module catalogs in SALOME application:

General module catalog : This first catalog is common to all SALOME users once the the platform is installed (for example for a particular company or a service). This catalog will be managed by the integrator or the administrator of the platform, +
Personal module catalog : A specific catalog for every user (possibly empty). This catalog should notably allow the developers to test a new component before integrating it into the general catalog. +

The objective of these two module catalogs is to:

List the available modules; +
Allow the addition, the modification and the deletion of a module in catalogs; +
Look for a module and\or a service fulfilling some given criteria (in catalogs); +

Implementation of this service in SALOME application is provided by two classes +ModuleCatalogand AComponent encapsulated in the package +SALOME_ModuleCatalog.

+ +

3.5 Data type catalog

+ +

The data exchanged between components services have definite types. During description of input, output, and +configuration parameters of components in the module catalog, the +definition of the parameters types is taken from data type catalog. During the editing of execution of +graphs, it is necessary to check that the connections output-input parameters are of compatible +types.

The data types correspond to CORBA object classes, including attributes and access methods (defined by their IDL). +These types can be created by specialization of generic data types.

The purpose of the data type catalog is to:

List the available data types in the catalog; +
Browse the type hierarchy to check the compatibility of types (specialized output toward generic input); +
Allow the addition, the modification and the deletion of a data type in the catalog; +

The API reference for this service is not included in the current version of the reference + manual.

3.6 Resource catalog

+ +

This catalog describes machines, possible types of container on a machine, resources of machines... This catalog is used by the SALOME LifeCycle service.

The API reference for this service is not included in the current version of the reference + manual.

+ +

3.7 Engine

The engine represents a shared library which can be dynamically loaded by a container. The container can load this library, +given an interface name and an implementation +name. The container dynamically resolves an extern_C function in the library, +which constructs the CORBA Engine servant object.

The SALOME engine in + the current version of the application is implemented + as Engines package of interfaces. It encapsulates two classes: Component, Container.

The API refernce for Engines package can be found here. +

3.7.1 Component class

This class is used for interaction between the container and the component and between the components inside the container. +

The API reference for this class can be found here.

+ +

3.7.2 Container class

This class provides a set of methods which are necessary for definition of the process of loading and registration of new components in SALOME application.

The API reference for this class can be found here.

+ +Back to the contents + + diff --git a/doc/salome/tui/KERNEL/sources/static/overview_Life_Cycle.html b/doc/salome/tui/KERNEL/sources/static/overview_Life_Cycle.html index 659c2ab24..f1a1fb8af 100755 --- a/doc/salome/tui/KERNEL/sources/static/overview_Life_Cycle.html +++ b/doc/salome/tui/KERNEL/sources/static/overview_Life_Cycle.html @@ -1,90 +1,90 @@ - - - - - - Life Cycle service Description - - - - - - - - - - - - - - -

- - -

Life Cycle service Description

Introduction

The objective of this document is to give the users of SALOME - application a brief overview of the Life Cycle service implemented in SALOME. - A complete version of the LifeCycle service specification edited by the Object Management Group, Inc.(OMG) can be found here. -

- -
1. Overview
- - -
2. SALOME Life Cycle service description
-
-
- -

1. Overview

- -

Life Cycle service defines services and conventions for creating, deleting, copying and moving objects. -Because CORBA-based environments support distributed objects, the Life Cycle service defines conventions that allow clients to perform -life cycle operations on objects in different locations. This overview describes the life cycle problem for distributed object systems.

-
- - -

2. SALOME Life Cycle service description

The SALOME Life Cycle service represents a partial implementation of the CORBA LifeCycle service.

From general point of view, the SALOME Life Cycle service allows to find or load with the help of a given container a definte SALOME component with its further -initialization and registration in the Naming service.

Container - it's a certain engine realizing the mechanism of loading a SALOME module.

Component - it's a certain abstract shell wrapping SALOME modules, performing all operations concerned with their initialization and registration.

From the point of view of the service user, the Life Cycle provides a set of functions allowing to :

Locate a machine (more generally a container) by a logical set of required features (of both container and - machine);
Load components on the obtained containers;
Create a container;
Obtain the container containing a given component;
Treat the list of the active components;
Treat the list of the available containers.

- - - -

The SALOME Life Cycle is a CORBA server. This server at its initialization is registered with the naming service.

The Life Cycle service is invoked to find a container and use it to load a -component. It supplies, as parameters, the type of container and the machine features required for loading -a given component. -

The Life Cycle service then returns a CORBA reference of a launched container.

Containers are launched on demand depending on components to be loaded. The Life Cycle service manages loading of containers.

When there is no launched container matching the request the Life Cycle service invokes loading of the correct type of container on a correct machine via a rsh type command.

The Life Cycle service interrogates containers to have information about the dynamic state of the machine (load). It contains (and update) the state of the active containers.

The Life Cycle service can implement a loading strategy for new containers on new machines, depending on the state of the already launched containers.

The Life Cycle service can stop containers at the end of session on -demand.

- -

In SALOME platform the Life Cycle service is implemented in SALOME_Life CycleCORBA class. The API refernce for the methods of this class -can be found here.

-Back to the contents -
- - -
- - - + + + + + + Life Cycle service Description + + + + + + + + + + + + + + +

+ + +

Life Cycle service Description

Introduction

The objective of this document is to give the users of SALOME + application a brief overview of the Life Cycle service implemented in SALOME. + A complete version of the LifeCycle service specification edited by the Object Management Group, Inc.(OMG) can be found here. +

+ +
1. Overview
+ + +
2. SALOME Life Cycle service description
+
+
+ +

1. Overview

+ +

Life Cycle service defines services and conventions for creating, deleting, copying and moving objects. +Because CORBA-based environments support distributed objects, the Life Cycle service defines conventions that allow clients to perform +life cycle operations on objects in different locations. This overview describes the life cycle problem for distributed object systems.

+
+ + +

2. SALOME Life Cycle service description

The SALOME Life Cycle service represents a partial implementation of the CORBA LifeCycle service.

From general point of view, the SALOME Life Cycle service allows to find or load with the help of a given container a definte SALOME component with its further +initialization and registration in the Naming service.

Container - it's a certain engine realizing the mechanism of loading a SALOME module.

Component - it's a certain abstract shell wrapping SALOME modules, performing all operations concerned with their initialization and registration.

From the point of view of the service user, the Life Cycle provides a set of functions allowing to :

Locate a machine (more generally a container) by a logical set of required features (of both container and + machine);
Load components on the obtained containers;
Create a container;
Obtain the container containing a given component;
Treat the list of the active components;
Treat the list of the available containers.

+ + + +

The SALOME Life Cycle is a CORBA server. This server at its initialization is registered with the naming service.

The Life Cycle service is invoked to find a container and use it to load a +component. It supplies, as parameters, the type of container and the machine features required for loading +a given component. +

The Life Cycle service then returns a CORBA reference of a launched container.

Containers are launched on demand depending on components to be loaded. The Life Cycle service manages loading of containers.

When there is no launched container matching the request the Life Cycle service invokes loading of the correct type of container on a correct machine via a rsh type command.

The Life Cycle service interrogates containers to have information about the dynamic state of the machine (load). It contains (and update) the state of the active containers.

The Life Cycle service can implement a loading strategy for new containers on new machines, depending on the state of the already launched containers.

The Life Cycle service can stop containers at the end of session on +demand.

+ +

In SALOME platform the Life Cycle service is implemented in SALOME_Life CycleCORBA class. The API refernce for the methods of this class +can be found here.

+Back to the contents +
+ + +
+ + + diff --git a/doc/salome/tui/KERNEL/sources/static/overview_Naming.html b/doc/salome/tui/KERNEL/sources/static/overview_Naming.html index ae24ab54d..8af6b10ec 100755 --- a/doc/salome/tui/KERNEL/sources/static/overview_Naming.html +++ b/doc/salome/tui/KERNEL/sources/static/overview_Naming.html @@ -1,197 +1,197 @@ - - - - - - Naming Service Description - - - - - - - - - - - -

- - -

Naming Service Description

-
-

Introduction

This page contains an abridged version of the Naming Service specification - edited by the Object Management Group, Inc.(OMG). The objective of this document is to give the users of SALOME - application a brief overview of the Naming Service implemented in SALOME. - A complete version of this document can be found here. -

-
-

- -
-
1. Overview
-
2. SALOME Naming Service
-
-
2.1 Introduction
-
2.2 Definitions
-
2.3 Partition of SALOME name directory hierarchy
-
2.4 SALOME name directory persistence
-
2.5 SALOME naming service features
-
- -
-
- -

1. Overview

This chapter presents the OMG Naming Service and explains how the Naming Service can be used to decouple clients and servers by -providing an external reference exchange mechanism. The chapter also covers how to solve the bootstrapping problem for clients and -servers by controlling their configuration. -

- -

In practice, copying stringified references from a server to all its clients is clumsy and does not scale. The Naming Service provides a way -for servers to advertise references under a name, and for clients to retrieve them. The advantages are: -

Clients and servers can use meaningful names instead of having to deal with stringified references.
By changing a reference in the service without changing its name, you can transparently direct clients to a different object.
The Naming Service solves the bootstrapping problem because it provides a fixed point for clients and servers to rendezvous.

The Naming Service is much like a white pages phone book. Given a name, it - returns an object reference.

- -

The terminology used in description of NamigService is the following:

- -

A name-to-IOR association is called by a name binding.
Each binding identifies exactly one object reference, but an object reference - may be bound more than once (have more than one name).
A naming context is an object that contains name bindings. - The names within a context must be unique. Naming contexts can contain bindings - to other naming contexts, so naming contexts can form graphs. Binding contexts - in other contexts creates a naming graph a directed graph with nodes - and labeled edges where the nodes are contexts. A naming graph allows more - complex names to reference an object. Given a context in a naming graph, a - sequence of names can reference an object. This sequence of names (called - a compound name) defines a path in the naming graph to navigate the - resolution process. Figure 1-1 shows an example of a naming graph.
Binding a name to a context means to add a nameIOR pair to a context.
Resolving a name means to look for a name in a context and to obtain the - IOR bound under that name.

- - -

Figure 1-1 A Naming Graph

- Back to the contents -
- -

2. SALOME Naming Service

- -

2.1 Introduction

The SALOME Naming Service is a kernel function which supplies a name directory - hierarchy for pointing out CORBA objects. This name directory hierarchy allows, - from symbolic names, to dynamically find the references of distributed SALOME - objects, without information about their location. SALOME objects which can - be reached via the naming service are:

- -

The kernel services
Containers -
SALOME components instances -

The name directory hierarchy in SALOME represents a graph of directories containing - symbolic associations name-reference on objects. (It has been described in the - previous section)

- -

2.2 Definitions

Directory: Context of names containing symbolic associations name-reference on objects.
"/": Character used in SALOME to separate two names of a directory
Access path: List of names (separated by "/" character representing the path to be followed - in the graph to reach an association name-reference (the last name in the sequence).

Note:An object can be referenced by several symbolic names - in one or several directories.

- -

2.3 Partition of SALOME name directory hierarchy

The hierarchical organization of the SALOME name directory is not completely frozen . -Because the framework allows the simultaneous opening of several studies, the following levels are determined:

 
- /Kernel
- /Container/
-	       /Component	
-

- -

2.4 SALOME name directory persistence

During a SALOME session, stopping a server in charge of the Naming Service - doesn't imply the loss of the contents of the SALOME name directory hierarchy. - A backup file is produced and can be used to restart the Naming Service. So, - one can recover the state of the SALOME name directory hierarchy at restart - time. During such breakdown, every call to any function of the Naming Service - invokes an exception of type Unreachable service.

- -

2.5 SALOME Naming Service features

Usage and administration of the name directory hierarchy is realized by means of the following functions:

Recording and recovering of the reference of an object
Searching for a symbolic name
Creating of a directory, reading and modifying of the current directory
Destructing of a symbolic name and a diredtory

The access path used in these functions can be defined, either from the root, or from any -directory of SALOME name directory hierarchy.

- -

In SALOME there is s standard interface of Naming Service, and any user can - use it for binding and finding objects. How to use it, it's possible to find - in any CORBA documentation. However in SALOME there is an additional layer which - hides calls to standard interface.

The precise API reference for these functions you can find here.

Here is a short list of public methods which are used for working with the SALOME Naming Service:

Register: Method which register object reference in the naming service with given name. It makes assignment between IOR and stringified name. -Then it's possible to get object reference from name using "Resolve" method.
Resolve: Try to obtain object reference from name. It's necessary before publishing - IOR in the Naming Service by Register method.
Find: The purpose of this method is to research a name from the current directory - of the naming service. Then if there is occurrence the naming service changes - directory to go to the directory where last occurrence is found.
CreateDirectory: This method allows to create one or several directories in the current directory
ChangeDirectory: Moves the current directory. The current directory is moved to the root directory if the input parameter Name is "/".
CurrentDirectory: Method allowing to get the current directory.
list: Method allowing to list and print the whole context beginning from the current context.
list_directory: Method to get all contexts contained in the current directory.
DestroyName: Destroys a symbolic name-object reference association.
DestroyDirectory: Destroys an empty directory.

- -Back to the contents -
- - + + + + + + Naming Service Description + + + + + + + + + + + +

+ + +

Naming Service Description

+
+

Introduction

This page contains an abridged version of the Naming Service specification + edited by the Object Management Group, Inc.(OMG). The objective of this document is to give the users of SALOME + application a brief overview of the Naming Service implemented in SALOME. + A complete version of this document can be found here. +

+
+

+ +
+
1. Overview
+
2. SALOME Naming Service
+
+
2.1 Introduction
+
2.2 Definitions
+
2.3 Partition of SALOME name directory hierarchy
+
2.4 SALOME name directory persistence
+
2.5 SALOME naming service features
+
+ +
+
+ +

1. Overview

This chapter presents the OMG Naming Service and explains how the Naming Service can be used to decouple clients and servers by +providing an external reference exchange mechanism. The chapter also covers how to solve the bootstrapping problem for clients and +servers by controlling their configuration. +

+ +

In practice, copying stringified references from a server to all its clients is clumsy and does not scale. The Naming Service provides a way +for servers to advertise references under a name, and for clients to retrieve them. The advantages are: +

Clients and servers can use meaningful names instead of having to deal with stringified references.
By changing a reference in the service without changing its name, you can transparently direct clients to a different object.
The Naming Service solves the bootstrapping problem because it provides a fixed point for clients and servers to rendezvous.

The Naming Service is much like a white pages phone book. Given a name, it + returns an object reference.

+ +

The terminology used in description of NamigService is the following:

+ +

A name-to-IOR association is called by a name binding.
Each binding identifies exactly one object reference, but an object reference + may be bound more than once (have more than one name).
A naming context is an object that contains name bindings. + The names within a context must be unique. Naming contexts can contain bindings + to other naming contexts, so naming contexts can form graphs. Binding contexts + in other contexts creates a naming graph a directed graph with nodes + and labeled edges where the nodes are contexts. A naming graph allows more + complex names to reference an object. Given a context in a naming graph, a + sequence of names can reference an object. This sequence of names (called + a compound name) defines a path in the naming graph to navigate the + resolution process. Figure 1-1 shows an example of a naming graph.
Binding a name to a context means to add a nameIOR pair to a context.
Resolving a name means to look for a name in a context and to obtain the + IOR bound under that name.

+ + +

Figure 1-1 A Naming Graph

+ Back to the contents +
+ +

2. SALOME Naming Service

+ +

2.1 Introduction

The SALOME Naming Service is a kernel function which supplies a name directory + hierarchy for pointing out CORBA objects. This name directory hierarchy allows, + from symbolic names, to dynamically find the references of distributed SALOME + objects, without information about their location. SALOME objects which can + be reached via the naming service are:

+ +

The kernel services
Containers +
SALOME components instances +

The name directory hierarchy in SALOME represents a graph of directories containing + symbolic associations name-reference on objects. (It has been described in the + previous section)

+ +

2.2 Definitions

Directory: Context of names containing symbolic associations name-reference on objects.
"/": Character used in SALOME to separate two names of a directory
Access path: List of names (separated by "/" character representing the path to be followed + in the graph to reach an association name-reference (the last name in the sequence).

Note:An object can be referenced by several symbolic names + in one or several directories.

+ +

2.3 Partition of SALOME name directory hierarchy

The hierarchical organization of the SALOME name directory is not completely frozen . +Because the framework allows the simultaneous opening of several studies, the following levels are determined:

 
+ /Kernel
+ /Container/
+	       /Component	
+

+ +

2.4 SALOME name directory persistence

During a SALOME session, stopping a server in charge of the Naming Service + doesn't imply the loss of the contents of the SALOME name directory hierarchy. + A backup file is produced and can be used to restart the Naming Service. So, + one can recover the state of the SALOME name directory hierarchy at restart + time. During such breakdown, every call to any function of the Naming Service + invokes an exception of type Unreachable service.

+ +

2.5 SALOME Naming Service features

Usage and administration of the name directory hierarchy is realized by means of the following functions:

Recording and recovering of the reference of an object
Searching for a symbolic name
Creating of a directory, reading and modifying of the current directory
Destructing of a symbolic name and a diredtory

The access path used in these functions can be defined, either from the root, or from any +directory of SALOME name directory hierarchy.

+ +

In SALOME there is s standard interface of Naming Service, and any user can + use it for binding and finding objects. How to use it, it's possible to find + in any CORBA documentation. However in SALOME there is an additional layer which + hides calls to standard interface.

The precise API reference for these functions you can find here.

Here is a short list of public methods which are used for working with the SALOME Naming Service:

Register: Method which register object reference in the naming service with given name. It makes assignment between IOR and stringified name. +Then it's possible to get object reference from name using "Resolve" method.
Resolve: Try to obtain object reference from name. It's necessary before publishing + IOR in the Naming Service by Register method.
Find: The purpose of this method is to research a name from the current directory + of the naming service. Then if there is occurrence the naming service changes + directory to go to the directory where last occurrence is found.
CreateDirectory: This method allows to create one or several directories in the current directory
ChangeDirectory: Moves the current directory. The current directory is moved to the root directory if the input parameter Name is "/".
CurrentDirectory: Method allowing to get the current directory.
list: Method allowing to list and print the whole context beginning from the current context.
list_directory: Method to get all contexts contained in the current directory.
DestroyName: Destroys a symbolic name-object reference association.
DestroyDirectory: Destroys an empty directory.

+ +Back to the contents +
+ + diff --git a/doc/salome/tui/KERNEL/sources/static/overview_Study.html b/doc/salome/tui/KERNEL/sources/static/overview_Study.html index f4c278363..0526536e9 100755 --- a/doc/salome/tui/KERNEL/sources/static/overview_Study.html +++ b/doc/salome/tui/KERNEL/sources/static/overview_Study.html @@ -1,261 +1,261 @@ - - - - - - Main Page - - - - - - - - - - - -

- - -

General overview -

-
-

1. Introduction
2. Representation of the study

2.1 Study in transient format
2.2 Study in persistent format
2.3 Link between transient and persistent formats

3. Services and features of the study

3.1 Study class
3.2 StudyBuilder class
3.3 StudyManager class
3.4 SObject class
3.5 SComponent class
3.6 ChildIterator class
3.7 SComponentIterator
3.8 GenericAttribute class
3.9 UseCaseBuilder class
3.10 UseCaseIterator
3.11 Callback class
3.12 Driver class

1. Introduction

In SALOME application the Study module is used for management (creation, saving - etc.) of studies. In the framework of the platform, a study represents a working - document allowing to manage the data produced by various components which are - integarted into SALOME.
-

2. Representation of the study

The study represents a set of objects that we will call Study Objects or SObjects. - The study can be represented as a tree, every node of that tree containing a - SObject. SObjects in the study can be values or references towards data of calculation, - graphs of calculation, trees of construction of detail(room), results. Every - SOject of the study is characterised by a unique identifier in the study.

The study allows to describe the following relations:

The link between the transient and persistent values of an SObject.
The relations between the SObjects produced by different components.
The relations between the SObjects produced by the same component.
The link between an object and its user name.
The access to the definition of the component which produce an object of - the study.
The access to instance of the component (if this one exists) which has produced - this SObject of the study.

- -

Every SObject in the study contains a set of attributes. These attributes represent - a set of definitions associated to that object, they can contain values or corba - references towards the data contained in the internal data structure of a component.

As the structure of the study is tree-like it is possible to associate sub-objects - to objects.

As particular object, the study contains Component Data which are labels associated to the component -which produce data in the study. It is to this object that we can associate attributes containing ID which -we shall allow to identify the type of the component and also its instance. Objects produced by a -component will be sub-objects of the coresponding Data Component.

For example Component Data GEOM will contain the data produced by the component - Geom.

- - - - - -

GEOM contains the data produced by the component GEOM. The component MESH - contains a SObject Mesh_1 wich refers to the SObject identified - by ID4 corresponding to Geometrie_1.

We distinguish two forms of the study, the study opened in a session SALOME and the study in the -persistent format. These two formats are described in the following sections

2.1 Study in transient format

The representation of the study in memory will be based on the document OCAF (supplied by OCC). -The document OCAF can be seen as a tree, every node of that tree is identified by a tag representing an integer value.

The exploration of the tree from the root to a node supplies a sequence of tags which establishes a -unique identifier ID. ID represents a character string containing the sequence of tags separated by -one ':'.

For example 0:1:12:4

To every node we can associate a set of attributes.

The attributes which the study can contain can be of the following types:

All standard attributes supplied by OCC (package TdataStd) which allow to define (integers, -real, strings, identifiers, references etc.)
Attributes which contain CORBA references.
Attributes which contain the path HDF to reach the persistent datum. (Cf. the following chapter)

Remark: it is the study which takes care to build the attributes from the values which are passed to it, so -an attribute is always in a study, and it knows the study object to which it is attached.

Example of a Study Object as a set of various attributes.

2.2 Study in persistent format

To store a study HDF format is used, this tool allows to represent persistent data in the form of a tree.

Under the root of the persistent document, you can find a set of nodes:

The first node contains the skeleton of the study. The skeleton consists of the identifiers of the -objects, as well as the references among them.
There is also one node for every component which has produced data during this SALOME session. Under each of these -node there are values of the data produced by this component.

2.3 Link between transient and persistent formats

It will be possible to complete the definition of one object in the study by associating to it an attribute -HDFPath which will contain the path to the persistent data.

Back to the contents

3. Services and features of the study

The Study in SALOME application possess a wide functionality. This functionality is provided by a set of classes which are described -below. -

3.1 Study class

The purpose of the Study class is to manage the data produced by various components - of SALOME platform. Most of the Study operations are handled by the StudyManager - and the StudyBuilder. What - is left in the Study class are elementary inquiries. A Study is explored by - a set of tools, mainly iterators , which are described further.

Nevertheless, the Study class contains a set of methods providing:

- -

management of study properties -
search for SObjects. -
search for SComponents -
creation of a new StudyBuilder, ComponentIterator, ChildIterator etc. -

The API reference for this class can be found here.

3.2 StudyBuilder class

StudyBuilder supplies basic services to edit the study. The edition of the study is made by the -component. Every component will use the basic services of the StudyBuilder allowing to write and publish objects.

StudyBulder provides the following functionality:

creation, modification or deletetion of SObjects in the study
creation or removal of SComponents
undo/redo functionality. For that purpose it supplies the methods NewCommand, - CommitCommand, AbortCommand.

The API reference for this class can be found here.

3.3 StudyManager class

The purpose of the Manager is to manipulate Studies. Since SALOME is a multi-document - application during a working session you can operate as many stadies as you - wishes to create.

For that purpose StudyManager provides the following functionality:

creation, opening, closing and saving studies
navigation through a set of studies present in the current working session
copy/paste of the objects in the study functionality.

The API reference for this class can be found here.

3.4 SObject class

The objects in the study are built by the StudyBuilder. -The SObject class provides methods for elementary inquiries, like getting an object ID or its attribuites.

The API reference for this class can be found here.

3.5 SComponent class

The SComponent class establishes in the study a permanent assocition to the components -integrated into SALOME platform. The SComponent interface is a specialization of the SObject - class. It inherits the most of its methods from the SObject class which are used for management of the SComponents.

The API reference for this class can be found here.

3.6 ChildIterator class

It is one of the tools destined for exploration of the study. This class contains a set of methods allowing to get -the access to all identified objects which are sons of another identifiedobject.

The API reference for this class can be found here.

3.7 SComponentIterator

This is the second tool destined for exploration of the study. This interface contains the methods allowing to iterate over all SComponents in the list. - The search is started from the first SComponent in the list.

The API reference for this class can be found here.

- -

3.8 GenericAttribute class

GenericAttribute represents a base class for all attributes which can be assigned to the SObjects created in the study. All attribute classes - derive from this classe and inherit its methods.

The API reference for this class can be found here.

- -

In SALOME application a SObject can possess the following attributes:

- - - - - -

3.9 UseCaseBuilder class

UseCase in the study represents a user-defined subtree, containing all or some of the objects which currently exist -in the study. The UseCaseBuilder class contains a set of methods used for management (creation, deletion etc) of this sub-tree in the study.

The API reference for this class can be found here.

- -

3.10 UseCaseIterator

This class represents an exploration tool for the UseCase. It contains a set of methods used for iteration over the objects in the UseCase.

The API reference for this class can be found here.

- -

3.11 Callback class

The StudyBuilder can be created with the method NewBuilder. While invocation of this method a new object of the class - Callback is created and this object is assigned to the newly created Builder as callback which should be called - when adding and removing the objects.

The API reference for this class can be found here.

- -

3.12 Driver class

- -

This class represents a common tool for all components integrated into SALOME - application, that allows them to communicate with the study. It contains a set - of methods which can be called by any component and which provide the following - functionality: -

publishing in the study of the objects created by a definite component
saving/loading of the data created by a definite component. These methods - are called by the StudyManager when loading/saving a study containing the - data created by a definite component.
transforming of the transient references into persistant references (or - vice versa) of the SObjects when saving (or loading) a study
copy/paste common functionality. These methods can be called by any component - in order to copy/paste its object created in the study

The API reference for this class can be found here.

Back to the contents

- - + + + + + + Main Page + + + + + + + + + + + +

+ + +

General overview +

+
+

1. Introduction
2. Representation of the study

2.1 Study in transient format
2.2 Study in persistent format
2.3 Link between transient and persistent formats

3. Services and features of the study

3.1 Study class
3.2 StudyBuilder class
3.3 StudyManager class
3.4 SObject class
3.5 SComponent class
3.6 ChildIterator class
3.7 SComponentIterator
3.8 GenericAttribute class
3.9 UseCaseBuilder class
3.10 UseCaseIterator
3.11 Callback class
3.12 Driver class

1. Introduction

In SALOME application the Study module is used for management (creation, saving + etc.) of studies. In the framework of the platform, a study represents a working + document allowing to manage the data produced by various components which are + integarted into SALOME.
+

2. Representation of the study

The study represents a set of objects that we will call Study Objects or SObjects. + The study can be represented as a tree, every node of that tree containing a + SObject. SObjects in the study can be values or references towards data of calculation, + graphs of calculation, trees of construction of detail(room), results. Every + SOject of the study is characterised by a unique identifier in the study.

The study allows to describe the following relations:

The link between the transient and persistent values of an SObject.
The relations between the SObjects produced by different components.
The relations between the SObjects produced by the same component.
The link between an object and its user name.
The access to the definition of the component which produce an object of + the study.
The access to instance of the component (if this one exists) which has produced + this SObject of the study.

+ +

Every SObject in the study contains a set of attributes. These attributes represent + a set of definitions associated to that object, they can contain values or corba + references towards the data contained in the internal data structure of a component.

As the structure of the study is tree-like it is possible to associate sub-objects + to objects.

As particular object, the study contains Component Data which are labels associated to the component +which produce data in the study. It is to this object that we can associate attributes containing ID which +we shall allow to identify the type of the component and also its instance. Objects produced by a +component will be sub-objects of the coresponding Data Component.

For example Component Data GEOM will contain the data produced by the component + Geom.

+ + + + + +

GEOM contains the data produced by the component GEOM. The component MESH + contains a SObject Mesh_1 wich refers to the SObject identified + by ID4 corresponding to Geometrie_1.

We distinguish two forms of the study, the study opened in a session SALOME and the study in the +persistent format. These two formats are described in the following sections

2.1 Study in transient format

The representation of the study in memory will be based on the document OCAF (supplied by OCC). +The document OCAF can be seen as a tree, every node of that tree is identified by a tag representing an integer value.

The exploration of the tree from the root to a node supplies a sequence of tags which establishes a +unique identifier ID. ID represents a character string containing the sequence of tags separated by +one ':'.

For example 0:1:12:4

To every node we can associate a set of attributes.

The attributes which the study can contain can be of the following types:

All standard attributes supplied by OCC (package TdataStd) which allow to define (integers, +real, strings, identifiers, references etc.)
Attributes which contain CORBA references.
Attributes which contain the path HDF to reach the persistent datum. (Cf. the following chapter)

Remark: it is the study which takes care to build the attributes from the values which are passed to it, so +an attribute is always in a study, and it knows the study object to which it is attached.

Example of a Study Object as a set of various attributes.

2.2 Study in persistent format

To store a study HDF format is used, this tool allows to represent persistent data in the form of a tree.

Under the root of the persistent document, you can find a set of nodes:

The first node contains the skeleton of the study. The skeleton consists of the identifiers of the +objects, as well as the references among them.
There is also one node for every component which has produced data during this SALOME session. Under each of these +node there are values of the data produced by this component.

2.3 Link between transient and persistent formats

It will be possible to complete the definition of one object in the study by associating to it an attribute +HDFPath which will contain the path to the persistent data.

Back to the contents

3. Services and features of the study

The Study in SALOME application possess a wide functionality. This functionality is provided by a set of classes which are described +below. +

3.1 Study class

The purpose of the Study class is to manage the data produced by various components + of SALOME platform. Most of the Study operations are handled by the StudyManager + and the StudyBuilder. What + is left in the Study class are elementary inquiries. A Study is explored by + a set of tools, mainly iterators , which are described further.

Nevertheless, the Study class contains a set of methods providing:

+ +

management of study properties +
search for SObjects. +
search for SComponents +
creation of a new StudyBuilder, ComponentIterator, ChildIterator etc. +

The API reference for this class can be found here.

3.2 StudyBuilder class

StudyBuilder supplies basic services to edit the study. The edition of the study is made by the +component. Every component will use the basic services of the StudyBuilder allowing to write and publish objects.

StudyBulder provides the following functionality:

creation, modification or deletetion of SObjects in the study
creation or removal of SComponents
undo/redo functionality. For that purpose it supplies the methods NewCommand, + CommitCommand, AbortCommand.

The API reference for this class can be found here.

3.3 StudyManager class

The purpose of the Manager is to manipulate Studies. Since SALOME is a multi-document + application during a working session you can operate as many stadies as you + wishes to create.

For that purpose StudyManager provides the following functionality:

creation, opening, closing and saving studies
navigation through a set of studies present in the current working session
copy/paste of the objects in the study functionality.

The API reference for this class can be found here.

3.4 SObject class

The objects in the study are built by the StudyBuilder. +The SObject class provides methods for elementary inquiries, like getting an object ID or its attribuites.

The API reference for this class can be found here.

3.5 SComponent class

The SComponent class establishes in the study a permanent assocition to the components +integrated into SALOME platform. The SComponent interface is a specialization of the SObject + class. It inherits the most of its methods from the SObject class which are used for management of the SComponents.

The API reference for this class can be found here.

3.6 ChildIterator class

It is one of the tools destined for exploration of the study. This class contains a set of methods allowing to get +the access to all identified objects which are sons of another identifiedobject.

The API reference for this class can be found here.

3.7 SComponentIterator

This is the second tool destined for exploration of the study. This interface contains the methods allowing to iterate over all SComponents in the list. + The search is started from the first SComponent in the list.

The API reference for this class can be found here.

+ +

3.8 GenericAttribute class

GenericAttribute represents a base class for all attributes which can be assigned to the SObjects created in the study. All attribute classes + derive from this classe and inherit its methods.

The API reference for this class can be found here.

+ +

In SALOME application a SObject can possess the following attributes:

+ + + + + +

3.9 UseCaseBuilder class

UseCase in the study represents a user-defined subtree, containing all or some of the objects which currently exist +in the study. The UseCaseBuilder class contains a set of methods used for management (creation, deletion etc) of this sub-tree in the study.

The API reference for this class can be found here.

+ +

3.10 UseCaseIterator

This class represents an exploration tool for the UseCase. It contains a set of methods used for iteration over the objects in the UseCase.

The API reference for this class can be found here.

+ +

3.11 Callback class

The StudyBuilder can be created with the method NewBuilder. While invocation of this method a new object of the class + Callback is created and this object is assigned to the newly created Builder as callback which should be called + when adding and removing the objects.

The API reference for this class can be found here.

+ +

3.12 Driver class

+ +

This class represents a common tool for all components integrated into SALOME + application, that allows them to communicate with the study. It contains a set + of methods which can be called by any component and which provide the following + functionality: +

publishing in the study of the objects created by a definite component
saving/loading of the data created by a definite component. These methods + are called by the StudyManager when loading/saving a study containing the + data created by a definite component.
transforming of the transient references into persistant references (or + vice versa) of the SObjects when saving (or loading) a study
copy/paste common functionality. These methods can be called by any component + in order to copy/paste its object created in the study

The API reference for this class can be found here.

Back to the contents

+ +

-Mapping of IDL definitions to Python language.

-Introduction

-Using Scoped Names

-Mapping for Template and Array Types

-Mapping for Objects and Operations

-Narrowing Object References

-Mapping for Exceptions

-Mapping for Enumeration Types

-Mapping for Structured Types

+Mapping of IDL definitions to Python language.

+Introduction

+Using Scoped Names

+Mapping for Template and Array Types

+Mapping for Objects and Operations

+Narrowing Object References

+Mapping for Exceptions

+Mapping for Enumeration Types

+Mapping for Structured Types

General overview -

Table of contents

1. Introduction

2. Basic principles

3. Services and features of the SALOME kernel module

3.1 Session service

3.2 Registry service

3.3 Notification service

3.4 Module catalog service

3.5 Data type catalog

3.6 Resource catalog

3.7 Engine

3.7.1 Component class

3.7.2 Container class

General overview +

Table of contents

1. Introduction

2. Basic principles

3. Services and features of the SALOME kernel module

3.1 Session service

3.2 Registry service

3.3 Notification service

3.4 Module catalog service

3.5 Data type catalog

3.6 Resource catalog

3.7 Engine

3.7.1 Component class

3.7.2 Container class

Introduction

Table of contents

1. Overview

2. SALOME Life Cycle service description

Introduction

Table of contents

1. Overview

2. SALOME Life Cycle service description

Introduction

Table of contents

1. Overview

2. SALOME Naming Service

2.1 Introduction

2.2 Definitions

2.3 Partition of SALOME name directory hierarchy

2.4 SALOME name directory persistence

2.5 SALOME Naming Service features

Register

Resolve

Find

CreateDirectory

ChangeDirectory

CurrentDirectory

list

list_directory

DestroyName

DestroyDirectory

Introduction

Table of contents

1. Overview

2. SALOME Naming Service

2.1 Introduction

2.2 Definitions

2.3 Partition of SALOME name directory hierarchy