RE: Creating a Wicket Session outside of a Wicket request

2011-11-15 Thread David Berkman
Apache Shiro, and create a shiro version of WebSession. Then wicket can ask for the Shio Session from the Http context, and you can get it outside the context. David -Original Message- From: Thomas Heigl [mailto:tho...@umschalt.com] Sent: Tuesday, November 15, 2011 10:57 AM To:

RE: Creating a Wicket Session outside of a Wicket request

2011-11-15 Thread David Berkman
, but at the moment the minimal wicket-auth-roles is enough for my requirements. I'd prefer to just create the session myself when I need it. Any other ideas? Cheers, THomas On Tue, Nov 15, 2011 at 8:02 PM, David Berkman david.berk...@glu.comwrote: Apache Shiro, and create a shiro version

RE: Creating a Wicket Session outside of a Wicket request

2011-11-15 Thread David Berkman
interesting I was trying to do some thing similar n eariler and just dropped it. Is it possible to use wicket shiro instead? -Original Message- From: David Berkman david.berk...@glu.com Date: Tue, 15 Nov 2011 11:09:10 To: users@wicket.apache.org Reply-To: users@wicket.apache.org Subject: RE

RE: wicket-dojo wrappers (correction)

2011-11-10 Thread David Berkman
) Hi David, Would it be possible to put up the jar that contains or the java file: org.smallmind.nutsnbolts.util.DotNotationComparator? I get a compile error with this and I don't understand what it does in terms of dot notation. Thanks, James. On 10/11/2011 3:15 AM, David Berkman wrote: Sorry

RE: wicket-dojo wrappers (correction)

2011-11-10 Thread David Berkman
@wicket.apache.org Subject: Re: wicket-dojo wrappers (correction) David, I would love to help you manage/maintain this project if you need help. -Original Message- From: David Berkman david.berk...@glu.com Date: Thu, 10 Nov 2011 11:50:12 To: users@wicket.apache.org Reply-To: users@wicket.apache.org

wicket-dojo wrappers

2011-11-09 Thread David Berkman
I've had a number of requests, so I'll upload this bit of code here so people can have a look. I know there's room for improvement in the code that exists, and a ton that needs to be done. There's a wicket-dojo project on GitHub https://github.com/vijaykiran/wicketstuff-dojo that's much

wicket-dojo wrappers (correction)

2011-11-09 Thread David Berkman
Sorry for the repost, but this list doesn't take attachments I guess, so I've upload the code at https://github.com/zenbones/WicketDojo I've had a number of requests, so I'll upload this bit of code here so people can have a look. I know there's room for improvement in the code that exists,

RE: How to run a JavaScript function from Form Constructor in Wicket

2011-11-08 Thread David Berkman
Add a Behavior, mark the behavior temporary (setTemporary(true)), and override the Behavior's renderHead (Component component, IHeaderResponse response) method, and call response.renderJavascript(). If you want the JS function to go off every time the component is rendered, don't mark the behavior

RE: Advice wanted about polished component set with Wicket

2011-11-08 Thread David Berkman
I've had excellent success wrapping most of Dojo with Wicket, and it would not be hard to complete the rest. There's a wicket-dojo project out there, but it didn't seem to be active, so I just started in on my own. Dojo is a comprehensive, well laid out project (always had a good concept of

RE: wicket-4200 still broken in 1.5-SNAPSHOT

2011-11-07 Thread David Berkman
ticket that reproduces your particular problem. -igor On Sun, Nov 6, 2011 at 6:41 PM, David Berkman david.berk...@glu.com wrote: I understand that wicket-4200 (no prepended javascript in onBeforeRender()) is marked fixed in 1.5.3. I pulled the latest SNAPSHOT to see if I could get an early fix

wicket-4200 still broken in 1.5-SNAPSHOT

2011-11-06 Thread David Berkman
I understand that wicket-4200 (no prepended javascript in onBeforeRender()) is marked fixed in 1.5.3. I pulled the latest SNAPSHOT to see if I could get an early fix. It may be that the current snapshot is known to be unstable in this regard, but prepending javascript still does not work. I've

AjaxRequestTarget does not allow prepending javascript

2011-11-05 Thread David Berkman
Not sure why, but, in 1.5.2 (at least), the call order is such that prependJavascript is not called on AjaxRequestTarget until after constructResponseBody() has passed... IteratorCharSequence it = prependJavaScripts.iterator();

RE: AjaxRequestTarget does not allow prepending javascript

2011-11-05 Thread David Berkman
: Igor Vaynberg [mailto:igor.vaynb...@gmail.com] Sent: Saturday, November 05, 2011 12:46 PM To: users@wicket.apache.org Subject: Re: AjaxRequestTarget does not allow prepending javascript fixed. see wicket-4200 -igor On Fri, Nov 4, 2011 at 10:59 PM, David Berkman david.berk...@glu.com wrote

RE: Problem with Panel default model

2011-10-26 Thread David Berkman
It does... private static final ThreadLocalBoolean STRIP_TAGS_LOCAL = new ThreadLocalBoolean(); @Override protected void onBeforeRender () { super.onBeforeRender(); STRIP_TAGS_LOCAL.set(Application.get().getMarkupSettings().getStripWicketTags());

Problem with Panel default model

2011-10-25 Thread David Berkman
Thank you. Upgrade to 1.5.2 did seem to resolve the issue with the last ajax request parameters being pushed onto the base url. However, testing that resolution exposed a further problem. I'm using a org.apache.wicket.markup.html.panel.Panel into which I'm handing the a

RE: AbstractAutoCompleteRenderer.getOnSelectJavaScriptExpression doesn't have access for callbackUrl

2011-10-25 Thread David Berkman
How about... @Override public void renderHead (IHeaderResponse response) { response.renderJavaScript(var foo=' + myBehavior.getCallbackUrl() +';); } ...or just put the callback into whatever javascript requires it dynamically upon page construction via some similar methodology.

Problem with ajax base url

2011-10-24 Thread David Berkman
I'm currently using wicket 1.5.1, testing with Firefox (latest). When wicket receives an ajax GET request it seems to store the query parameters of the last such request, and append them to the base url upon page reload. I'm sure this behavior serves a very valid purpose, but I'm wrapping a