on 2003 Dec 05 5:25 PM
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
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
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
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
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
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
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
User | Count |
---|---|
70 | |
10 | |
10 | |
7 | |
6 | |
6 | |
6 | |
5 | |
5 | |
5 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.