tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geoff Longman" <glong...@intelligentworks.com>
Subject Re: [DISCUSS] Backward compatibility
Date Wed, 13 Aug 2003 18:56:09 GMT

On the surface it kinda makes sense. But I imagine there would come a point
where configuration overhead would become a burdon.

What really prompts the -1 from me is that once people can mix and match the
behaviour of things, the next step will be mixing and matching DTD versions.
Say a library using the 1.3 DTD in an app using the 3.0 DTD. YIKES!

----- Original Message -----
From: "Mind Bridge" <mindbridgeweb@yahoo.com>
To: <tapestry-dev@jakarta.apache.org>
Sent: Wednesday, August 13, 2003 10:42 AM
Subject: [DISCUSS] Backward compatibility

> Hi,
> 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 targets.
> 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)
> namespace
> application
> ... 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,
> -mb

View raw message