tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mind Bridge <mindbridge...@yahoo.com>
Subject [DISCUSS] Backward compatibility
Date Wed, 13 Aug 2003 14:42:12 GMT
We have been discussing periodically backward-incompatible changes that will make the framework
more powerful. Needless to say, these changes are great in the long term, but they do have
a cost with respect to the developers who are using older versions and want to switch to a
new one. This problem is bound to become more and more important as the number of people using
Tapestry increases. I would like to suggest an approach that should 'untie' our hands to make
some backward incompatible changes in general. Here is a good example: the change in the form
listener behaviour (invoke immediately or delay) discussed a while ago.
The idea is the following: have a standard component property called 'org.apache.tapestry.version-compatibility'.
The value of the property should be a number. It will represent the version which the code
When components introduce backward-incompatible changes in their behaviour, they can check
this property to decide how to behave. For example, the code that invokes the form listeners
can check whether the version is <=  3.0 and invoke them immediately, or if it is >=
3.1 (for example) it can perform delayed invocation unless specified otherwise. The result
of the check can be stored in the component at load time, so it will have no other bearing
on performance.
The following order can be used to search for the property value:
component/page (this will be the enclosing component/page in cases like the above)
... the rest of the standard property search order
This will allow, for example, a library and its components to have 3.0-specific code, while
the rest of the application is designed for 3.3 or sth like that.
Clearly, this would not help in all cases, but it will definitely make some incompatible changes
much easier to make.
Does this make sense?
Best regards,

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message