[Yanel-dev] Resource has workflow, but not live yet and hence show most recent revision or show a 404

[Guillaume Déflache]

Michael Wechner schrieb:
> Hi
> 
> I have added a parameter to choose if the most recent revision or a 404 
> shall be displayed, within
> 
> WEB-INF/web.xml
> 
> Parameter: workflow.not-live.most-recent-version
> 
> whereas it is set to true in order to stay backwards compatible.
> 
> It would be nice to have this configurable per realm, but would mean:
> 
> - either we enhance the realm api and break backwards compatibility re 
> realm implementations
> 
> - or we introduce a second realm API version
> 
> I would prefer the latter. What do you think?

I think sometimes we should also use (abstract) classes instead of 
interfaces to help use keep backward-compatibility.

For example for realms there has only been (a need for) one 
implementation for a long time, and only recently we switched to a 
interface to cater for the 1st new implementation: IIRC error realms 
(realms that have not been initialized properly at startup).

So I guess switching back to an *abstract* class and deriving both 
implementations from it could also be OK backward-compatibility-wise and 
would make adding things possible without any disruption. Hey, I just 
found out that's what we did for menus ( 
http://svn.wyona.com/repos/public/yanel/trunk/src/webapp/src/java/org/wyona/yanel/servlet/menu/Menu.java 
) and I think it served us great so far! :)

Granted, we should be careful to only keep as few 
code/behaviour/contracts as possible in the abstract class initially and 
only gradually add it back when we realize it is so useful it should be 
shared/standardized: IMHO this may be a much smoother path in this case.


Of course for contracts that are implemented often and possibly mostly 
by third-parties (e.g. SPIs and not APIs) interfaces still fully make sense!

Sorry I do not have any good pointers/references to what is ATM more a 
feeling of how we should go with this kind of compatibility issues: I 
have been trying to collect some about this API/SPI conundrum for a 
while now without much success so far...

HTH,
    Guillaume