For compatibility purposes, we would always be type compatible. :)
But introducing a general mechanism for component overriding could be tricky
because of the issue. I guess you could enforce type compatibility when the
components are overridden? Not sure what an "override" would look like...
In terms of the component definitions in code, we're already instrumenting
that, right? So for the user, as long as the types are type compatible, we
should be ok. So what if there was a component class mapping somewhere that let
you map from a declared component class to the concrete component class? The
@InjectComponent case is somewhat trivial since the component type will be
determined by the template. The @Component case is the tricky one; we normally
grab the component class from the declared type, unless the "type" is set via
annotation. In both of these cases, you have a type. So you ask a
"ComponentOverrides" service for the "real type" to use. We should be able to
enforce that overrides are subclasses of the component they override at startup
time by making the service eagerload, and just checking that the type is
assignable from the overridden type.
Or...
As it stands now, applications can override components by supplying the same
package structure + component, right? Because the classes in the application
are searched before the classes in the tapestry module, so if a user defined
org/apache/tapestry5/corelib/components/Label.java, said class would be used at
runtime in place of the one provided by tapestry. Is this something we can
leverage to allow "compatibility modules" to define "exact matches" to core-lib
components??
Robert
> The problem with overriding core components looks simple:
>
> <t:label> normally means org.apache.tapestry5.corelib.components.Label
>
> It seems like you could do some magic somewhere to map "label" instead to
> org.apache.tapestry5.compat52.components.Label
>
> However, you get hosed by other options, such as:
>
> @Component(for="username")
> private Label usernameLabel;
>
> or even
>
> @InjectCompnent
> private Label usernameLabel;
>
> ... especially because there's no guarantee that the compatibility Label
> class is type compatible with the default Label (i.e., a subtype).
>
> Despite this, if I had it to do over again, I would have fewer options for
> components in the templates; as in, if you want mixins, you'd have to use
> the @Component annotation on a field.
>
>
>
>> 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
>>
>>
>
>
> --
> 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
