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 <andy...@di.uoa.gr> 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 <hls...@gmail.com> 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
>>
>
>
>
> --
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
