week8+

Correct repetitive bugs in Unicorn Call BR We had to rebuild the whole dependance things with the classesBR We had to correct the algorithm and think about the Response.BR

---

Does the if launch an observation or does it use a result previously executed?BR I mean , the if does an observation or use an previous observation done by an exec?BR The answer to this question will completly change the data structure and the algorithm to apply the condition in UnicornCall.BR Then we debate about that. BRBR If the if doesn't perform an observation we'll just need of map of Response with the name of the observer as an ID.BR Therefore the condition of the if will give us the name of the observation on which we'll have to apply the condition and we can search it in the map of Response.BRBR Otherwise it's a little bit trickier to get the observer of the if to launch it but still quite easy to do.BR We'll have a huge map of Response which will group all the response. This map will be filled thanks to the recursion on the tree.BR

---

We may have erased more mimetypes occurence than needed. Then we deleted a bit of check concerning the mimetype in UnicornCall.BR Then we have to re write it. Check the mapOfObserver to do the check observer.canHandleMimetypes.BR Maybe we need to associate an Observer in the tree in order to keep the mimetypes things.BR In the tree we only have the String of the name of the observer. Should we put an Observer object instead?BR The mapofObserver is given in the tasklistUnmarshaller from the Framework in static.BR We can also associate the name of the Observer to the real Observer in UnicornCall and check the mimetype compatibility at that time.BR

---

We had to merge the version of Jonathan with mine , with minor problems... just took ages to do for each class.

---

After the merge and the algorithm in UnicornCall we had a big cleaning to do in the class... still on itBR We created a procedure to browse the Tree and create a RequestList for each execution level / each node.BR The problem is to keep going in the tree knowing that the answer is in the mapofResponse.BR The new procedure should browse the tree, launch the Request, check the ifs of the current node and for each of them and analyze the response and recall itself on the new node.BR Heavy recursion but might work.BR We can externalize the launch of the Request , the condtional checking on the response.BR However the procedure will still be heavyBR

---

We had a little specification problem. The way we did the UnicornCall to browse the tree wasn't especially made to care about the condition.BR Now that we're coding the conditional checking we have to adapt the UnicornCall and do another algorithm to care the conditional checking now.BR Jonathan is doing the conditional checking.BR Me (Florent) I rewrite the whole UnicornCall and clean it up while I'm on it.BR

---

About conditional checking and XPath in particular : BR The XPath expression is to be used on the XML response of an observer. But this response is immediately put in a Java object (Response) for now. Thus, we need to keep a way to access the XML version of the response somewhere. BR It could be in the corresponding Request or in the Response itself (more logical I think).BR In what shape should we stock it ? As an URLConnection, InputStream, something else (ObservationresponseDocument ...) ?BR

---

Jonathan is on the conditional checking having trouble with the XPATH and the different way of transmitting the file. BR What if the response of the observer is not in XML? XPATH would have no purpose in that context.BR We may let that option to the administrator and hope that he'll be clever enough not to do XPATH on text response.BR Additionnely, the observer sends its response in a stream which can be read only once! Therefore we can't create the Response for Unicorn and use it for the conditional checking at same, we'll have to find a way to deal with this.BR

---

Futhermore me (Florent) is having trouble with UnicornCall as we deleted some class like Observation i had to emulate certain behaviour inside UnicornCall especially for the requestList. We discussed with Jean-Gui about strange pieces of code too that check the mimetypes even for the parameters and so on. I try to emulate and reproduce it in case it would be important but i still don't get the purpose of that.BR We had to change the TasklistTree in order to take into account the observer. Therefore we changed the algorithm to fill the tree.BR I had to create a Map for each node of the tree to group all the execution list and the list of the observer nested in the ifs.BR