Focus not getting set after an ajax call
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 seems somewhat inconsistent and seems to happen more frequently for different fields). When the problem occurs, the ajax debug outputs "last focus id was not set". So apparently, for some reason, the focus id is not set on the ajax call, so it can't be reset properly after the call completes. Any reason why this is occurring and how to fix it? I was originally using wicket 1.3.1, but tried upgrading to 1.3.3, but this did not fix the issue. Thanks. Joel -- View this message in context: http://www.nabble.com/Focus-not-getting-set-after-an-ajax-call-tp17407105p17407105.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Javascript Header Contribution via Ajax
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 doesn't have an ID it calls eval() -- which wouldn't render it
to the page, but WOULD cause an alert() call in the javascript to be
executed.
If I could give it an ID, I would, but it's not a component and the script
tag is added by TextTemplateHeaderContributor (specifically through
JavaScriptTemplate). I suppose I could wrap my own solution that would
allow for the inclusion of an ID. I do understand that the ID is being used
to prevent duplicate javascript.
My Javascript isn't vary complex, basically it's in the form:
var ${var1} = default_value;
var ${var2} = default_value;
. . .
function ${function1}() {
. . .
}
function ${function2}() {
. . .
}
. . .
I know the javascript file isn't the problem, because it works fine for
components that are part of the initial page render. Just not for
components added via ajax.
I think I'm either going to rewrite my javascript so that I no longer need
to do variable replacement, therefore all instances of my custom behavior
can use the same static file without interfering with each other, or extend
TextTemplateHeaderContributor so I can include an ID on the script tag that
gets wrapped around my javascript.
Joel
Matej Knopp-2 wrote:
>
> If the javascript is evaluated that means it's added to page. What
> exactly is the difference here? And why can't you give it id? (id is
> used to filter out duplicate javascripts).
>
> What does the javascript look like?
>
> -Matej
>
> On Mon, Jul 13, 2009 at 9:28 PM, Joel Hill wrote:
>> I have a custom behavior that contributes Javascript to the header. In
>> order to prevent collisions with other components that may also be using
>> that behavior, I include it using TextTemplateHeaderContributor. Like
>> so:
>>
>> public class CustomBehavior extends AbstractBehavior {
>>
>> private Component component;
>>
>> . . .
>>
>> �...@override
>> public void bind(Component component) {
>> this.component = component
>> component.setOutputMarkupId(true);
>>
>> . . .
>>
>> component.add(TextTemplateHeaderContributor.forJavaScript(getClass(),
>> "javascriptSource.js", variables));
>> }
>>
>> }
>>
>>
>> This works great, unless I add this behavior to a component that gets
>> added to the page as part of an Ajax request. In that case, the
>> Javascript does not get added to the page, so when the component looks up
>> the Javascript it needs to function, it's not there.
>>
>> I'm not sure if this is related to
>> https://issues.apache.org/jira/browse/WICKET-618 or not, but that bug was
>> resolved 'Won't Fix'.
>>
>> I tried tracing through the Ajax code, and if I understand it properly,
>> the issue seems to come down to line 1445 of wicket-ajax.js:
>>
>> 1441 var text = Wicket.DOM.serializeNodeChildren(node);
>> 1442
>> 1443 var id = node.getAttribute("id");
>> 1444
>> 1445 if (typeof(id) == "string" && id.length > 0) {
>> 1446 // add javascript to document head
>> 1447 Wicket.Head.addJavascript(text, id);
>> 1448 } else {
>> 1449 try {
>> 1450 eval(text);
>> 1451 } catch (e) {
>> 1452 Wicket.Log.error(e);
>> 1453 }
>> 1454 }
>>
>>
>> It would appear that because the script tag generated by
>> TextTemplateHeaderContributor does not contain an 'id' attribute, the
>> javascript is not rendered on the page. (However it is still evaluated,
>> via line 1450, which explains why when I added an alert() call to my
>> javascript file, it got executed. Imagine my initial confusion.)
>>
>> Is this expected behavior? A bug? Is there a workaround? Am I even
>> interpreting the issue correctly? If I were using a static Javascript
>> file, I think there are calls I can use to include an 'id' attribute, and
>> I may have to rewrite my javascript so I can make it static (if
>> possible).
>>
>> Picking up on suggestions I read on the mailing list archives, I also
>> tried:
>>
>> public void renderHead(IHeaderResponse response) {
>>
>> response.renderOnDomReadyJavascript(TextTemplateHeaderContributor.forJavaScript(getClass(),
>> "popupBehavior.js", variables).toString());
>> }
>>
>> and:
>>
>> public void onRendered(Component component) {
>> if(RequestCycle.get().getRequestTarget() instanceof AjaxRequestTarget)
>> {
>> AjaxRequestTarget target = (AjaxRequestTarget)
>> RequestCycle.get().getRequestTarget();
>>
>> target.appendJavascript(TextTemplateHeaderContributor.forJavaScript(getClass(),
>> "popupBehavior.js", variables).toString());
>> }
>> }
>>
>> Neither alternative worked. At this point I'm not even sure they make
>> sense, but I tried them before I had dug in and (hopefully) traced down
>> the problem.
>>
>> Thank you for any help that anyone
Re: wicket-event.js returning unreadable
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 resource.UrlResourceStream (:92) - cannot convert url: code-source:/C:/oc4j10132/j2ee/home/applications/mcir/wicket-1.3.0-beta2.jar!/org/apache/wicket/markup/html/wicket-event.js to file (URI scheme is not "file"), falling back to the inputstream for polling I'm hoping it will give me some clue as to what is going on, but maybe it's just another by-product of the problem. Any suggestions were be great. Thanks. Joel -- View this message in context: http://www.nabble.com/wicket-event.js-returning-unreadable-tf4158501.html#a11989377 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: wicket-event.js returning unreadable
I'm using OC4J 10.1.3.2, I believe it's 32-bit. I've tried it with both FF2
and IE6. I'm not sure about the response headers, because when I use my
tool for extracting the headers (NetTool 4.7.0) it seems to work fine, so
I'm not sure the headers are the same as when it doesn't work. Unless
there's some simple thing I can override in wicket to intercept the response
headers (which there probably is). Maybe that happens because technically
NetTool becomes my webserver at that point (with oc4j being NetTool's
webserver). That would seem to indicate even more that it's an Oracle
problem.
As for "junk" I mean the js file returns as random ascii, like it's binary
data.
I think I tried disabling wicket compression once before, with no success.
But I'll try that again just to make sure. I'll also see if I can tinker
with Oracle's settings.
Thanks for the suggestions, I'll let you know how it works out.
Joel
Matej Knopp-2 wrote:
>
> Well, oracle app server doesn't have a good reputation exactly for
> messing the output. Try disabling the compression of wicket resources
> completely,
>
> Application.getResourceSettings.setDisableGZipCompression(true).
>
> -Matej
>
> On 8/3/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
>> Seems like Oracle application server, version 10.1, 32 bits?
>>
>> Apparently the classloader for the app server converts the
>> getClass().getResourceAsStream("wicket-event.js")
>> to use a "code-source:" protocol. I'm not sure, but it sounds like a
>> security constraint in your setup.
>>
>> Martijn
>>
>> On 8/3/07, Matej Knopp <[EMAIL PROTECTED]> wrote:
>> > I doubt this is related. What app server are you using? What exactly
>> > does it mean junk? Wha headers are set on ouput? What browser are you
>> > using?
>> >
>> > -Matej
>> >
>
>
--
View this message in context:
http://www.nabble.com/wicket-event.js-returning-unreadable-tf4158501.html#a12015983
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: wicket-event.js returning unreadable
Well I have the compression filter turned off now, so that shouldn't be the
problem. And I'm not trying to dynamically include a js file, but create
dynamic js which runs onload:
response.renderOnLoadJavascript("some js code");
However, your suggestion inspired me to take a second look at the API for
IHeaderResponse and I think I've figured out a workaround. If I use
renderJavascript() it doesn't include the js file from wicket, then I can
just manually write my own onload handler which utilizes the output from the
renderJavascript() call. I'm fairly confident that should cover me for
almost any situation that comes up. It may not always be the cleanest code,
but it's better than wasting hours getting oc4j (assuming it's oc4j's fault)
to behave.
Thanks for the suggestion, it may have indirectly solved my problem.
Joel
Alex Objelean wrote:
>
> I've got the same problem. A quick fix for you can be give-up using
> home-grown compression filter or instead of using IHeaderContributor to
> include dynamic Javascript:
>
> [code]
> public void renderHead(final IHeaderResponse response) {
> response.renderJavascriptReference(new JavascriptResourceReference(
> WicketApplication.class, "ref/javascriptFile.js"));
> }
> [/code]
>
> include the JS this way:
>
> [code]
> add(new JavaScriptReference("js.markupId",
> WicketApplication.class, "ref/javascriptFile.js"));
> [/code]
>
> I do not understand the difference between these two methods of adding
> JavascriptReference object (maybe this is related to gzip compression used
> by wicket), but I've noticed that this makes the difference.
>
> PS: I use for compression the
> http://sourceforge.net/project/showfiles.php?group_id=195642 Resource
> Accelerate project. I find it very useful.
>
>
> hillj2 wrote:
>>
>> I'm using IHeaderContributor to include dynamic Javascript; however,
>> wicket-event.js is returning to the browser as unreadable garbage. I
>> think it MAY have something to do with compression. Our app uses a
>> home-grown compression filter, and I also read today that wicket uses
>> default compression too. I tried disabling one or the other or both but
>> this didn't work UNLESS I was using NetTool, which basically acts as a
>> request intercept that spits out the request/response headers. I
>> wouldn't expect NetTool to modify the request/response at all, but for
>> some reason if I have at least one of the compression filters disabled
>> AND go through NetTool wicket-event.js returns fine.
>>
>> I also get this in my log output when the js file fails to return
>> properly:
>>
>> DEBUG 2007-07-27 10:54:19,156 locator.ResourceStreamLocator
>> (locateByResourceFinder:197) - Attempting to locate resource
>> 'org/apache/wicket/markup/html/wicket-event.js' on path [folders = [],
>> webapppaths: []]
>> DEBUG 2007-07-27 10:54:19,156 locator.ResourceStreamLocator
>> (locateByClassLoader:166) - Attempting to locate resource
>> 'org/apache/wicket/markup/html/wicket-event.js' using classloader
>> mcir.root:0.0.0
>> DEBUG 2007-07-27 10:54:19,156 resource.UrlResourceStream (:92) -
>> cannot convert url:
>> code-source:/C:/oc4j10132/j2ee/home/applications/mcir/wicket-1.3.0-Beta-20070606.jar!/org/apache/wicket/markup/html/wicket-event.js
>> to file (URI scheme is not "file"), falling back to the inputstream for
>> polling
>>
>>
>> What makes it even more odd is I've used IHeaderContributor in another,
>> far simpler app before and it's worked fine.
>>
>> Thanks.
>>
>> Joel
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>>
>
>
--
View this message in context:
http://www.nabble.com/wicket-event.js-returning-unreadable-tf4158501.html#a12018207
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: wicket-event.js returning unreadable
Disabling wicket resource compression did not solve my issue, however I may
have a workaround that's faster than tinkering with oc4j's settings, which
I'm not an expert on. See my response to Alex's suggestion for details.
Joel
hillj2 wrote:
>
> I'm using OC4J 10.1.3.2, I believe it's 32-bit. I've tried it with both
> FF2 and IE6. I'm not sure about the response headers, because when I use
> my tool for extracting the headers (NetTool 4.7.0) it seems to work fine,
> so I'm not sure the headers are the same as when it doesn't work. Unless
> there's some simple thing I can override in wicket to intercept the
> response headers (which there probably is). Maybe that happens because
> technically NetTool becomes my webserver at that point (with oc4j being
> NetTool's webserver). That would seem to indicate even more that it's an
> Oracle problem.
>
> As for "junk" I mean the js file returns as random ascii, like it's binary
> data.
>
> I think I tried disabling wicket compression once before, with no success.
> But I'll try that again just to make sure. I'll also see if I can tinker
> with Oracle's settings.
>
> Thanks for the suggestions, I'll let you know how it works out.
>
> Joel
>
>
>
> Matej Knopp-2 wrote:
>>
>> Well, oracle app server doesn't have a good reputation exactly for
>> messing the output. Try disabling the compression of wicket resources
>> completely,
>>
>> Application.getResourceSettings.setDisableGZipCompression(true).
>>
>> -Matej
>>
>> On 8/3/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
>>> Seems like Oracle application server, version 10.1, 32 bits?
>>>
>>> Apparently the classloader for the app server converts the
>>> getClass().getResourceAsStream("wicket-event.js")
>>> to use a "code-source:" protocol. I'm not sure, but it sounds like a
>>> security constraint in your setup.
>>>
>>> Martijn
>>>
>>> On 8/3/07, Matej Knopp <[EMAIL PROTECTED]> wrote:
>>> > I doubt this is related. What app server are you using? What exactly
>>> > does it mean junk? Wha headers are set on ouput? What browser are you
>>> > using?
>>> >
>>> > -Matej
>>> >
>>
>>
>
--
View this message in context:
http://www.nabble.com/wicket-event.js-returning-unreadable-tf4158501.html#a12018236
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: RequestDispather.forward()
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 it's running under the servlet/jsp app's path and not the wicket path, which is causing its own issues. I think I'd almost rather accomplish this using a redirect instead; however our reverse proxy seems to have issues with redirects. I already had to switch to one pass rendering because of it. Maybe one of these days someone will actually figure out that issue and fix it. Too bad I don't have access to it. If you want something done right...or at all sometimes...you have to do it yourself. :) If only I had time to convert the whole app over to wicket now; but I don't. But enough venting on the mailing list. Thanks for the help, Eelco. Joel Eelco Hillenius wrote: > >> Would the fact that wicket now uses a filter instead of a servlet have >> an effect on trying to forward a request. I'm trying to forward a >> request from the jsp/servlet portion of our app to a bookmarkable wicket >> page using RequestDispatcher.forward(), but no matter what sort of path >> I send it, I get a null value when trying to create my RequestDispatcher >> object. >> >> My wicket filter is mapped to /wicket/*, and as an experiment I tried >> to forward to my app's home page. I tried passing "/wicket/", >> "wicket/", and even "/wicket" (which shouldn't work), an neither case >> allowed me to create a RequestDispatcher (using >> request.getRequestDispatcher()). If I simply pass "/" id does forward >> to my app's welcome page, and I think even passing a path for my servlet >> (where the forward is occuring--or trying to at least) is recognized; >> but I can't get it to recognize the wicket app. >> >> I tried including >> >> REQUEST >> FORWARD >> >> in the filter-mapping of my web.xml, since it looked like that might >> solve it, but no luck. It would be nice if I could find some way to >> redirect from the old servlet back to wicket, but I haven't figured it >> out yet. I've started experimenting with response.senRedirect(), but so >> far that's not looking promising either. Why won't my app server >> recognize my wicket path? Thanks. >> >> >> Joel >> >> P.S. If someone tells me they think it's oc4j again (my app server) I >> think I may cry. lol > > No idea. You can still use a servlet with Wicket 1.3 if you want to > test whether that makes the difference (sounds very unlikely to me, > but if you test it you can make sure) and if you think it might be > oc4j, you can simply test it with another servlet container and see > whether the same problem exists. > > Eelco > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/RequestDispather.forward%28%29-tf4251039.html#a12130211 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can we do straight print in a java web application?
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 use a product called pdflib (not free). By inserting PDF javascript you can get a PDF document to print silently (no print dialog). The trick being you have to somehow open the PDF first. In our app we just have a print link that generates a PDF and spits it to the printer without the user having to even see the document first. We just load the PDF into a hidden IFRAME and on the document load the embedded javascript calls the print command. Do some research on JS for PDFs. It's been a while since I've dealt with that code, so I'm a bit rusty on it. Also it can be a bit cumbersome to get it working the way you want it, depending on your exact usecase. But it may be just what you're looking for. Good luck. Joel Martijn Dashorst wrote: > > Just think about it for 1 minute why this isn't available... (anwser > below). > > Martijn > > > > Spam is of all ages, I figure that even in the clay tablet era people > would create ads for enlargements of various body parts (just use a > bigger nail!). So before e-mail was the prevalent means of spreading > ads, the fax machine (documents sent through the phone line in an > analog/copier type of fashion) was churning out forrests of (unwanted) > ads. > > Now imagine a website hosted by Nigerian/Russian/Chinese/Dutch > spammers. They would *love* a way to directly print documents without > interventioni on the user's part. > > -- > Wicket joins the Apache Software Foundation as Apache Wicket > Apache Wicket 1.3.0-beta2 is released > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta2/ > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/Can-we-do-straight-print-in-a-java-web-application--tf4289452.html#a12235547 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: wicket-event.js returning unreadable
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 (FF suddenly seemed to work fine) but only with the IE on MY computer, I ended up clearing IE's temporary internet files. Problem solved. So IE cached the double compressed version of the js file and kept it in cache for several weeks until I manually deleted it. For now it's looking like the problem is solved. (Thanks, Microsoft, for introducing the world to permanent temporary internet files.) Joel -- View this message in context: http://www.nabble.com/wicket-event.js-returning-unreadable-tf4158501.html#a12478274 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Refresh a page from an AjaxButton?
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() );
>
> The only problem I am having now is that ModalWindow has an annoying "are
> you sure you want to navigate away from this page" JavaScript confirm
> since the modal window is open when the browser tries to move on. Maybe
> there's something in the API to disable that warning...
>
>
I had this exact same problem but found my own way around it. I'm using a
page for my modal window (so it probably would work a bit different if
you're using a Panel). When I create my modal, I pass the parent page to
the constructor and store that as a member variable as well as the
ModalWindow object. In the onSubmit handler of my ajax submit button I do:
if(/*Custom form vaidation*/) {
/* Submit form data */
parent.setSubmitted(true); // this sets a variable in the parent class
that is initialized to false
modalWindowObject.close(target);
} else {
target.addComponent(ModalWindowForm.this); // The allows you to see the
feedback panel inside the modal window, assuming it is inside the form
}
Then in the onClose handler of my modal window:
if(isSubmitted()) { // Checks the member variable the modal window set on
submit (keeps whole page from refreshing if you close modal by other means)
setResponsePage(ModalWindowParent.class);
}
The code may vary depending on your specific setup (particularly if you're
using a panel instead of a page for you modal window), but I think it should
be workable. Not sure how it will work with wicket's built-in validators,
because I currently don't use those.
I spent quite some time trying to figure out how to do this, so I hope it
benefits others. Seems to be the best way of handling a page modal which
has an internal feedback panel, which refreshes the whole page on a
successful submit, but not on a failure (or other close modal events). It
also avoids the annoying popup, since you're directly calling the close
function.
Joel
--
View this message in context:
http://www.nabble.com/Refresh-a-page-from-an-AjaxButton--tf4469626.html#a12756667
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Embedding wicket in jsp error
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 tag. oc4j throws a ServletException: Error in Servlet,
with no further information specifying the problem, nor any indication from
wicket that it's having a problem. To isolate the problem I tried to
recreate it in a very small app, so I could rule out any issue with other
app code/configurations. This time, I get a more informative (but not
necessarily more helpful) error message:
java.lang.IllegalStateException: Response has already been committed, be
sure not to write to the OutputStream or to trigger a commit due to any
other action before calling this method.
I'm hoping it's the same error in both cases, and the former case just has a
more generic error message for some reason; but I was hoping someone might
have a clue why I can't get the embedding to work. I'm using oc4j 10.1.3.3,
and wicket beta2. I tried it on Tomcat also. It didn't throw an error, but
the place where the wicket content should be was just empty.
I'd prefer not to have to do this with embedded IFRAME's as I've seen
suggested. That's the setup I have now, but when a page loads there's a
delay loading the IFRAME content, which doesn't look very nice, especially
since the embedded content is my app's navigation menu. Any thoughts,
suggestions, alternate solutions to the embedding issue?
Here's the code from my small test app:
embed.jsp
Embed test
Here is my JSP content
EmbedServlet.java
==
public class EmbedServlet extends HttpServlet {
public void doGet(HttpServletRequest request, HttpServletResponse
response)
throws ServletException, IOException {
doPost(request, response);
}
public void doPost(HttpServletRequest request, HttpServletResponse
response)
throws ServletException, IOException {
RequestDispatcher rd =
request.getRequestDispatcher("/WEB-INF/jsp/embed.jsp");
rd.forward(request, response);
}
}
EmbedApplication.java
=
public class EmbedApplication extends WebApplication {
public EmbedApplication() {
super();
}
public Class getHomePage() {
return EmbedPage.class;
}
protected void init() {
System.out.println("* Wicket App initialized *");
}
}
EmbedPage.java
public class EmbedPage extends WebPage {
public EmbedPage() {
super();
}
}
EmbedPage.html
Embeded Wicket
Here is my wicket content.
web.xml
==
http://java.sun.com/j2ee/dtds/web-app_2.2.dtd";>
http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"; version="2.5"
xmlns="http://java.sun.com/xml/ns/javaee";>
EmbedServlet
EmbedServlet
EmbedServlet
/main
EmbedApplication
org.apache.wicket.protocol.http.WicketServlet
applicationClassName
EmbedApplication
EmbedApplication
/wicket/*
35
html
text/html
txt
text/plain
Thanks,
Joel
--
View this message in context:
http://www.nabble.com/Embedding-wicket-in-jsp-error-tf4488872.html#a12801646
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Embedding wicket in jsp error
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. I changed the render strategy on the test app and got the same error. Martijn Dashorst wrote: > > - don't use oc4j, or at least look at the threads on this list, as > there have been more problems with oc4j and Wicket. > I know, several of those posts are probably mine. :) Frankly I've been about ready to chuck oc4j myself, but it's not my call. Although it may come to it if we finally reach a problem that has no workaround. However, when I ran the app in Tomcat it also didn't work, so it doesn't look to be an oc4j specific problem this time (I'm as shocked as you are). -- View this message in context: http://www.nabble.com/Embedding-wicket-in-jsp-error-tf4488872.html#a12803370 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Embedding wicket in jsp error
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: > http://herebebeasties.com/2007-03-01/jsp-and-wicket-sitting-in-a-tree/ > > It comes at things from slightly the other end of the spectrum > (embedding JSPs in a Wicket page) but the issues are very similar and > you should find it interesting reading. > > You'll probably discover that you want to migrate your template stuff to > Wicket anyway at some point, in which case this is the approach you'll > need to adopt anyway. > I have seen your blog before. I was even skimming over it again today earlier. I'll have to sit down and read it thoroughly to see what it will entail to implement, and how long it will take. I'd love to migrate everything to wicket right now, but it's an very large app and we barely have time to implement the new component we're working on now (which IS all wicket). Thanks for the help. And thanks to Martijn as well. Joel -- View this message in context: http://www.nabble.com/Embedding-wicket-in-jsp-error-tf4488872.html#a12803501 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Embedding wicket in jsp error
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 servlet context rather than under the wicket context (the url's seem to bear that out, however it's still getting back to wicket when I click on them). However, some of the wicket links on my main wicket page (with no embedded JSP) were throwing page expired errors too, but not always. I haven't figured out yet when they will and when they won't. I may have to revert to the ugly, slow loading IFRAMEs solution, because nothing else seems to work for me. This comes out in the logs anytime I get the page expired error: DEBUG 2007-09-21 13:54:57,359 http.FilePageStore (getPage:504) - Error loading page 90,0 for the sessionid 0a080b5722b83ac0afe2682449908b03d150131b49d7 from disk java.lang.RuntimeException: Could not deserialize object using `org.apache.wicket.util.io.IObjectStreamFactory$DefaultObjectStreamFactory` object factory at org.apache.wicket.util.lang.Objects.byteArrayToObject(Objects.java:410) at org.apache.wicket.protocol.http.FilePageStore.readPage(FilePageStore.java:541) at org.apache.wicket.protocol.http.FilePageStore.getPage(FilePageStore.java:484) at org.apache.wicket.protocol.http.SecondLevelCacheSessionStore$SecondLevelCachePageMap.get(SecondLevelCacheSessionStore.java:192) at org.apache.wicket.Session.getPage(Session.java:725) at org.apache.wicket.request.AbstractRequestCycleProcessor.resolveRenderedPage(AbstractRequestCycleProcessor.java:427) at org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:139) at org.apache.wicket.RequestCycle.step(RequestCycle.java:1090) at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1176) at org.apache.wicket.RequestCycle.request(RequestCycle.java:499) at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:257) at org.apache.wicket.protocol.http.WicketServlet.doGet(WicketServlet.java:126) at javax.servlet.http.HttpServlet.service(HttpServlet.java:743) at javax.servlet.http.HttpServlet.service(HttpServlet.java:856) at com.evermind.server.http.ServletRequestDispatcher.invoke(ServletRequestDispatcher.java:713) at com.evermind.server.http.ServletRequestDispatcher.forwardInternal(ServletRequestDispatcher.java:370) at com.evermind.server.http.ServletRequestDispatcher.unprivileged_forward(ServletRequestDispatcher.java:259) at com.evermind.server.http.ServletRequestDispatcher.access$100(ServletRequestDispatcher.java:51) at com.evermind.server.http.ServletRequestDispatcher$2.oc4jRun(ServletRequestDispatcher.java:193) at oracle.oc4j.security.OC4JSecurity.doPrivileged(OC4JSecurity.java:283) at com.evermind.server.http.ServletRequestDispatcher.forward(ServletRequestDispatcher.java:198) at gov.mi.mdch.event.EventHandlerBase._dispatch(EventHandlerBase.java:153) at gov.mi.mdch.event.EventHandlerBase.forward(EventHandlerBase.java:137) at gov.mi.mdch.event.Controller.doPost(Controller.java:128) at gov.mi.mdch.event.Controller.doGet(Controller.java:81) at javax.servlet.http.HttpServlet.service(HttpServlet.java:743) at javax.servlet.http.HttpServlet.service(HttpServlet.java:856) at com.evermind.server.http.ResourceFilterChain.doFilter(ResourceFilterChain.java:65) at gov.mi.mdch.filter.ValidationFilter.doFilter(ValidationFilter.java:241) at com.evermind.server.http.ServletRequestDispatcher.invoke(ServletRequestDispatcher.java:623) at com.evermind.server.http.ServletRequestDispatcher.forwardInternal(ServletRequestDispatcher.java:370) at com.evermind.server.http.HttpRequestHandler.doProcessRequest(HttpRequestHandler.java:871) at com.evermind.server.http.HttpRequestHandler.processRequest(HttpRequestHandler.java:453) at com.evermind.server.http.HttpRequestHandler.serveOneRequest(HttpRequestHandler.java:221) at com.evermind.server.http.HttpRequestHandler.run(HttpRequestHandler.java:122) at com.evermind.server.http.HttpRequestHandler.run(HttpRequestHandler.java:111) at oracle.oc4j.network.ServerSocketReadHandler$SafeRunnable.run(ServerSocketReadHandler.java:260) at com.evermind.util.ReleasableResourcePooledExecutor$MyWorker.run(ReleasableResourcePooledExecutor.java:303) at java.lang.Thread.run(Thread.java:595) Caused by: java.io.StreamCorruptedException: unexpected block data at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1313) at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1912) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:18
Re: Embedding wicket in jsp error
Martijn Dashorst wrote:
>
> Does your log contain serialization errors? That typically is a
> problem with trying to deserialize a page from the disk store.
>
Well the stack trace I posted seems to indicate a serialization problem.
But there is nothing further in the logs that I didn't already post.
Martijn Dashorst wrote:
>
> You may want to switch your session store to the HttpSessionStore, if
> you don't mind having a limited back button support. Or at least you
> can try it, to see if it solves the problem. If so, you have a
> serialization problem in your component structure.
>
I added
protected ISessionStore newSesionStore() {
return new HttpSessionStore(this);
}
to my application class, but I still got the same error.
Joel
--
View this message in context:
http://www.nabble.com/Embedding-wicket-in-jsp-error-tf4488872.html#a12827823
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Embedding wicket in jsp error
My mistake. I noticed there was a typo in my newSessionStore() declaration which caused it not to be called (obviously). Now that I have ACTUALLY gotten wicket to use HttpSessionStore, it did solve my problem. So how can I track down exactly what couldn't serialize so I can fix it (hopefully)? Also are there any other issues with using HttpSessionStore besides losing back button support? Since I'm already forced to use ONE_PASS_RENDER (for now), I've already lost that support (haven't I?). Thanks, Joel -- View this message in context: http://www.nabble.com/Embedding-wicket-in-jsp-error-tf4488872.html#a12829244 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Embedding wicket in jsp error
Eelco Hillenius wrote: > > One of the better additions to the JDK in my opinion were the > @Override tags. If you use those (and e.g. use your IDE's autocomplete > function) you would have avoided this in the first place. > Yeah, I should probably start using more of that real nice stuff they put so much effort into providing us. I guess I never realized that annotation actually would check to make sure you were really overriding something. Thanks. Joel -- View this message in context: http://www.nabble.com/Embedding-wicket-in-jsp-error-tf4488872.html#a12829555 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Embedding wicket in jsp error
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 default store for wicket 1.2 and prior. It > only limits the number of pages that are stored per session for > backbutton support. So you will be able to press back, but not > unlimited as with the disk based store. > Well that doesn't bother me. The users really shouldn't need to press the back button at all, so only having a limited number of previous pages shouldn't be a problem. Martijn Dashorst wrote: > > As for the serialization errors, somehow either you don't read the log > too well, or you have a misconfigured Wicket. To fix them, you should > return to the Disk store: it will report exactly what is wrong. Do you > run the application in development mode on your local box? If so, you > should see things like the following in your log: > > ERROR - Objects - Error serializing object class wicket.in.action.HomePage > > Field hierarchy is: > 0 [class=wicket.in.action.HomePage, path=0] > children [class=[Lorg.apache.wicket.Component;] > children[0] [class=org.apache.wicket.markup.html.basic.Label, > path=0:name] > model [class=org.apache.wicket.model.PropertyModel] > target [class=wicket.in.action.User] <- field that is > not serializable > at org.apache.wicket.util.io.SerializableChecker.check() > at org.apache.wicket.util.io.SerializableChecker.checkFields() > Well I thought what I put in the original post was all that I could see in the logs regarding this issue. I'll try again and see if I notice more, or fiddle with some of the config, if I can figure out what to change. I probably won't get to this until Mon though. I'll let you know what I discover. Thanks, Joel -- View this message in context: http://www.nabble.com/Embedding-wicket-in-jsp-error-tf4488872.html#a12829549 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Security message when using popup dialog
I'm using wicket's popup dialog and it works just fine, but when deploy my app to our test server, which sits behind a proxy using SSL, I get a security message from IE saying "This page contains both secure and nonsecure items" whenever I open the popup. I've traced it to a 404 error which is returning from a request to SERVLET_PATH/://0. I have no idea where this request is coming from or what resource "://0" is supposed to refer to. This request doesn't appear to get made when I run it on my local machine (of course I'm not using SSL, but I also don't ever see this request get made to my local webserver). Any idea what this path is supposed to be or where it's getting called from? This is wicket 1.3 beta2. Thanks. Joel -- View this message in context: http://www.nabble.com/Security-message-when-using-popup-dialog-tf4720449.html#a13494917 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Security message when using popup dialog
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 changes made to the HTML document. Here is the request header that I think is causing the problem: GET /dch-apps/mcir/wicket/://0 HTTP/1.1 Accept: */* Referer: https://localhost:7000/dch-apps/mcir/wicket/;jsessionid=cc1740a122b817d48694251b4c9ebfa7f4cb98e303e4?wicket:interface=modal-dialog-pagemap:0 Accept-Language: en-us Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322) Host: localhost:7000 Connection: Keep-Alive Cookie: PD-S-SESSION-ID=2_3Up0h124Sdjoiwp2xtcs6noIRVFNPvCGgyexh+nKYigzh-Xr; AMWEBJCT!%2Fsom!JSESSIONID=86sQ6Yf_BcJ3mqzjMZdxO1g:-1; PD_STATEFUL_e7b6e27e-0ebe-11dc-b6c7-cc17401eaa77=%2Fsom; IV_JCT=%2Fdch-apps; AMWEBJCT!%2Fdch-apps!JSESSIONID=cc1740a122b817d48694251b4c9ebfa7f4cb98e303e4 And here is the corresponding response: HTTP/1.1 404 Not Found content-type: text/html date: Wed, 31 Oct 2007 12:53:18 GMT p3p: CP="NON CUR OTPi OUR NOR UNI" server: Oracle Containers for J2EE x-old-content-length: 148 transfer-encoding: chunked 94 404 Not Found404 Not FoundResource /dch-apps/mcir/wicket/:/0 not found on this server 0 Don't let the "localhost:7000" throw you. That's just because I'm routing the request through a program which allows me to capture to request/response headers. It doesn't appear that this same request is being made in FF though. Martijn Dashorst wrote: > > And please check if you have images without a src attribute or an > empty src attribute. That seems to cause problems too (though possibly > not this one). > No image tags to check in this case. Aside from the images used by the wicket popup, there's only one image on the page at all and it's added via css. We're not really allowed to use graphics in this app (boring). Thanks for the help. Joel -- View this message in context: http://www.nabble.com/Security-message-when-using-popup-dialog-tf4720449.html#a13509156 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JDeveloper and Wicket
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 wicket jar to the list of libraries, and then go into project properties and under the Compiler options add all the extensions of files in my classpath to the list of extensions under the "Copy File Types to Output Directory" option (.html, .properties, etc.). This makes sure files like you markup files stay in the proper directory for deployment. Then I just develop like I would any other web app. The only annoying part is when I add a new html file (make sure you add it to the proper directory on your classpath and not the default web folder, unless your wicket is setup to look for markup on something other than the classpath). Since I'm not adding to the default web folder, JDev decides to add that directory to the list of resources. Simple to remove in the project properties (under Project Content > Resources), but annoying to have to do it for each new html file. Hopefully that helps. Good luck. Joel -- View this message in context: http://www.nabble.com/JDeveloper-and-Wicket-tf4730313.html#a13527949 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket merchandise? - T-Shirt problem
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 include the sleeves in the child markup? Joel -- View this message in context: http://www.nabble.com/Wicket-merchandise--tp19066811p19089785.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Double submit problem
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 better than having it not work at all. I assume the "input" variable is the value of the hidden field? Also, if the validation fails, can I still send the user to a custom error page instead of just putting an error message in the feedback panel? Sorry, I haven't dealt much with validators. I usually just validate form data manually in onSubmit. I'll start working with this solution and see what I can come up with. OnUnload isn't working our for me so far. Partly because I can't attach the event to the page with the way my code is currently set up. Thanks for the suggestion. Joel -- View this message in context: http://www.nabble.com/Double-submit-problem-tp15957979p15976496.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Double submit problem
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 button and change the button
> label.
>
> function saveForm(btn) {
> eForm = document.forms[0];
> btn.disabled=true;
> btn.value='Please wait...';
> eForm.submit();
> return;
>
> }
>
>
>
--
View this message in context:
http://www.nabble.com/Double-submit-problem-tp15957979p15988774.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Double submit problem
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: http://www.nabble.com/Double-submit-problem-tp15957979p15988777.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Double submit problem
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 is
upgraded to wicket.)
public abstract class NoDoubleSubmitForm extends Form {
private String token;
protected NoDoubleSubmitForm(String id) {
super(id);
}
protected NoDoubleSubmitForm(String id, IModel model) {
super(id, model);
}
protected abstract void onSubmitted();
protected void onResubmitted() {
setResponsePage(CustomErrorPage.class);
}
@Override
protected final void onSubmit() {
if(isValidToken())
onSubmitted();
else
onResubmitted();
}
@Override
protected void onBeforeRender() {
super.onBeforeRender();
saveToken();
}
private boolean isValidToken() {
HttpServletRequest request = ((WebRequestCycle)
RequestCycle.get()).getWebRequest().getHttpServletRequest();
if (!isTokenValid(request)) {
Token.resetToken(request); // Removes unique token string from
session
return false;
}
Token.resetToken(request); // Removes unique token string from session
return true;
}
public boolean isTokenValid(HttpServletRequest request) {
// Retrieve the saved transaction token from our session
HttpSession session = request.getSession(false);
if (session == null)
return false;
String saved = (String)
session.getAttribute(Token.TRANSACTION_TOKEN_KEY);
if (saved == null)
return false;
if (token == null)
return false;
// Do the values match?
return saved.equals(token);
}
private void saveToken() {
HttpServletRequest request = ((WebRequestCycle)
RequestCycle.get()).getWebRequest().getHttpServletRequest();
HttpSession session = request.getSession();
Token.saveToken(request); // Generates a unique string for this request
and stores it in session
token = (String) session.getAttribute(Token.TRANSACTION_TOKEN_KEY); //
Save the generated token in this page instance
}
}
Like I said, for now this appears to be working. I just extend all my forms
from this class and implement onSubmitted() with the same code I previously
put in onSubmit(). The key is putting matching unique strings in session
and in the page instance. On submit, those string should match, at which
point, the string in session is cleared and the form is processed as normal.
If another submit comes in, the string in session has been cleared so it
doesn't match the string svaed in the page instance. In the case where
setResponsePage is not called, onBeforeRender resets the token string, so
submitting from the refreshed page won't register as an error.
Our JSP version of this involves putting the token string in session and
also saving a copy to a hidden field on the JSP page. Which I think is
similar (although maybe a bit more complex) to what Martijn was suggesting.
Thanks for all you suggestions.
Joel
--
View this message in context:
http://www.nabble.com/Double-submit-problem-tp15957979p16002307.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
