I am working on parsing some strings that contain a object information with some dependencies or requirements for the object.
This is for product configuration and the objects are the components that make up a build for the product. Think of like when you go through a list to bulid a car, a computer, or anything else that has components that require you to select certains ones in order to get others. This is the logic I am trying to create in my application.
My application presents the user with a treeView component that contains a list of objects that are loaded in from a excel file. I am trying to create an interactive list of objects that correctly enables and disables the treeView’s nodes appropriately based on the dependencies between the objects that the nodes are representing. The list of objects represents a configuration for a build. So the objects are components that make up a final product and have restrictions as to which components or objects can be selected for any given build.
Here is a sample format for a line containing the dependencies that I am trying to write logic for:
objectID_y1234_y1233_n2345
-
objectID is the id of this object(component) and is a 4 digit number, there is an extremely rare case of it having one letter in the object’s id like: 12a4
-
y1234 means this object requires object with id 1234 to be selected to be active.
-
y1233 means this object requires object with id 1233 to be selected to be active.
Since y1234 and y1233 share the same first two digits in their ID numbers this creates an or condition.
So this object requires object 1234 or 1233 to be selected instead of both to be selected.
-
n2345 means this object is not active when object 2345 is selected.
The the first dependency listed always starts with a "y" or a "n" so you can never have objectID_1234_n2345_y1235, but you can have objectID_y1234_1235_n2345.
Also if the condition is an "or" condition you cannot have y1234_n1233, it is either both have y’s or both have n’s.
Some more of the many possible formats:
-
objectID_y1234_2345
This is stating object requires object 1234 and object 2345 to be selected for this object to be active. -
objectID_n1234_2345_y3456
This states objectID requires 1234 and 2345 to not be selected and 3456 to be selected for this object to be active. -
objectID_n1234_n1233
Unlike y1234_y1233 if n is used the condition is always "and" so this means 1234 and 1233 cannot be selected for this object to be active.
Feel free to ask for more information/explanation if something is unclear. I am trying to explain this as clearly as possible because the dependencies can become confusing easily. I did not list all the possible combinations for the statements as they don’t have a limit to length, but just consist of longer or multiple "or" and "and" conditions with object Ids.
Big Picture of what is going on:
I have a treeview of objectIDs and when you select one object you have to de-activate the conflicting objects and activate or the ones that can be selected now.
Purpose of Dependencies:
The dependencies have to answer two questions…
1: What objects cannot be selected for this object to be active?
2: What objects must be selected for this object to be active?
My Question/Problem:
I find that this data is extremely fragile and sometimes objects place dependencies on eachother that de-activate both objects and neither will ever be able to be selected.
Example:
ID1234_y2345
ID2345_y1234
This results in neither 1234 or 2345 being active because at start both are de-activated since the requirements(dependencies) are not met.
If anyone has an idea that could change the syntax or format that represents the dependencies I can do that. I just haven’t found a alternate way that fits the requirements with out causing more complexity or problems.
Ultimately I am looking for a way I can approach this and come up with a solution that will work. I have been trying to implement a solution for some time now and all of my attempts have failed so far. I have tried various recursive and non-recursive solutions. I may be wrong, but I almost feel like this is something a neural network could do since I am basically trying to make a computer think for itself here.
I have been trying to start with a list of everything I need to do and then implement a solution that fulfills the list, but I end up finding more issues as I go and add to the list so I never am covering all the possibilities and there are probably more I haven’t discovered yet. Overall I have been able to de-activate and activate correctly some of the time, but it is not reliable all the time and it needs to be.
Current Logic
In the tree the components of the same type share the same 2 leading characters so if 1234,1233, and 1245 are in a group and the user picks 1234 I treat the group like a radio button. So 1234 added to a list tracking the selected components and 1233,1245 are added to another list of disabled components. Then the entire tree is updated by checking each component and making sure it is disabled or enabled depending on if it’s requirements are now met. However if I have to disable another component while checking, currently I check the tree all over again which is horribly inefficient because it could keep doing this for a while. I thought recursion might have worked better, but got a mess that was really hard to debug and still had too many issues.
For checking the list of components, I still think recursion is the way because when I select a component I need to disable the other components that are not available then check the components I disabled, and then any components that are disabled because of the ones I disabled and so on…
Example: If I disable 1234 and 1890 requires 1234, I now disable 1890. But now 1770 required 1890 so I disable 1770. Then if something requires 1770 I need to disable that and so on…
All help and suggestions are appreciated.
A solution that works and has been implemented in place of my original logic.
The original logic had the application checking all the nodes affected by a node that was being selected by the user. The nodes states (disabled, enabled, selected) were controlled by the nodes being selected by the user and were being verified each time the user selected a component in the treeView.
Solution:
By re-thinking my approach I came up with the following logic for the application that accomplishes the task of ensuring the dependencies of the components are enforced:
When the user selects a component the application carrys out the following steps:
Checks the component for the objects it is incompatible with and checks if any of the components have been selected by the user.
Checks the component for other components that are required for this component and checks if these components have been selected already.
Notes:
The prompts will be optional because they are recorded in a log on the interface allowing the user to refer back to them as needed.
Conclusion:
This solution allows the configurator to ensure the dependencies and requirements of the components have been met. Although having the nodes update was the original intent, I realized in the original logic I hadn’t thought of how to help the user figure out why a component was disabled. With this new approach the configurator is informative and doesn’t leave the user confused.
It is possible of course to create a configurator like the original concept, but given my experience and assortment of tools, this other solution provided a working application that my users are more pleased with.