Make CycleStrategy More Flexible
Brought to you by:
niallg
I had previously gone the route of wanting to extend the CycleStrategy class, but because you didn't like that approach, I've refactored it slightly.
See the attached patch to allow for users to easily add in their own logic as needed during serialization.
This patch is against simple 1.6.
Added ability for users to add logic to their cycle strategy
Logged In: YES
user_id=1853426
Originator: YES
Note: this allows me to do the following:
public class OpenmrsCycleStrategy extends CycleStrategy {
/**
* Overriding the default constructor so we can set our label
* logic onto the strategy.
*
* This label logic will convert hibernate proxy class names to
* their equivalent pojo class names
*/
public OpenmrsCycleStrategy(){
super();
setLabelLogic(new OpenmrsLabelLogic());
setReferenceLogic(new OpenmrsReferenceLogic());
}
}
This allows me to serialize around the hibernate proxy objects with the attached LabelLogic class. This label logic could be cleaned up to allow for any type of hibernate/cglib object to be serialized fairly easily. We only have a few types that get in the way, so my labellogic is fairly basic right now.
File Added: OpenmrsLabelLogic.java
Label logic used by openmrs to have custom serialization done via a cycle strategy
Logged In: YES
user_id=604628
Originator: NO
Cool, looks good. I am going to take a look at this soon, did not make it in to 1.6.1 but may very well make it in to the next release.
Logged In: YES
user_id=604628
Originator: NO
Could you provide an example implementation of ReferenceLogic?
Example Reference logic class
Logged In: YES
user_id=1853426
Originator: YES
Our reference logic just allows me to serialize multiple times with multiple objects without duplicating keys.
File Added: OpenmrsReferenceLogic.java
Logged In: YES
user_id=604628
Originator: NO
I have taken a look at this, I like the idea, and I think the Strategy needs to be made a little more usable. In particular the CycleStrategy. I am leaning more twards an even more generic implementation, such that on writing you can substutite attributes reagardless of whether its a classname or some other attribute. This enables the strategy to play the role of a decorator of sorts. A more generic implementation will allow modification of the attributes after the Strategy implementation has finished adding its attributes, such as class=some.class.Name or id=some.reference. If you have any input on this that would be great, I am going to initially implement something that can add and change attributes on writing, and replace and substitute attributes on reading.
Niall