Was this ever resolved? I'm still seeing problems when I use back button,
where the ajax actions on the previous page are being evaluated as though
they were for the more recent page, as if the ajax actions have no way of
knowing what page they are for, so assuming the one rendered most
recentely.
, and if the user has reset it, skip the warning.
dukejansen wrote:
>
> Tried this. It still gives the warning. :(
>
>
> James McLaughlin-3 wrote:
>>
>> Its a shameless hack, but you could try it in a setTimeout. Or possibly,
>> target.appendJavascript(&
antics of onClose make it necessary for
> the modal to be around until onClose returns.
>
> hth,
>
> jim
>
> On 5/31/07, dukejansen <[EMAIL PROTECTED]> wrote:
>>
>> Any chance anyone has any input on this? I still think this is a bug in
>> Wicket, that
s, you think we
>> should build in better support for this in Wicket?
>>
>> Eelco
>>
>> On 6/5/07, dukejansen <[EMAIL PROTECTED]> wrote:
>> > I've gone ahead and implemented this, but instead of using the
>> > Component.saveInnermostModel m
f you override some boolean method, your component will get
> auto-ajax-updated on every AJAX request. For many problems, this would be
> convenient because it's easier to just update the thing every time than to
> think about all the places it might need to be updated.
>
>
> duk
Any chance anyone has any input on this? I still think this is a bug in
Wicket, that I can't set Javascript to reload the page after the modal
window is closed, since the page still thinks the modal is open.
dukejansen wrote:
>
> Yup. That's why I was tryin
I have some state which backs two panels, Panel A and Panel B, that may be
included as part of other panels. Ultimately they are both on the same page,
and their backing state is shared via the model class that backs both of
them. Panel A has an Ajax event handler which modifies the backing model
}
> filterPath = getFilterPath(request);
>
> so i dont know exactly where you are looking at ?
>
> johan
>
>
> On 5/11/07, dukejansen <[EMAIL PROTECTED]> wrote:
>>
>>
>> I believe I have identified a rather serious bug in WicketFi
Probably would be wise to look at all calls to
HttpServletRequest.getServletPath.
--
View this message in context:
http://www.nabble.com/WicketFilter-doesn%27t-work-in-Weblogic--Wicket-1.3--tf3724994.html#a10424543
Sent from the Wicket - User mailing list archive at Nabble.com.
---
I believe I have identified a rather serious bug in WicketFilter.
I'm using a recent 1.3 snapshot, and I have recently updated our application
to leverage the WicketFilter instead of WicketServlet. This is working great
in Tomcat, but when we deploy to our Weblogic server, Wicket dies an ugly
dea
rocess the ajax
> response at all. Just sets window.location.
>
> -Matej
>
> On 5/9/07, dukejansen <[EMAIL PROTECTED]> wrote:
>>
>> Yeah, but I don't want to disable that warning. That warning is valid if
>> the
>> user really does try to navigate away wh
on
Matej Knopp-2 wrote:
>
> There is a way that should also work in recent 1.x. To disable the
> confirmation dialog you need to put this inside the page with modal
> window:
>
> Wicket.Window.unloadConfirmation=false;
>
>
> -Matej
>
> On 5/9/07, Arnout Engel
Anyone have any recommendations for how I would go about getting my Ajax
event handler method to trigger a refresh of the current page on the client
side after it is done with the Ajax request? My Ajax event handler needs to
first close the current modal window and then refresh the entire page.
I
I too am working on a system which must go live to a large user base early to
mid July.
What kind of confidence can I have that 1.3 be stable enough by then? Are we
talking 95%, 75%, or 50%?
I need some of the 1.3 functionality but once I commit to move to 1.3 I'm
not going to have time to go ba
taken?
igor.vaynberg wrote:
>
> second level store involved some pretty heavy refactoring of the internals
> afaik, so i dont think you will get it working under 1.2
>
> -igor
>
>
> On 3/30/07, dukejansen <[EMAIL PROTECTED]> wrote:
>>
>>
>> Does anyone hav
Does anyone have any good recommendations for how I get started with second
level session storage in Wicket 1.2, via persistence to disk, for (1) old
page versions and (2) entire sessions when session expires? We can't move to
1.3 or 2.0, so I'm trying to get an understanding of what my options ar
Right now, if I have a localized property file (e.g. Welcome_de.properties),
it seems I must have all resource keys defined in it.
I would prefer to have the localizer be smart enough to fallback to the
default properties file (e.g. Welcome.properties) if a property is not
present in the localize
I can understand why onException might only be used for internal exceptions
in processing, but shouldn't the exception at least escalate back up to
RequestCycle.onRuntimeException and be handled there?
Otherwise, are we expected to always catch any possible Throwable in our
onSubmit if we want to
More session/state management questions.
I have an application with a search page, backed by a multitude of panels
all backed by a model which is not fully detacheable now but easily could
be.
The search page has various forms on it to enable the user to update search
criteria and refresh result
PERFECT! Thanks. :)
-Jason
Al Maw wrote:
>
> dukejansen wrote:
>> What I'm really after is whether there is a way to set default behavior
>> for
>> ALL AjaxRequestTargets.
>
> Ah, I see.
>
> You can execute some Jav
he page is rendered, and I want to ensure that this
function is called any time I do an ajax replacement of a component.
Since the AjaxRequestTarget doesn't seem to be created by a factory (or
extensible really), I'm not sure how I would go about this.
Thoughts?
Al Maw wrote:
>
> d
What's the best way to add some JavaScript code to be called after a
component is updated via Ajax?
I have a component that is rendered by Wicket and then requires a Javascript
function to be called in order to modify the DOM for that component
client-side. I have Ajax events which re-render this
ipt instead of prepand
>
> -igor
>
>
> On 2/26/07, dukejansen <[EMAIL PROTECTED]> wrote:
>>
>>
>> Yes, I've tested some more and I only get this error in my Ajax debug
>> window
>> under IE. In Firefox, it correctly loads the modal window.
>>
erhtml of a tr). it is a very helpful message :) i bet
> that
> code looks like this
>
> try {
> processjavascript();
> } catch (Throwable e) {
> // we should never get here
> throw new Exception("Unknown Error");
> }
>
> :)
>
> -igor
>
>
e before I kept trying to find it server side.
Ryan Holmes wrote:
>
> Set a breakpoint in the Java code that handles the Ajax event and
> then the problem is usually pretty obvious...
>
> -Ryan
>
> On Feb 25, 2007, at 3:54 PM, dukejansen wrote:
>
>>
>
INFO: Response parsed. Now invoking steps...
ERROR: Error while parsing response: Unknown runtime error
INFO: Invoking post-call handler(s)...
INFO: Invoking failure handler(s)...
How can I dig deeper into this "Unknown runtime error"? I see nothing in the
server logs. Thought I'd ask for simple
Haven't had a chance but will try to get you a quickstart reproduction this
week...
igor.vaynberg wrote:
>
> can you reproduce in quickstart please?
>
> -igor
>
>
> On 2/1/07, dukejansen <[EMAIL PROTECTED]> wrote:
>>
>>
>> I have a DataView
ive/jcifs/2004-December/004459.html
igor.vaynberg wrote:
>
> strange indeed. what is your wicket filter/servlet mapping? what does the
> generated form markup look like?
>
> -igor
>
>
> On 2/1/07, dukejansen <[EMAIL PROTECTED]> wrote:
>>
>>
>> I&
I have a DataView.
Within this DataView I have multiple items.
Each item includes, among other things:
- a markup container "more" that starts out visible=false
- an ajax link "show more", which toggles the visibility of the markup
container (this is an AjaxFallbackLink)
In addition, the
I'm facing a very strange issue which may be Wicket-related or may not.
It seems that for any form posts in our application, whether Ajax or
otherwise, when the request arrives at the server there is no form data
included. The request.postData member is null.
This happens only in IE. Form posts
Excellent! Thanks.
-Jason
igor.vaynberg wrote:
>
> ((webrequest)requestcycle.get().getrequest()).gethttpservletrequest().
>
> -igor
>
>
> On 1/31/07, dukejansen <[EMAIL PROTECTED]> wrote:
>>
>>
>> I know that Wicket intentionally obsfuscates
I know that Wicket intentionally obsfuscates much of the
HttpSession/HttpServletRequest/HttpServletResponse complexity, and that's
mostly fine, but I need to be able to get the root context path for my
application so that I can construct meaningful links to servlets and other
resources that are ou
the
page before creating and returning a new one.
-Jason
dukejansen wrote:
>
> Did not know about that functionality. Sounds perfect. Then for pages
> which must always have bookmarkable URL, we can always extend a base class
> that sets itself to unversioned, and for other non-bookma
t; Haven't tried it myself, but looking at the code, calling (your web
> page).getBodyContainer().getBodyContainer() should get you the 'real'
> body container, to which you should be able to add AttributeModifiers.
>
> Eelco
>
>
> On 1/28/07, dukejansen <[E
Is there any way to allow inherited page markup to update or contribute to
the body tag's attributes (other than onLoad and onUnload, which seems to be
covered).
Specifically, I'd like to have a single base page which is then subclassed
to provide different page behaviors, and I want to be able t
re unversioned.
>
> johan
>
>
> On 1/24/07, dukejansen <[EMAIL PROTECTED]> wrote:
>>
>>
>> Sorry, guess I misunderstood. Still trying to wrap my head around these
>> concepts.
>>
>> We have an app that is all bookmarkable pages so far, but we m
n't use forms anywhere?
> or if you use for (with wicket 1.2) you handle the post in the constructor
> of the page itself?
> Thats not really where wicket is made for, your throw away pretty much 90%
> of what makes wicket.
>
> johan
>
>
>
> On 1/24/07, dukejan
ne?
> What is the best English for this??
> should we better express it like: setMaxPageUndoBuffer() ??
>
> johan
>
>
> On 1/24/07, dukejansen <[EMAIL PROTECTED]> wrote:
>>
>>
>>
>> Eelco Hillenius wrote:
>> >
>> > Well, every us
ework such that it posts page parameters in the URL somehow against
bookmarkable URLs, it would be much easier than having to do it myself.
-Jason
igor.vaynberg wrote:
>
> you do realize that by doing this you are completely killing the back
> button
> support in your app
>
&
Eelco Hillenius wrote:
>
> Well, every user (session) will use memory, correct. But only to a
> certain limit. Wicket 1.2 holds a couple of page/ versions in a
> session, and Wicket 2.0 by default only holds the current one. So the
> creation of a fresh instance (e.g. a bookmarkable page) will r
40 matches
Mail list logo
