[Yanel-dev] XMLResource is not (quite) substituable to BasicXMLResource

Guillaume Déflache guillaume.deflache at wyona.com
Tue Jun 1 17:30:14 CEST 2010


Hi!

On my current project I started to extend BasicXMLResource for my own 
needs, and I later realized XMLResource would also need the same extensions.


XMLResource (XMLR) inherits from BasicXMLResource (BXMLR) but is not 
quite compatible with the latter's initial contract:

Thanks to Eclipse's warnings I can see that only 3 methods from BXMLR 
are overridden in XMLR: #getView(String viewId), #getSize(), 
#getMimeType(String viewId) and the other code "only" implements other 
Yanel capability interfaces: ModifiableV2, VersionableV2, CreatableV2, 
IntrospectableV1, TranslatableV1, WorkflowableV1.

So AFAICU it seems I should also be able to use XMLResource instead of 
BasicXMLResource when I do not need the additional interfaces' 
capabilities, as long as the overridden methods have compatible semantics.

#getSize() is OK: the code is the same apart from comments
#getMimeType(String viewId) *looks* OK, the code of XMLR looks like a 
duplicate of BXMLR's with more features added afterwards, so it's 
probably compatible too
#getView(String viewId) is spreaded out in more methods in XMLR than in 
BXMLR, it could be fully compatible but sadly it never calls 
super.getContentXML(String viewId), it directly calls some code 
equivalent to BXMLR's 
getRealm().getRepository().getNode(getPath()).getInputStream() code.


Summing up, if one wants to override getContentXML(String viewId) as is 
often done to implement views, one must refrain from using XMLR's other 
useful stuff, like versioning, workflow support, translation support, 
editing support, etc. which is a shame IMHO.

I think XMLResource can easily be refactored to correct this.
Any opinion on that?


Cheers,
    Guillaume


More information about the Yanel-development mailing list