how to modify internal JavascriptResourceReference packaged with component
Hi, I'm working on a project that's on wicket 1.4. It's using the MultiFileUploadField class. I see in the code for that class that in renderHead, it calls: response.renderJavascriptReference(JS); and earlier it defines: private static final ResourceReference JS = new JavascriptResourceReference( MultiFileUploadField.class, MultiFileUploadField.js); But, I'd like to make a minor modification to the actual javascript in MultiFileUploadField.js. Specifically, I want to modify that code to remove the c:/fakepath prefix that appears in the box with the list of selected files below the field (in chrome and safari - not a problem in firefox and ie). If I could just over-ride the javascript contents of that file, it would be an easy fix. But, more generally, I'd like to know not just for this specific issue, is there a wicket way to override the packaged javascript resource that comes with a component? Perhaps is there a simple way to extend the MultiFileUploadField class with my own class, and somehow keep the rest of the code as is, but specify an alternate resource? It's private in that class, so I don't see how I'd do this, but maybe I'm missing something obvious. Or maybe is there some way to keep using the same class but to tell the application that I want to replace the corresponding javascript file with my own? Or is there some other approach I should be taking when this type of issue comes up? Thanks very much for any advice, -Evan
RE: AjaxFormComponentUpdatingBehavior after validation problem
Hello,
I think the problem is just that you're calling setValues on your
genericModelObject, which is set as the compoundpropertymodel for your
form, but you're not adding the form back to the ajax response - with the
AjaxRequestTarget, you're only adding the component dropDownId to get
re-rendered into the page, not the form with the updated model. So, the
change made directly on the dropdown which is added to the ajaxRequestTarget
(calling setEnabled) is taking effect, but it's not finding the updated
model. It should work if you add:
target.addComponent(get(formId));
Hope that helps,
-Evan
-Original Message-
From: Gytis [mailto:lietuvis...@mail.ru]
Sent: Friday, March 16, 2012 5:32 AM
To: users@wicket.apache.org
Subject: AjaxFormComponentUpdatingBehavior after validation problem
Hello, I have such a problem with AjaxFormComponentUpdatingBehavior.
I have some DropDownChoice and a CheckBox on a Form. I need to make a change
to DropDown, when I click on CheckBox. But as I try to submit a Form, got
some error, and then click CheckBox DropDown doesn`t change. The code looks
like this:
DropDownChoiceSomeEnum dropDownz = new
DropDownChoiceSomeEnum(dropDownId,
Arrays.asList(SomeEnum.values()), new
EnumChoiceRendererSomeEnum(this));
getGenericModelObject().setValues(SomeEnum.FIRSTVALUE);
CheckBox boxz = new CheckBox(BoxId);
boxz.add(new AjaxFormComponentUpdatingBehavior(onchange)
{
@Override
protected void onUpdate(AjaxRequestTarget target) {
if (boxz.getModelObject())
{
getGenericModelObject().setValues(SomeEnum.SECONDVALUE);
get(dropDownId).setEnabled(false);
target.addComponent(get(dropDownId));
}
else
{
get(dropDownId).setEnabled(true);
target.addComponent(get(dropDownId));
}
}
@Override
protected void onError(AjaxRequestTarget target,
RuntimeException e) {
if (boxz.getModelObject())
{
getGenericModelObject().setValues(SomeEnum.SECONDVALUE);
get(dropDownId).setEnabled(false);
target.addComponent(get(dropDownId));
}
else
{
get(dropDownId).setEnabled(true);
target.addComponent(get(dropDownId));
}
super.onError(target, e);
}
});
Form form = new Form(formId, getGenericModel());
form.add(dropDownz);
form.add(boxz);
So as I said, after form validation, if errors occur, it won`t change
dropdown to SECONDVALUE, but sets it as setEnabled(false), why this happens?
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/AjaxFormComponentUpdatingBehavior
-after-validation-problem-tp4477705p4477705.html
Sent from the Users forum mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
RE: Wicket jQuery Validator integration
Hi Zac, this sounds great - I would be very appreciative if you make this code public, and I imagine it would be useful for many. I was just about to take a look at the wicketstuff-client-and-server-validation project which seems to be a similar idea, but it would be great to check out what you have done using wiquery. Have you had a chance to post this somewhere? Thanks, -Evan -Original Message- From: Zachary Bedell [mailto:zacl...@thebedells.org] Sent: Wednesday, February 15, 2012 10:52 AM To: users@wicket.apache.org Subject: Wicket jQuery Validator integration Good morning, Reading a recent thread about accessing jQuery Validation from Wicket reminded me that I've developed some code that might be of use. I'm not sure if this is something anyone else would be interested in or if it's something that might eventually be integrated into Wicket core or if it would be more appropriate for one of the existing jQuery/Wicket integration libraries. I wanted to describe what I've cooked up so far. If this is anything that would be useful, I'd be willing to clean the code up a bit to extract a few bits that are specific to our environment and post the code somewhere. My intent was to get client-side validation using Wicket's existing validation classes without requiring AJAX calls to make them work and preferably without requiring Page's to include lots of unsightly JavaScript. Also, not duplicating validation logic on the client server tiers was desirable. The code was originally developed for a site that was expected to receive a high amount of traffic in a short period of time, and avoiding unnecessary server calls was a priority. I created a subclass of Form (ClientSideValidatingForm) which examines each FormComponent (and sub-Form) added to it and extracts information about the standard Wicket validations. It generates JavaScript which uses jQuery's Validator library to apply client-side checks equivalent to the Wicket server side checks. The nice thing about this is that you get client-side validation for free just by adding the normal Wicket validations plus you still get all your validations backed up in the server side in case JavaScript is unavailable or disabled. The implementation of the class does lack a bit in terms of elegance unfortunately. As the Wicket validation interface doesn't currently know anything about JavaScript, it was necessary to run a chain of instanceof checks against all the known Wicket validations and emit JavaScript to mirror their logic. I also created an extension of the Wicket IValidator interface which can provide JavaScript functions to perform validation equivalent to the server-side Java code. The extraction code in ClientSideValidatingForm preferentially checks for this interface and uses provided JavaScript if available. Otherwise, it's a bunch of instanceof's to check for known validations or log an error if an unknown instance of IValidator is found. Long term, it would be helpful if the stock Wicket IValidator interface could include a method to get JavaScript validations for all of the stock validations. The code is pretty tightly bound to jQuery Validator at this point, but it's likely the methodology could be abstracted to other validation frameworks. It's also built using WiQuery, though that's mostly as a convenience to get the same version of jQuery that we use elsewhere. The same could easily be implemented without WiQuery provided a version of jQuery was contributed to the response via some other mechanism. Is this something anyone would be interested in? Best regards, Zac Bedell (Apologies if this is a dupe. I had some email client config issues this morning...) - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: continueToOriginalDestination seems to be incorrectly retaining destination across multiple logins
Thanks for your response Martin, and sorry for my delayed reply!
I added the breakpoint (it's line 210 in my 1.5-SNAPSHOT). I also put one at
line 197, at the start of the mapRequest method, to see if it was getting into
the method and finding a null value for the data variable. But neither
breakpoint gets reached so the method is not being called. Does this mean that
something is wrong with my wicket/shiro integration code, regarding the wicket
request processing not being used correctly? I should add that I'm using a
library from this fifyfive-wicket project (see
https://github.com/55minutes/fiftyfive-wicket#readme) that pretty much sets up
the wicket/shiro integration for me. Does it sound like the problem is most
likely coming from there, or might something else be going on?
Thanks again,
-Evan
-Original Message-
From: Martin Grigorov [mailto:mgrigo...@apache.org]
Sent: Thursday, February 09, 2012 3:12 AM
To: users@wicket.apache.org
Subject: Re: continueToOriginalDestination seems to be incorrectly retaining
destination across multiple logins
Hi,
The intercept data should be cleaned at
org.apache.wicket.RestartResponseAtInterceptPageException, line 211 -
InterceptData.clear(); Put a breakpoint there and see what happens.
On Wed, Feb 8, 2012 at 7:55 PM, Evan Sable e...@novelution.com wrote:
Hi,
I'm using wicket 1.5-SNAPSHOT along with Shiro for
authentication/authorization security, and when an unauthorized user
tries to go to a page, Shiro calls redirectToInterceptPage behind the
scenes, and during the login process, after a successful login, there is code
that says:
if (!continueToOriginalDestination()) {
setResponsePage(getApplication().getHomePage());
}
It is working in the sense that if a user gets redirected to login,
they are taken to the correct destination afterwards, and if a user
just clicks the login link in a new browser they are redirected to the
homepage after login.
BUT, the problem is, if an initial user tries to go to a protected
page, gets redirected to the login, logs in, and then logs out, and
then, without closing the browser, clicks the login link and logs in
with the same user again or even another user, it still redirects to the
prior original
destination, which should no longer take effect. I would think that
this should be forgotten upon logging out, which replaces the wicket
session
with:
Session session = Session.get();
session.replaceSession();
I think I must be misunderstanding how continueToOriginalDestination
is working - I thought it was placing the original destination url
into the users session, which is why I figured that after the login
which redirects, followed by the logout which replaces the session, it would
be gone.
Can someone please explain what I'm thinking about wrongly here and
why the destination is being retained across multiple logins. Also,
how can I avoid this so that the original destination is only used the
first time?Btw, just to be clear, if I logout and then click to a
new protected url, the original destination value is properly
replaced with the new protected destination which redirects back to
the intercept page. The problem is only if I click directly to the
login page without a new intercept, but after having previously
utilized the continueToOriginalDestination in the prior login.
Thanks very much for any help!
-Evan
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
continueToOriginalDestination seems to be incorrectly retaining destination across multiple logins
Hi,
I'm using wicket 1.5-SNAPSHOT along with Shiro for
authentication/authorization security, and when an unauthorized user tries
to go to a page, Shiro calls redirectToInterceptPage behind the scenes, and
during the login process, after a successful login, there is code that says:
if (!continueToOriginalDestination()) {
setResponsePage(getApplication().getHomePage());
}
It is working in the sense that if a user gets redirected to login, they are
taken to the correct destination afterwards, and if a user just clicks the
login link in a new browser they are redirected to the homepage after login.
BUT, the problem is, if an initial user tries to go to a protected page,
gets redirected to the login, logs in, and then logs out, and then, without
closing the browser, clicks the login link and logs in with the same user
again or even another user, it still redirects to the prior original
destination, which should no longer take effect. I would think that this
should be forgotten upon logging out, which replaces the wicket session
with:
Session session = Session.get();
session.replaceSession();
I think I must be misunderstanding how continueToOriginalDestination is
working - I thought it was placing the original destination url into the
users session, which is why I figured that after the login which redirects,
followed by the logout which replaces the session, it would be gone.
Can someone please explain what I'm thinking about wrongly here and why the
destination is being retained across multiple logins. Also, how can I avoid
this so that the original destination is only used the first time?Btw,
just to be clear, if I logout and then click to a new protected url, the
original destination value is properly replaced with the new protected
destination which redirects back to the intercept page. The problem is only
if I click directly to the login page without a new intercept, but after
having previously utilized the continueToOriginalDestination in the prior
login.
Thanks very much for any help!
-Evan
