week7+

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?BR 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?BR

---

We deleted the tasklist.Observation and contact.Observer. We had to solve quite a huge amount of conflict around the project after that!!!BR Still working on that

---

Split the TaskList from XMLBeans and tasklist.Task. It means we'll build the tree of tasklist.Task in the UnmarshallerBeans instead of inside the Task.

---

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 BR 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.BR Recursion ||Con's|| Pro's|| || 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|| || RequestList adaptation ||Con's|| Pro's|| || 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: BR 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.BR Don't forget to check that the node is not null at the beginning. If it is , just returnBR 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.

---

Now that we did the Request and so on , we're doing the treatment of the condition.BR Depending on the type we need to care about several types of condition including XPATH. We're then doing the condition algorithmBR We need to apply a condition on a Response object while the multi-threading.BR

---

TODO :

• condition
• check the mimetype observer
• check the schema http://www.w3.org/2008/03/validators-chart.png