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
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 tho
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 f
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.
-
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 ComponentClassReso
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
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 compatibi
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
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 upgrad
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 t
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 l
+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 th
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
13 matches
Mail list logo
