Re: A more general approach to configuring for compatibility
There are three that I know of that may be used to achieve that First is Wookie (Apache licence) Second one is jumpstart (also open source, don't know what licence though) Third is hotel bookmarking application I know that two of those are made as a demo apps, but they contain a lot of T5 features still. Only thing needed would be server for selenium tests and some separate repo for test. Maybe apache-extras? Regards Michał Gruca -- View this message in context: http://tapestry-users.832.n2.nabble.com/A-more-general-approach-to-configuring-for-compatibility-tp5846901p5861794.html Sent from the Tapestry Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: A more general approach to configuring for compatibility
That would probably be helpful for development of the framework, to
make sure certain changes that break backwards compatibility don't get
made lightly. It's not a complete solution though - the tapestry
javascript file will change, and that will change behavior, as well as
the java code behind those components. For example, a change that
stopped the server side form validation event from happening wouldn't
be caught by this.
You would really need a full application with tests in order to ensure
backwards comparability. I remember reading that the maven team asked
for people to submit plugins they had made, including tests, so that
they could run them against their new version of maven as they were
developing it, to make sure they were backwards compatible. Maybe the
Tapestry team needs something like that - several applications,
complete with selenium (or other high level) tests that can be run to
make sure that all changes are backwards compatible, or to consciously
decide to make a change that isn't.
On Wed, Dec 22, 2010 at 3:56 PM, Andreas Andreou wrote:
> I was recently thinking about this but from another direction - what if we
> have a heavy page full of forms and almost every one of the tapestry-core
> components and we render and store (in svn) the outcome of its rendering
> both in production and in development mode.
>
> That way we'd end up with many files of the form
> page-dev-5.0.11.html
> page-prod-5.0.11.html
> page-prod-5.2.2.html
> page-dev-5.2.4.html
> page-prod-5.2.4.html
> e.t.c
>
> and a simple diff between any of those will show important info to the user
> and to the devs
> On Fri, Dec 17, 2010 at 22:09, 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
>> 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
>>> 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
>>> 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...@tap
Re: A more general approach to configuring for compatibility
I was recently thinking about this but from another direction - what if we
have a heavy page full of forms and almost every one of the tapestry-core
components and we render and store (in svn) the outcome of its rendering
both in production and in development mode.
That way we'd end up with many files of the form
page-dev-5.0.11.html
page-prod-5.0.11.html
page-prod-5.2.2.html
page-dev-5.2.4.html
page-prod-5.2.4.html
e.t.c
and a simple diff between any of those will show important info to the user
and to the devs
On Fri, Dec 17, 2010 at 22:09, 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 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
>> 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
>> 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
>
--
Andreas Andreou - andy...@apache.org - http://blog.andyhot.gr
Tapestry PMC / Tacos developer
Open Source / JEE Consulting
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: A more general approach to configuring for compatibility
I'm not familiar with Tapestry code but that sounds like a lot of if's and checking for version. If i'm not mistaken then it will pollute the code and maybe slow down applications (as every action will need to be checked) If it is possible then additional modules sounds as much better idea. If someone is upgrading library version then some minimal effort is required from his side (downloading new jar/changing maven). Some small additional effort (downloading second jar/adding maven dependency) should not be so exhausting, and will allow to avoid a lot of unnecessary code. Regards Michał Gruca -- View this message in context: http://tapestry-users.832.n2.nabble.com/A-more-general-approach-to-configuring-for-compatibility-tp5846901p5859511.html Sent from the Tapestry Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: A more general approach to configuring for compatibility
On Fri, 17 Dec 2010 20:25:48 -0200, Robert Zeigler wrote: For this to really work, we might need to introduce a mechanism for explicitly overriding components... We don't need to introduce one because we already have it: it's just a matter of decorating or advising the ComponentClassResolver service, specifically the resolveComponentTypeToClassName() method. -- 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
Re: A more general approach to configuring for compatibility
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: > > 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 >> 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
Re: A more general approach to configuring for compatibility
On Fri, Dec 17, 2010 at 3:27 PM, Robert Zeigler 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:
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
> 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",
Re: A more general approach to configuring for compatibility
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 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 >> 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...
Jos
Re: A more general approach to configuring for compatibility
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 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 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 > >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
>> >> 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
Re: A more general approach to configuring for compatibility
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 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 >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
> >> 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 uns
Re: A more general approach to configuring for compatibility
On Fri, Dec 17, 2010 at 2:25 PM, Robert Zeigler 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
>> 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
>>> 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
>>> 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
Re: A more general approach to configuring for compatibility
+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 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
>> 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
>> 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 Tapes
A more general approach to configuring for compatibility
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 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
> 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
> 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
