[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