On Fri, 17 Apr 2015 09:33:50 -0300, Poggenpohl, Daniel
wrote:
Hi,
Hi!
It was just an idea without knowing the inner workings or workflow of
the bytecode manipulation. I just saw something which looked like the
JavaScript problem on first glance without looking into the mechanics.
On
On Fri, 17 Apr 2015 04:54:33 -0300, Lance Java
wrote:
In theory, that's possible. Tapestry doesn't reference ASM classes, it's
only dependency is plastic. So in theory you could have a layer in
plastic to choose ASM or javassist as the "provider" (or another byte
code
library).
Yeah, I
[mailto:lance.j...@googlemail.com]
Gesendet: Freitag, 17. April 2015 14:02
An: Tapestry users
Betreff: Re: Tapestry 5.4 bytecode manipulation
On second thought... Why would you want to swap out the the bytecode provider?
With clientside javascript it makes sense to choose the provider since you will
be
On second thought... Why would you want to swap out the the bytecode
provider?
With clientside javascript it makes sense to choose the provider since you
will be directly using jquery or prototype in your own code. Having a
single provider reduces the scripts downloaded by the client.
But with pl
In theory, that's possible. Tapestry doesn't reference ASM classes, it's
only dependency is plastic. So in theory you could have a layer in plastic
to choose ASM or javassist as the "provider" (or another byte code
library).
I'd doubt that this is high priority for the tapestry team. I seem to
rec
Hi,
if I understand your plans regarding Tapestry 5.4 correctly, you uncoupled the
JavaScript engine so that you can choose between e.g. Prototype or JQuery.
Now, after asking some question on StackOverflow:
http://stackoverflow.com/questions/29645744/how-do-i-deploy-my-eclipse-tapestry-web-app-
