cancel
Showing results for 
Search instead for 
Did you mean: 

Context copy

Former Member
0 Kudos

Hi,

I am interested whether there is possibility to copy part of the view context at once. For example if I have the following structure:

+ node1

   - attribute1

   - attribute2

   + subnode11

      - attribute11

      - attribute12

      + subnode12

         - attribute121

I would like to copy the information contained in subnode11 and the attributes and nodes below it and do some work with this part of the context but I don't want to change the original.

Is this possible?

Regards,

Metodi

Accepted Solutions (0)

Answers (1)

Answers (1)

Former Member
0 Kudos

Hello Methodi,

Yes, this works. Just do a right mouse click on subnode11, choose "Copy" from the context menu. Then position the cursor on the node you want to add a copy of subnode11 as child node, do a right mouse-click and choose paste from the context menu.

Best regards,

Karin

Former Member
0 Kudos

Hi Karin,

thank you for the answer:) I forgot to write that I am interested to do this programatically not manually. The question is how can I do this on run time?

Regards,

Metodi

Former Member
0 Kudos

Hi Metodi,

Unfortunately this feature is not available during runtime.

Regards,

Karin

Former Member
0 Kudos

Hi Karin,

    Lets forget copying the complete context tree programmatically.

    Can you tell me how do we search this tree assuming a search criterion

     eg. Search corresponding lead selection path for attribute121 = "someconstantstring"

     whats i mean to say is given a search criteria how do we go about programmatically scan nodes and attributes at the given 3 levels i.e. node1, subnode11 and subnode12 .

   it would be great if you can give us a small code segment explaining this.

   After all not all the tasks can be accomplished with getCurrentXYZElement() kind of function.

.V

Former Member
0 Kudos

Hi Jake,

Of course it is perfectly possible to write code that performs a recursive scan of the context hierarchy, but could you please explain why this functionality is needed?

Normally, a context hierarchy should be constructed such that you know at least the name of the node collection in which the target attribute can be found.  Therefore, if a search is required, then you only need loop around the elements of a single node collection to locate the required attribute value.

If you could give some more details about the business functionality you are implementing, then it will make providing a code sample much easier.

Best regards,

Karin

Former Member
0 Kudos

Karin,

   Appreciate your prompt response.

   Lets take the example given above.

   Now assume that the value stored in the attribute121 is an integer and there is a 0..n kind of cardinality between node1 , subnode11, subnode12. Hence there would be a collection of node1 type of elements under which there will be a collection of subnode11 type of elements under which there would be a collection of subnode12 type of elements corresponding to the context tree above.

    Now the webdynpro app needs to find out what is the maximum possible value of attribute121

throughout the tree and once that maximum value is found what are the corresponding values in the lead selection path i.e. With respect to the maximum value of attribute121 what is the corresponding set of values for the following         

                                          node1-attribute1 (level 1 attribute)

                                          node1-attribute2 (level 1 attribute)

                                          subnode11-attribute11 (level 2 attribute)

                                          subnode11-attribute12 (level 2 attribute)

                                          subnode12-attribute121 (level 3 attribute)

   To accomplish this i have no way but to write a search algorithm which loops thru all the nodes at all levels. (i am doing this but it would be good if you could provide me with a sample code segment just to make sure i am doing the write thing).

    This further means that while scanning thru the tree, i got to make the node1 point to the exact element (based on the index of my loop counter for level 1) and once node1 points to a particular element, i then have to make subnode11 point to the exact element(based on the index of my loop counter for level 2)... and so on.. to scan all elements.

      please tell me whether the search algorithm given above is the best way or is there any other way to do this. Even if this is not the best way it would be great if you can show me a simple code segment doing the search as given above since i need to make sure whether i am doing thre right things or not.

.V

Former Member
0 Kudos

Hi Jake

Thank you for explaining your abstract situation, but your business requirements are still not clear.

It also appears that there is a slight misunderstanding about the nature of the context at runtime.  Please allow me to explain. There are various fundamental concepts that must first be understood in order to use the context correctly:

The following explanation is made in reference to the diagram that can be found in this document

http://sapmats-de.sap-ag.de/download/download.cgi?id=TCECZKZ9QZXLHYT0R0M8KJEIHLNZITH8XTZC09A73GO536C...

The structure of the context defined at design time should be thought of as a "flat" hierarchy - that is, a two dimensional hierarchy possessing no depth.

However, at runtime, the flat context hierarchy seen at design time will now take on a third dimension of depth

Principles concerning the context

1) All nodes are collections.

2) The attributes and child nodes of any given node are aggregated together into a unit known as an element.  A node is a collection of such elements.

3) The cardinality property of a node controls the maximum and minimum number of elements a node collection may contain at runtime.

a.The first part of the cardinality value determines the number of elements the node will contain when the context is initialised.

b.The second part of the cardinality value determines the maximum numbers of elements the node may contain.

c.Therefore, a node with a cardinality of 0..1 starts off empty, and may contain no more than one element.  A node of cardinality 1..n, starts off with one empty element, and may contain as many elements as required.

d.Nodes that have a cardinality of 1..1 or 1..n will always have element 0 in their collection.  This element is known as the default element, and is coloured yellow in the diagram.

e.When iterating around the elements in a node collection, the currently selected element can be obtained by referencing the element at the "Lead Selection".  This element is coloured red on the diagram.

4) The singleton flag controls the relationship between a child node and its parent.  The default value for the singleton flag is true.

a.If a child node is a singleton with respect to its parent, then this means that no matter how many elements the parent node has, there will only ever be one instance of the child node.

b.In order to access the contents of a singleton child node, the lead selection of the parent node must first point to the correct element.  Then the contents of the child node will be determined automatically when any of the node's accessor methods are called.

c.If a child node is a non-singleton with respect to its parent, then for each element in the parent node collection, there will be a separate instance of the child node.  In this situation, the contents of a child node can be directly referenced without needing to reposition the lead selection of the parent node.

Do you have an actual business requirement? If yes, please let us know. That would help us understand what you are trying to achieve, and therefore provide you with the best solution.

Regards,

Karin

Former Member
0 Kudos

Dear Karin,

     With respect to your 4th point above, let me mention the fact that i am using Singleton nodes always and this is because all nodes as by default singleton in nature. Due to this fact i have always been using the positioning technique where by the exact element at a particular parent node should be made as the lead selection element and only then the data under it's child node would be the corresponding collection of elements for that particular element selected in the parent node. I perfectly understand this and i am fine with making the relevant elements under all parent nodes at all levels above the child node as the current elements as appropriate.

correct me if i am wrong.

But although nodes might be singleton at all levels it does not make much difference except for the fact that right positioning needs to be done at all levels above. But the no of elements at all levels remain the same regardless of whether we use the singleton node or non singleton node.

Eg.  Assume a design time context as follows

Context

    +GreatGrandFather

         - eyecolor

         - height

         + GrandFather

             - name

             - address

             + Father

                 - name

                 - address

                 + Son

                      - name

                      - address

For which the runtime data is as follows

+GreatGrandFather1

       - eyecolor

       - height

       + Grandfather11

       + Grandfather12

          - name

          - address

          + Father 121

          + Father 122

          + Father 123

                 - name

                 - address

                 + Son1231

                 + Son1232

                 + Son1233

                 + Son1234

                       - name (='john')

                       - address

Now lets say if all the nodes were SINGLETON,

-

-


    In that case in order to access a Son by the name "john" throughout the family tree, i would

   i would have to make sure

     i) the GreatGrandFather node points to the GreatGrandFather1

                       wdContext.nodeGreatGrandFather().setLeadSelection(0); --> 1st greatgrandfather

     ii) the GrandFather node point to the GrandFather12

                       wdContext.nodeGrandFather().setLeadSelection(1); --> 2nd grandfather

     iii) the GrandFather node point to the GrandFather12

                       wdContext.nodeFather().setLeadSelection(2); --> 3rd father

     iv) the Son node points to the Son1234

                       wdContext.nodeSon().setLeadSelection(3); --> 4th son

                       wdContext.currentSonElement().getName()

     So although there is a single node at all levels(because of the singleton nature of all nodes)

         i.e. one node at GReatGrandFather level

                          one node at GrandFather level

                           one node at Father level

                           and one node at Son level,

      there is still a possibility to get any part of the data by using the right positioning at all levels.

PLEASE VALIDATE THE ABOVE UNDERSTANDING

Now lets say if all the nodes were NON SINGLETON,

-

-


      what would the code be to do the searching.?

regards...

  .V