Hi Everyone,
Thanks to everyone on this list for their continuing support on Tapestry
technical issues. Hopefully you all can help me land some new Tapestry work
too. :-) Here's a little about me:
I have over 11 years of experience in client/server and distributed systems
- including 4 recent
I know this is an old thread, but I've been working on a T4.1.1 application
for a long time and it's about to go live. Our recent live site testing
shows that these huge .js files kill the initial page load and they aren't
really getting cached by the browser, so they transfer on *every* page
I know this is an old thread, but I've been working on a T4.1.1 application
for a long time and it's about to go live. Our recent live site testing
shows that these huge .js files kill the initial page load and they aren't
really getting cached by the browser, so they transfer on *every* page
tapestry-prop doesn't work with 4.1.5 right off the bat. Does 4.1.5 have
built-in support?
What's the recommendation here?
--
View this message in context:
http://www.nabble.com/Tapestry-4.1.5---tapestry-prop-tp18456522p18456522.html
Sent from the Tapestry - User mailing list archive at
That is exciting! So what binding prefix do I use? ognl:? nothing?
Many thanks!
Jessek wrote:
4.1.5 no longer needs tapestry-prop. Expression jit compilation is
built in already.
--
View this message in context:
I was using this with Tap 4.1.1, but when I upgraded to 4.1.5 today, I'm
getting this javassit error...
javassist.NotFoundException: $BaseComponent_4
at javassist.ClassPool.get(ClassPool.java:436)
at
org.apache.tapestry.enhance.CtClassSource.getCtClass(CtClassSource.java:50)
Hmm. Just finished upgrade to 4.1.5 and the asset service clearly isn't
caching dojo .js resources.
Using firebug, I can see every request. There is no MD5 digest in any of the
urls, and when I add a breakpoint to the asset service and step through the
service() method, I can see it open the
browser cache? I've never seen/heard of something like this so
I
don't have a lot of ideas.
On 6/29/07, Jeremy F. Kassis [EMAIL PROTECTED] wrote:
Just upgraded to T4.1.2. On pages with forms, I get the following error:
tapestry.form.registerForm is not a function
Using firebug, I
.
On 6/29/07, Jeremy F. Kassis [EMAIL PROTECTED] wrote:
Thanks for the quick reply.
I cleared my browser cache, but no luck.
Then, I rebuilt the tapestry-framework-4.1.2 jar with a couple of
alert('hi'); lines embedded in the form.js file. Cleared my cache again
and
checked the GET request
Just to be clear, I broke it more to see what would happen and eliminate
the possibility that the defaultDojoPath and related IAsset declarations
were wrong. I changed them back, assuming they are right, but I don't have
any new theories.
I'm using Firefox 2, which I know is a little bleeding
Just upgraded to T4.1.2. On pages with forms, I get the following error:
tapestry.form.registerForm is not a function
Using firebug, I...
1. Set a breakpoint on this line: require(tapestry.form);
2. clear the console
3. step over the function call
4. observe the GET requests for
to make it easy:
div t:type=EmptyFrame t:id=myFrame
t:parameter name=centerBlock Something /t:parameter
/div
t:parameter is used to define a Block and bind it to a parameter all
in one go.
On 6/17/07, Jeremy F. Kassis [EMAIL PROTECTED] wrote:
This works:
div t:type=EmptyFrame t:id
This works:
div t:type=EmptyFrame t:id=myFrame
centerBlock=block:centerBlock/div
t:block t:id=centerBlockSomething/t:block
But T5 complains that the component doesn't have a Block with
id=centerBlock in this case:
div t:type=EmptyFrame t:id=myFrame centerBlock=block:centerBlock
t:block
so it'd be easy to qualify
it as a bug..
On 2/8/07, Jeremy F. Kassis [EMAIL PROTECTED] wrote:
I'm having the same problem. I looked into this once. It has something to
do
with how the Dialog component works. It actually copies the DOM tree of
the
elements within the Dialog into a DOM
I'm having the same problem. I looked into this once. It has something to do
with how the Dialog component works. It actually copies the DOM tree of the
elements within the Dialog into a DOM island that it stuffs under the window
or document object I think. So, basically, the Input element within
on my part but I'm not sure? Either way
your feedback would be greatly appreciated, hopefully I can use your
issues to enhance the 4.0-4.1 upgrade guide.
On 1/11/07, Jeremy F. Kassis [EMAIL PROTECTED] wrote:
I just noticed something that seems related. The browser reports a syntax
error
with a library prefix. Not a major
deal, but perhaps a bug.
Many thanks for your help Jessek!
jeremy
Jeremy F. Kassis wrote:
Hi Jessek!
This sounds right on.
Since a few service points, including DojoAjaxResponseBuilder get the
exceptionPageName from the Infrastructure service point, I tried
Note for the update guide:
If you are using a custom Exception Page, make sure you check out the
changes made to the default exception page. In particular, your exception
page won't render correctly after an XHR request unless it renders with an
empty or null DOCTYPE.
Jeremy
Jeremy F. Kassis
the core.js client-side javascript that handles this request actually
parse and run script in embedded script blocks anymore? If not, what's the
recommended way to handle this?
Many thanks!
Jeremy F. Kassis
BumpQ, Inc.
--
View this message in context:
http://www.nabble.com/Q%3A-Body-Scripts-in-T4.1
19 matches
Mail list logo
