Yeah, to be sure. That's why I like the tapestry-compatibility module idea....
you add it if you want full backwards compatibility. You leave it out if you
don't need it/want the new behavior by default.
Additionally, each compatibility module could contribute the
TAPESTRY_COMPATIBILITY symbol appropriate for it. Like I said, just "thinking
out loud". You're probably right that at least /some/ special casing will
remain in the core. But I think a large fraction of backwards
compatibility-type contributions could be factored into specific modules.
Managing which module does what might be a pain... I'm just imagining: "This
module adds 5.1 backwards compatibility to 5.2. That one does to 5.3" and so
forth. But I /think/ what you would do is have a "tapestry-compatibility-50"
(and tapestry-compatibility-51, 52, etc.) with versions 5.1.0.x, and maybe
5.2.0.x. And eventually 5.3.0.x. So the version matches the tapestry-core
version that you needs to add backwards compatibilitly /to/. The module name
reflects the level of compatibility that you're adding. I dunno... now that
I'm saying it out loud, it sounds like it could be overly confusing. But the
overall concept is good, I think. Especially if it's possible to override core
component definitions; I'm not sure if that's (easily) possible currently.
Robert
On Dec 17, 2010, at 12/175:12 PM , Howard Lewis Ship 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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
