Well, something that is deprecated with a replacement in Tapestry 5.(n)
might be removed in 5.(n+1), though I suspect most users would prefer to see
it live on to 5.(n+2).
On Fri, Dec 17, 2010 at 3:12 PM, Howard Lewis Ship <hls...@gmail.com> wrote:
> 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
>
--
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
