It's a tricky situation; some users are going to want to upgrade to 5.3 and
see new features and behaviors automatically; others will want to upgrade to
5.3 and see nothing change until they enable it.
I like the idea of factoring out as much as possible into
tapestry-compatibility.jar.
I think there will always have to be some "case" logic to handle some of
these compatibility issues. It's simply not avoidable (well, perhaps by
adding n-layers of new abstraction, and that's not going to happen).
On Fri, Dec 17, 2010 at 2:25 PM, Robert Zeigler <robe...@scazdl.org> wrote:
> +1.
> Although the question remains... how /long/ to be compatible. For
> instance, you might want "5.0" in there, as well, in which case, the
> label-id generation would need to be enabled for modes 5.0 and 5.1
> (suggesting perhaps a need for some conversion to an "ordered" value...
> something more than boolean).
>
> What we /don't/ want is to have the codebase littered with multiple
> different cases for different versions. It might go that way, but at some
> point, support for old behavior has to go... the question is when?
>
> I'm thinking out loud here, but...
> Recently, I upgraded a project from 5.0.15 to 5.1.0.4. The project is
> fairly complex, and there were some major changes in Tapestry's behavior
> between 5.0.15 and 5.0.18, when the public apis were locked down as stable.
> What impressed me from this process was how much of the "old" behavior I
> could restore via various service contributions. It makes me wonder if,
> instead of introducing a "compatibility version" symbol (and associated
> checks in the code), we could introduce "compatibility modules". Eg:
> tapestry-compatibility-5.1 (version 5.2.4) would restore 5.1's behavior in
> 5.2.4. For this to really work, we might need to introduce a mechanism for
> explicitly overriding components... so the 5.1 compatibility could have a
> label component that overrides the default 5.2 component, or something like
> that. Anyway... this might be a good solution to avoid littering the core
> codebase with checks.
>
> Thoughts?
>
> Robert
>
> On Dec 17, 2010, at 12/172:09 PM , Howard Lewis Ship wrote:
>
> > It was simply the case that the id wasn't needed, because the label could
> be
> > located as previously outlined.
> >
> > Rather than have an endless number of switches to set, I think we may
> need a
> > global compatibility symbol ("tapestry.compatibility"), and maybe a
> > mechanism for turning that into a boolean at the point of injection. The
> > values for the symbol would be "5.1", "5.2" "5.3", etc.
> >
> > The quickstart archetype should set the symbol in the generated
> AppModule.
> > In this way, users on upgrade could conciously change the compatibility
> > mode.
> >
> > We would want to document, exhaustively, what is enabled or disabled
> based
> > on the symbol.
> >
> > This isn't a total solution to backwards compatibility, and not
> everything
> > could be handled this way, but it would be a good start.
> >
> > On Fri, Dec 17, 2010 at 11:38 AM, Josh Canfield <joshcanfi...@gmail.com
> >wrote:
> >
> >> Hmm...
> >>
> >> The id needs to be put back, but before we add a symbol to allow it to
> >> be optionally removed I'd like to make sure that Howard (and anyone
> >> else) really needed it removed and it wasn't just some house cleaning.
> >> I imagine if it was really a number of bytes issue then more than just
> >> the label could be optimized and a markup filter like Robert suggested
> >> is more appropriate...
> >>
> >> Josh
> >>
> >> On Fri, Dec 17, 2010 at 10:56 AM, Robert Zeigler <robe...@scazdl.org>
> >> wrote:
> >>>
> >>> On Dec 17, 2010, at 12/1712:53 PM , Thiago H. de Paula Figueiredo
> wrote:
> >>>
> >>>> On Fri, 17 Dec 2010 16:35:43 -0200, Robert Zeigler <
> robe...@scazdl.org>
> >> wrote:
> >>>>
> >>>>> Just to clarify, I hope that by "true" you mean that id generation is
> >> turned /on/ by default. :)
> >>>>
> >>>> Your hope isn't in vain. :) true = on in this case.
> >>>>
> >>>>> warnings as time allowed. The important thing is that even with
> >> deprecated methods, the old /behavior/ was preserved. It's a policy we
> >> should adhere to more in Tapestry. What users need /most/ from the
> >> framework is dependable behavior; in large part, they need that more
> than
> >> the few bytes of bandwidth saved by removing the id from the label
> >> component.
> >>>>
> >>>> Agreed. I guess most of the disrupting changes were just honest
> >> mistakes. It's kinda hard to foresee of all the consequence of a change,
> >> specially when most of the users (the developers using Tapestry) are not
> in
> >> your team.
> >>>>
> >>>
> >>> Fair enough.
> >>>
> >>> Robert
> >>>
> >>>> --
> >>>> Thiago H. de Paula Figueiredo
> >>>> Independent Java, Apache Tapestry 5 and Hibernate consultant,
> developer,
> >> and instructor
> >>>> Owner, Ars Machina Tecnologia da Informação Ltda.
> >>>> http://www.arsmachina.com.br
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> >>>> For additional commands, e-mail: users-h...@tapestry.apache.org
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> >>> For additional commands, e-mail: users-h...@tapestry.apache.org
> >>>
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> >> For additional commands, e-mail: users-h...@tapestry.apache.org
> >>
> >>
> >
> >
> > --
> > Howard M. Lewis Ship
> >
> > Creator of Apache Tapestry
> >
> > The source for Tapestry training, mentoring and support. Contact me to
> learn
> > how I can get you up and productive in Tapestry fast!
> >
> > (971) 678-5210
> > http://howardlewisship.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to learn
how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
