Function Services

> Hi All,

Hi Fabrizio!

> I`m trying to use and understand OCAF, in
> particular Function Service. I'd like to
> know if there are some examples besides that
> provided from Open CAS.CADE.

I'm not sure that there are some other examples of OCAF, but I could devise some examples for You. It's possible to describe an algorithm of OCAF usage (and Function Services in particular) for a determined case. Please, could You describe Your task more detailed?

My issue is
> about to use Function Services. Let me
> explain, for example the TFunction_Loobook
> allow to set the Label to impacted, touched
> and valid. How/Where/When do I manage this
> information? In Ocaf example (provided by
> OpenCascade) the Valid is never use; Why?

The class Logbook from TFunction package is used to store information about functions execution plus gathering a map of valid labels for naming mechanism. How does it work? In the function driver in the method Execute() You should set all the data modified by the function as impacted. The impacted labels are used in the method MustExecute() of the next function. In this method the next function checks if its arguments are modified (its arguments are touched or impacted). If yes, it calls the method Execute() of this function, otherwise, it does nothing and the process of a function list iteration turns to the next function. What is the difference between the touched and impacted labels? The touched labels are the labels modified by a user (interactively) or by an external application. The impacted labels are the labels modified by a function. I wrote about modified labels, but it is not correct: it would be better to speak about modification of attributes attached to the labels. So, let's gather all the things together. An application has some data. This data should be presented as attributes attached to the labels. An application has some functionalities. These functionalities should be represented as functions (every function is an attribute too) attached to the labels. Each function has arguments - the data located in the attributes attached to the labels. Each function has a result - a data located in attributes attached to the labels. So, every function has arguments and a result located somewhere in the data structure (a data structure means a label tree). Every function should have a function driver. This driver should know where the arguments are located and where to put the result after computation. So, every driver has such methods like MustExecute() and Execute(). The first one makes a decision about the necessity of the function execution (by means of looking for a modified argument of the function in the Logbook). The second method (Execute()) runs the algorithm of the function, but before it collects the arguments located somewhere in the data structure. Just the computation is done, the method Execute() should set the result into the data structure and it sets the result label impacted into the Logbook. The impacted labels will be analyzed in the method MustExecute() of the next function driver.

Let's consider the function mechanism more complex. The application functionality should be represented by functions in the data structure. Only the developper of the application knows the sequence of the function executions. Based on this knowledge it is possible to construct a list of functions. It is possible to use TreeNode class from TDataStd to construct this list (tree), or to create this list any other way.

Some advises: The arguments of a function it would be better to locate under the function label (the label where the function attribute is attached). The result it is possible to located at the function label itself.

> If assume that I write a Function, and
> therefore a Driver, for each node in OCAF
> tree (Simple or complex my way) are TreeNode
> useful again?

Certainly, the class TreeNode is an attribute creating an editable tree. It may be used independantly on the Function Services of OCAF. This class helps us to iterate the tree of nodes for producing a list of functions.

> Is it right so to speak that TreeNode
> rapresents a logical group (of entity) of
> tree's OCAF node that describe for instance
> a Box? And if I want apply a Algorithm to
> Box Rather than at each side or face, Does
> treeNode to make easier this task?

If You consider a box as it is, You should set a TreeNode attribute located at the Box label. If You would like to consider the faces of the box too, it would be better to set TreeNode attributes located at the faces of the Box too.

> Thanks Fabrizio

Best Regards,

Vlad