I'm still having trouble getting wicket-event.js to return anything but junk.
Even though I thought it might have something to do with compression, I
doubt that now, because I have my homegrown compression filter turned off.
Does anyone know what this error means:
DEBUG 2007-08-03 15:42:34,452
I didn't know you could still use the servlet in 1.3. As it turns out,
switching to using the servlet did fix the problem. I don't know if that's
a problem with the filter or with the way I had things set up. The
downside, I've now discovered, is that after doing the forward the app now
thinks
Actually, this is available. It is possible to embed javascript inside a
PDF. It depends on what you're using to generate the PDF however. I'm sure
Acrobat can do it. There a library called iText which can. I think it can
even go into an already created PDF and insert the necessary JS. We
I believe I've finally solved my problem.
No doubt the original problem was double compression resulting from using a
homegrown compression filter on top of wicket's default compression. After
being forced to look at this issue again, which suddenly seemed to not only
be a problem with just IE
UPBrandon wrote:
That seems to work. I was trying to do exactly that earlier. At the
time, I couldn't seem to access the setResponsePage() method but I must
have been doing something wrong. For anyone who might be reading this
later, I ended up calling setResponsePage(getPage() );
I know this has been discussed before, but none of the previous posts have
helped me solve my problem. I'm trying to embed a wicket page into a jsp
page (until I have time go back and convert all our jsp's to wicket) using
the jsp:include tag. oc4j throws a ServletException: Error in Servlet,
Martijn Dashorst wrote:
I don't have any experience with oc4j nor embedding wicket in JSPs,
but I know two things that can cause trouble:
- make sure you use ONE_PASS_RENDER as a render strategy
I actualy did have this set up in our main app. I just didn't put it in my
small test app.
Al Maw wrote:
At the very least, you'll need to do what Martijn suggests and set a
one-pass render strategy.
Done, with no success.
Al Maw wrote:
I'd recommend you go and read my blog post about this whole topic:
I tried implementing the solution from your blog, and after a long struggle I
finally got it working. . .or so I thought. Now my wicket links are
throwing page expired errors. Maybe it has to do with the fact that the way
I had to set it up, the pages with embedded JSP are running under the old
Martijn Dashorst wrote:
ONE_PASS_RENDER does not kill back button support, but does provoke
that blasted repost on back button for form submissions. So it
prevents the double submit problem.
Right, of course. I knew that. :)
Martijn Dashorst wrote:
The HttpSessionStore is the
Martijn Dashorst wrote:
look in the source of the page, and possibly try to capture the
headers. This will help us in discovering what goes wrong.
Haven't been able to find anything in the source referencing this bizarre
address. Of course 'View Source' doesn't keep up with dynamic
johnnyGRE wrote:
Hello,
How can I setup wicket on JDeveloper?
Can anyone help with a step-by-step guide specific on JDev?
I have tried but no luck so far.
I'm not sure what fancy setup you're looking for, but I've done a little
wicket in JDev (Version 10.1.3.2). Basically I add the
I have a short sleeve Wicket T-Shirt, but as the weather is about to get
colder, I would like a long-sleeve version. What would be the best way of
accomplishing this? Should I add the sleeves to a panel and add them to the
shirt container? Or should I extend the base shirt component and
Then perhaps I'm not understanding the code in wicket-ajax.js properly. If
you refer to code I copied into my first post, it appears that if the script
tag has an id attribute, then wicket-ajax.js calls
Wicket.Head.addJavascript() -- which I assume is what renders it on the page
-- but if it
That would require me to either implement markup inheritance or to place the
hidden field in the markup of all my extended forms, wouldn't it? I was
hoping to make all my form instances as ignorant of the base class as
possible, but I guess if I have to implement one of these solutions, it's
In my original message, I said I wanted to avoid a javascript solution. It
doesn't lend itself to reuability, e.g. if I have multiple submit buttons or
specialized submit buttons. A more cumbersome solution, in my opinion.
rmattler wrote:
You could do it with javascript. Disable the
This was pretty much the original solution I linked. The problem comes when
you don't call setResponsePage() and go right back to the page (e.g. if some
custom form validation fails). It can no longer be submitted, because the
boolean is stuck in a true state.
--
View this message in context:
Here's a solution that SEEMS to be working. It incorporates our solution to
the double submit problem that we used on our JSP's. It didn't appear to be
working for me at first, but seems to be now. (It does use the old servlet
request/session objects, but this may change once all our old code
I have an issue with DropDownChoice components with an attached
AjaxFormComponentUpdatingBehavior. After the ajax is processed the focus
doesn't properly get reset so when the user tabs, the focus jumps back to
the top of the page. It doesn't happen all the time, but most of the time
(the issue
19 matches
Mail list logo
