![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
Topic Title: Whose turn is it? Topic Summary: Timing and sequence of object processing in LayoutDXL? Created On: 29-Mar-2007 14:34 Status: Post and Reply |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() |
|
here is a question about the "timing" and sequence in which objects are processed by LayoutDXL. Example case: On first glance, this looked to me like a classical case for using a recursive function, which drills down to the lowest level objects, and then back up again, accumulating the values as it goes along. However, in someone else's code I saw that he lets every object accumulate the value just over its immediate children (but not the grand- and great-grand-children etc.). Or do we? What about timing? If an object updates its values from its children before those children all have updated themselves from their children, wouldn't the higher-level object end up with a wrong ("stale") value? At least until the next round of running the code? I made a small test module to test this, and the end results for the accumulated values were in fact correct. But that may depend on module size / object number. Hence the question: Specifically, can we safely assume that upper level objects will always automatically and in a timely manner adapt their data to changes in their offspring (if there is a dependence)? Or do we have to make sure through specific code that either these changes consider the whole object tree globally; or that at least local changes are explicitly kept in sync? [ A straightforward alternative solution would of course be to handle this task "bottom-up": |
|
![]() |
|
![]() |
|
Layout DXL recalculates each time the object is redisplayed. I presume the order is top down from what you see on the screen.
If you have layout DXL working as you suggest then the DXL code itself must be searching for the currently displayed column that contains that layout code, so it can get the value from its children. That looks tough. You probably are talking about Attribute DXL; in fact that's what I'm going to talk about... Attribute DXL calculates the first time the value is retrieved, or whenever the value is null. That 'null' clause means that string AttrDXL should display a space instead of null if that's the result. integer AttrDXL should probably display zero. The Attribute dxl could retrieve its own current Old Value value before it sums up the values of its children resulting in the New value. If the Old Value is different than the new value than this object could realize that its parent must be recalculated, so it could set its parent value to null (not to zero), which should force it to recalculate. I believe this algorithm doesn't presume any particular ordering of execution, but does force parents to be calculated whenever their children change values, which is what you want. Attached is the psuedo code for that. - Louie |
|
![]() |
|
![]() |
|
Thanks, Louie, that's very helpful (as always, I might add
![]() Martin Edited: 30-Mar-2007 at 07:22 by Martin Erdelen |
|
![]() |
Telelogic DOORS
» DXL Exchange
»
Whose turn is it?
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.