Javascript Header Contribution via Ajax
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:
1441var text = Wicket.DOM.serializeNodeChildren(node);
1442
1443var id = node.getAttribute(id);
1444
1445if (typeof(id) == string id.length 0) {
1446 // add javascript to document head
1447 Wicket.Head.addJavascript(text, id);
1448} else {
1449 try {
1450eval(text);
1451 } catch (e) {
1452Wicket.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 can provide on this issue.
Joel
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Disabling RadioGroup via authorization strategy does not disable contained Radio buttons
Done: https://issues.apache.org/jira/browse/WICKET-1843 I've also attached a fix, although I haven't tested it exactly as written, because I didn't feel like recompiling wicket. Joel Igor Vaynberg [EMAIL PROTECTED] 9/19/2008 1:50 PM create a jira issue for this -igor On Fri, Sep 19, 2008 at 7:11 AM, Joel Hill [EMAIL PROTECTED] wrote: I'm doing some component-based authorization and I'm trying to disable an entire RadioGroup without having to tie the authorization to each individual Radio button. Were I to directly disable the RadioGroup, it looks like the Radio buttons would also disable (but I haven't tested this); but it will not disable all the choices when I tie an authorization strategy to the RadioGroup. I'm working with wicket 1.3.3, so has this problem been addressed in a later versoin, and if not, is there some reason we might not want to do this? Thanks. Joel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Disabling RadioGroup via authorization strategy does not disable contained Radio buttons
I'm doing some component-based authorization and I'm trying to disable an entire RadioGroup without having to tie the authorization to each individual Radio button. Were I to directly disable the RadioGroup, it looks like the Radio buttons would also disable (but I haven't tested this); but it will not disable all the choices when I tie an authorization strategy to the RadioGroup. I'm working with wicket 1.3.3, so has this problem been addressed in a later versoin, and if not, is there some reason we might not want to do this? Thanks. Joel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Double submit problem
I'm trying to prevent the double submit problem, where the user clicks the submit button more than once causing a double post. I tried implementing the soluion suggested here: http://www.nabble.com/Re%3A-double-form-submission-handling---p13850262.html The problem is if there's a validation error and the user gets sent back to the same page (without a call to setResponsePage), the page still registers as submitted, so when the user fixes the form and submits, it's stuck in the resubmit state (which in my case sends the user to an error page). I even have one page where I don't call setResponsePage on a successful submit, because it just returns to that same page after a submit because there's a lot of overhead in constructing the page the first time. I don't want the submit to take a long time. I tried resetting the submitted boolean during the submit process, but no matter where I could find to put that code, it always seems to get executed before the 2nd submit get processed by wicket. I'd prefer not to implment a javascript solution (e.g. disabling the submit button after the first click), becuase I think the soultion linked above lends itself better to reusability across any form. So is there any way to differentiate between a double submit situation, and simply not calling setResponsePage? Or is there anywhere in wicket I can reset the submitted flag AFTER the double submit has begun to process (I'd prefer not to implement an artificial timer to reset the flag after a hard-coded number of seconds). Some point in the request cycle that occurs after the old page is unloaded? Now that I think about it, maybe some ajax that fires on the onunload event would be appropriate here. I'll try that while I wait to see of anyone has any better suggestions. Thanks. Joel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Dynamically adding component and associated markup
I'm trying to implement a popup (via floating DIV) that triggers on an onmouseover event. Sort of like a tooltip, but with more content. I wanted to implement this as a behavior so the component with the mouse event (and the associated markup file) didn't need to have any special knowledge of the popup code. The problem with doing it this way is I need not only to dynamically add the markup to contain the popup, but also attach a component to this dynamic markup. I can get the markup to generate, but even if I output a wicket:id attribute, it doesn't recognize it was wicket markup. I'm guessing that's because it's past the point where the markup is processed and bound to wicket (if that's the right way to describe it). I've already spent too much time on this, and have begun working on a new idea (which should work, but isn't nearly as cool), but I just wanted to know if anyone knew of a way of attaching markup and an associated component inside a behavior. If there is no quick and easy answer, that's ok, I'll move on. Because I can't spend any more time on this, I just need to get something to work (which I think I can with a slightly different approach). But it would have been slick to get this to work simply by adding a behavior, but I think I may have to go one step further and actually add the markup myself to the html file. Thank you for your time. Joel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Ajax error with AjaxFormSubmitBehavior
I'm trying to use AjaxFormSubmitBehavior, and in the ajax debug I'm
getting:
ERROR: Received Ajax response with code: 404
Anyone know what this means? Nothing in the logs indicates a problem,
but maybe I'm not using AjaxFormSubmitBehavior properly. I'm trying to
wicketify a javascript-based calendar control I wrote in my pre-wicket
days, since I'm not sure I liked the out-of-the-box implementation of
the date picker (maybe there are some customization options available
for it, I haven't checked).
My CalendarControl class is a FormComponentPanel which contains a
TextField, button (implemented as an AjaxLink) which opens the calendar,
and a ModalWindow which contains the actual calendar. The ModalWindow
contains a page, which contains a single form. In the form constructor
I call:
add(new AjaxFormSubmitBehavior(onsubmit) {
@Override
protected void onSubmit(AjaxRequestTarget target) {
logger.debug(* Running the onSubmit handler);
CalendarControl.this.date = formDate; // Updating the
CalendarControl's model with the form's model data
target.addComponent(CalendarControl.this);
calendar.close(target); // calendar is the ModelWindow
object, obviously
}
});
I add the ajax behavior to the form itself, since the calendar page is
created almost entirely in javascript, so I can't really put in wicket
components to fire off the ajax. I only have a HiddenField component on
the page to capture the selected date so I can get it back to wicket.
So in order to actually make the ajax request, I have a js function on
the page which calls:
document.forms[0].onsubmit();
This invokes the onsubmit behavior wicket generates in the form tag.
I know this probably looks a bit hacked, but I was hoping to quickly
reimplement my calendar control in wicket, since it already has the
functionality and style I want. However, if no one has any handy
solutions, or the solution begins to get overly long and complicated, I
may have to look at what options I have for customizing wicket's date
picker. The biggest problem I had with it was that you could only move
through the calendar one month at a time, while my control has dropdowns
for both the month and year (although personally, if the date I wanted
was too far from the current date, or whatever default date the calendar
starts on, I would just type it in manually to the TextField).
Any help would be appreciated, as always. Thanks.
Joel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: wicket-event.js returning unreadable
This way you end up not using compression at all? I would be interested in a solution which would help me to use the compression without any problems. Now I'm just using wicket's default compression (which I didn't know existed before this problem arose). Maybe someone from the wicket core team would help us to understand the difference between using IHeaderContributor and adding directly JavascriptReference as a behavior? Have you taken a look at the html source of the rendered page in both cases? That might give an indication of how wicket handles these differently. Are you also using a fine Oracle product for your webserver? I think they might be right that this could be an Oracle-caused issue. Wouldn't be the first time I've had Oracle mess me up with their non-open source, blackbox implementation. Oracle interferred with my first stab at Jaas authentication, so I had to completely circumvent it; and when I was trying to include a jsp menu on a wicket page, it worked great until I upgraded to a newer version of oc4j (from 10.1.3.1.1 to 10.1.3.2 I believe * should anything past the second minor version number even be a public release??), and I ran into a conflict between Oracle and wicket writing to the output stream. I wrote that one off as unsolvable. Unfortunately, I have no say in what webserver we use, so I have to deal with it. Like I said before, we're trying to do slightly different things. You're trying to dynamically include an external js file. I just wanted to write dynamic js code which ran onload. But the wicket implementation of that includes a js file from the wicket jar. I'm curious, is the js file you're trying to call inside a jar or just in a directory on the webserver? Maybe this issue is related to including a jarred js file. I don't know, at times this problem has behaved so erratically for me, it's hard to get a grip on. That's why I'm glad I figured out a workaround. Joel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
