On Fri, Dec 17, 2010 at 2:25 PM, Robert Zeigler <robe...@scazdl.org> wrote:
> 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?
Brilliant! Now that would showcase the power of Tapestry IoC pretty
well. And it'd be also very convenient for users to configure.
Kalle
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
