|Version 17 (modified by fbatard, 5 years ago)|
Major development & Function testing
We finished to develop the list of references for the Task and currently testing it. How much should we care about the infinite recursion?
I mean if a Task1 has a subtask Task2. And the Task2 has Task1 as a subtask? Do we have to care or do we believe that the admin will be smart enough?
We deleted the tasklist.Observation and contact.Observer. We had to solve quite a huge amount of conflict around the project after that!!'''
Still working on that
We currently have a problem which was supposed to be solved... Apparently after changing x times the schema , we can't read a tasklist using XMLBeans anymore
Therefore we 're working actively on that
Problem solved - Never forget to keep up to date the tasklist.jar in your buid path everytime you compile the schema
Cleaned all the occurences of MimeTypes?!!
We're studying the solution of recursion and adaptation of the RequestList?.
|1. would effect major changes in the UnicornCall?||1. would be more natural to program|
|2. would break the design patterns and architecture of the application|
|1. May rise a problem for the level of execution||1. would effect minor changes in the UnicornCall?|
|2. Create a new algorithm to deal with conditional nodes||2. would suit the architecture of the application|
We're studying an hybrid solution. One which would create recursively a RequestList? for each level of execution. That might be the solution.
Here is the hybrid solution:
We'll browse the tasklist tree recursively in order to keep the link between the if and all that. At each recursion we'll generate a RequestList? which will contain the exec of this level and the if condition for the next level. We'll check the result of the "if" by applying the condition. If it matches we'll call the same method on the ifOK node. on the contrary we'll call the ifnotOK node in the function.
Don't forget to check that the node is not null at the beginning. If it is , just return
This way we'll keep the simple architecture already settled in the project and we'll also add the simplicity of the recursion. Therefore it might be easy to understand and quite clear. However this will cause major changes in the UnicornCall? class.