On Fri, Dec 17, 2010 at 3:27 PM, Robert Zeigler <robe...@scazdl.org> wrote:
> 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.
>
>
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
