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 Thu, 14 Aug 2003 11:59:51 GMT

> - disallowing old DTDs automatically means that the accumulated components
CANNOT be used with new Tapestry versions without manual modifications.

Y'know I really should think before I open my big yap. Tapestry does not
automaticly disallow old DTDs. 3.0 will still allow the use of the 1.3
version of the DTD. There was a point in the past when all the old versions
were still allowed. (I think that was before 2.4?). Originally Spindle
supported all the old versions of the DTD. But then it was decided that 1
version back was ok.

> - making incompatible changes to existing components automatically means
that code working in one version WILL NOT necessarily work correctly in

Sure. But how can one avoid having the framework become a massive ball of
spagetti code in order to support all the old versions? It'll turn into an
M$ product!

> None of this is acceptable.
> We have libraries (not apps) comprising several hundred thousand lines of
code related to Tapestry and a huge number of components. The transfer to
each new version of Tapestry has been a complete and utter pain, often
taking several days work of the entire company and causing bugs that we find
only later. While this was somewhat okay for the early Tapestry versions in
the view of the larger picture, I think we MUST now draw the line where this
will stop.

I think what you are saying is that the days of massive changes to the
framework should come to an end soon. I don't disagree. In fact I have the
same problem right now as we port our app to 3.0. Luckily we only have about
100 of the soon to be 300+ pages completed before porting!

> This is NOT a made up problem. It is deadly serious. At the very least we
must have a backward compatibility section of the contributor's guide (I can
help with this if necessary) and adher strictly to it. The people using the
framework are reaching a critical mass and changes in the names of the
interfaces or the objects' behaviour like what happened in 2.2 (and to some
extent in 2.3) would simply not be tolerated by Tapestry's users.

Then you'll hate Howards latest idea to drop the "I" from all the interface
I think the gunslinger days of Tapestry are coming to an end. Future changes
will need to be scrutinized more closely by us and backwards compatibility
needs to become the #1 factor for debate.

> At the same time, there is a demand for some changes and that must be
handled in some way (e.g. by completely denying such changes or having a
mechanism to do them). Consider the example I gave -- form listener
invocations. The overwhelming desire was to change the default behaviour of
the listeners to delayed invocation. How do we handle this? Do we
> - not make this change
> - add a second listener binding for those listeners
> - do the change using the mechanism that I suggested
> - screw everything and do the change anyway.
> Obviously, the second choice is the easy way out in this case, but it will
not always be possible. What would our standard approach be?

In that particular case why not add a (optional) policy parameter to the
Form component? let the default be the current behaviour. The policy would
apply to all the listeners in the form. Of course then all the listeners in
the form would follow one scheme or the other.

Is it really important that the behaviour be settable for each listener in
the form? If so add the policy parameter to the form components with
listeners.  The form would have to mediate. I guess that means another
hidden field.

I still think that building permanent backwards compatibility into the code
would be a nightmare.
Would be nice if the framework allowed libraries to use an older version of
tapestry. Something like a containment model. Then you could have libraries
using  older versions of Tapestry to interoperate with newer versions. To
use the latest features you would still have to port, but you would not lose
the functionality of existing libraries if you didn't want to port. Or, you
could defer porting until you really needed to.

That brings visions of classloaders and such which is getting into areas I'm
not the best authority on. But its an idea.


> -mb
> Geoff Longman <glongman@intelligentworks.com> wrote:
> -1
> On the surface it kinda makes sense. But I imagine there would come a
> where configuration overhead would become a burdon.
> What really prompts the -1 from me is that once people can mix and match
> behaviour of things, the next step will be mixing and matching DTD
> Say a library using the 1.3 DTD in an app using the 3.0 DTD. YIKES!
> Geoff
> ----- Original Message -----
> From: "Mind Bridge"
> To:
> 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
> 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
> 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
> >
> >
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org

View raw message