week6+

Code and Code again :)

BR

How to simplify that?

The difference is only in the parameter.. Parameters are auto-generated types created by XMLBeans so we can't change it... BR I've modified the schema to solve this.Now the else tag will contain an generated thenType.. might be confusing in the code but it solves the complexity. See the attached schema for the changes. Problem solved

BRBR

---

I'm coding the relation between the if value attributes and the conds nodes.BR As we build the tree we have insert the cond in it and therefore we'll have to find the cond node by ourselves.BR We won't need the # in the if statement anymore. Here is the new XML sample for the tasklist.BR Problem solved

As XMLBeans doesn't take into account the # , it's done this way now

---

The Task tree is implemented , filled and tested. Everything works fine by now. Wasn't a problem anyway :P

---

We had to change the schema once more to take into account the fact that an exec tag concerns another task OR an observer.BR Then we added a type attribute to resolve it. Possible values are -> subtask OR observerBR You can find the new schema here.

Problem solved

---

Currently doing the tasklist.Task coupled with the UnmarshallerBeans.Right now the Unmarshaller fills the MapOfObservation of the tasklist.Task by parsing the generated JAXB Task.BR Now , what we've done is to create the whole tree of execution level in the constructor of the tasklist.Task. Then to list the observation we just have to browse the tree.BR Is that too much responsibility for the tasklist.Task object? Should we continue to do it in the unmarshaller?BR What should be the responsability of the Task class? BR Should we let it cares about input methods , calls and threading which would simplify much the UnicornCall? However this will considerably change the current sources and the difficulty into the code. We would have to re-do quite everything about the calls to the observer too...BR The task already cares about parameters , taskTree, the reference merge and expand... BR This means there would be one object Task by Unicorn request too. This is a problem.

---

The tasklist.Observation represent an observation with the different mimetype handling priority.BR With our solution , an observation is almost like an exec tag in the new tasklist.BR Then the tasklist.Observation will become much much simpler.BR However we may create new classes to deal with the execution level to deal with the different Observation.BR Any ideas on that? The simplification of the Observation Class affects the RDFUnmarshallerjena class and Unicorn Call of course.BR I'll take a look at that.BR What to do with the mimetypes? should we erase it? or keep it for other purposes. The RDFUnmarshaller allows to add mimetype handling to a task and therefore to an observation. The mimetypes could stay in order to test if the observer really handles the mimetype we're giving.BR The RDF in in unicorn.conf.Task.rdfs define priorities and mimetypes.. We'll have to change all the RDF handling too.BRBR I've erased all the trace of mimetypes in the Observation class, and in the unicorn.cond.Task.rdfs. I may emulate the mimetypes check to know if an observer can handle specific mimetypes.

---

In the UnicornCall we should adapt the RequestList. In the GenerateRequestList , we'd add observation with their level of execution as a keyBR Therefore in the doTask method we'll loop till the level of execution existBR I think that's the solution that doesn't damage much the existing code and would be as effectiveBR Whereas this would erase the behaviour with the 3 priorities Maps.

---