Re: Wicke website makeover time?
Hi, Personnally, I really liked what Martijn did here: http://people.apache.org/~dashorst/wicket-flat/ It's clean and has personnality. The only thing IMHO is that a one page design for this amount of information is perhaps a bit too much. -- Guillaume On Fri, Nov 14, 2014 at 1:14 PM, Chris Colman chr...@stepaheadsoftware.com wrote: I think a multi phase approach might have more chance of success - as I said in my immediate previous post if we could live with jekyll source for phase one (even though it may not be ideal) then we can keep most of the current content source 'as is' and simply choose a decent modern Bootstrap CSS template to re-render it in to deliver the best 'bang for buck' possible at this early stage. Bootstrap would be too standard and anonymous and would ultimately be a ball and chain. A little .less and responsiveness can easily be achieved without going bootstrap. IMHO standard and anonymous looks a lot better than retro late 1990s ;) Having said that, there are plenty of Bootstrap customization tools (Bootswatch etc.,) that would allow us to customize very quickly and so move well away from the standard and anonymous Bootstrap look and feel - I would never use the standard Bootstrap template without customization - it's too generic these days. While we could go home grown i.e. without the help of Bootstrap and do a little .less (or .sass) and responsiveness the use of Bootstrap's already awesome (tried and tested and working) responsiveness and it's cross browser compatibility (who wants to deal with issues like that in 2014?) could make this a very quick project. I know I don't have a lot of time to spare to make greenfield, home grown responsiveness that works across IE7+, FF, Chrome and Safari. So a quick project is a good project for me. If it ends up looking a lot more modern and sexy than the current site and it takes hours instead of weeks then I think it's going to happen. If we insist on not using a grid/CSS/JS template like Bootstrap and so make the effort measured in weeks instead of hours then I fear that the website will still have it's current look and feel in a years time. I don't think we'll be locked into Bootstrap anyway. If the translator uses bootstrap then the copy can remain Bootstrap free and easily moved to another CSS/JS library later if required. Or does Jekyll have a fairly fixed translator that provides little customizability? Jekyll is fully customizable. It's just a translator from markdown to HTML with templates and includes. Martijn - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
ResourceModel with default *key*
Hi all, Maybe we are missing something but we haven't found an elegant way to have a ResourceModel with a default *key* if the current key doesn't exist. There is a mechanism for a default *string* but it's not sufficient for us (we want to be able to specialize the key if needed but have an internationalized default if not). Suggestions welcome! Thanks. -- Guillaume - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: ResourceModel with default *key*
Hi Tom, Thanks for your suggestion! That's the kind of thing I had in mind if we haven't missed anything in the API but I was hoping we have missed something as it seems generally useful! On Thu, Nov 6, 2014 at 12:49 PM, Tom Götz t...@decoded.de wrote: You could try something like this: https://gist.github.com/tgoetz/0735b05d47b16acf2fd7 https://gist.github.com/tgoetz/0735b05d47b16acf2fd7 Cheers, -Tom On 06.11.2014, at 11:53, Guillaume Smet guillaume.s...@gmail.com wrote: Hi all, Maybe we are missing something but we haven't found an elegant way to have a ResourceModel with a default *key* if the current key doesn't exist. There is a mechanism for a default *string* but it's not sufficient for us (we want to be able to specialize the key if needed but have an internationalized default if not). Suggestions welcome! Thanks. -- Guillaume - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Lock timeout per page class
Hi Martin,
Looks sane to me. I created a JIRA issue:
https://issues.apache.org/jira/browse/WICKET-5740 .
Thanks again for your help!
On Tue, Oct 28, 2014 at 9:45 AM, Martin Grigorov mgrigo...@apache.org wrote:
Here is my version: http://pastie.org/9680245
Please create a ticket in JIRA if you like it.
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Tue, Oct 28, 2014 at 9:52 AM, Martin Grigorov mgrigo...@apache.org
wrote:
Hi,
I share Sebastien's concern.
I'll see how to workaround this.
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Sat, Oct 25, 2014 at 2:57 PM, Sebastien seb...@gmail.com wrote:
Hi Guillaume,
Generally speaking, you cannot call a non final method from a
constructor...
Best regards,
Sebastien
On Oct 25, 2014 1:32 PM, Guillaume Smet guillaume.s...@gmail.com
wrote:
Hi Martin,
I got something working with the following changes in Wicket:
https://github.com/openwide-java/wicket/commit/6374a4a7c6fb66841143a88933523f97305cf1a4
Do you consider this commitable? If so, I can create a JIRA issue and
push
a PR.
Having the pageId in the getTimeout call is quite nice as I don't have
to get it again from the PageRequestHandlerTracker.
Thanks for your feedback.
On Fri, Oct 24, 2014 at 9:16 AM, Martin Grigorov mgrigo...@apache.org
wrote:
If you have a base page then BasePage#onInitialize() should be a good
place.
Or you could add the pageIds of the special/slow pages only in the
map.
Otherwise you may use PageRequestHandlerTracker#getLastHandler in a
custom
IRequestCycleListener#onDetach().
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Fri, Oct 24, 2014 at 10:11 AM, Guillaume Smet
guillaume.s...@gmail.com
wrote:
Hi Martin,
Yeah, I thought about that too but I'm not sure of the best place to
build the pageId - pageClassName map. Any advice about this?
Once I'll get this working, I'll build a PR for the few changes I
made
in Wicket (based on what you proposed earlier). Would be nice to have
them in 6.18.
On Fri, Oct 24, 2014 at 8:59 AM, Martin Grigorov
mgrigo...@apache.org
wrote:
Hi Guillaume,
Sorry for not thinking more carefully about this the first time!
I'm afraid it is not possible to do it the way I suggested.
PageAccessSynchronizer is the entry point to start using a page
and it
works only with pageId!
Here is a new hackish approach:
Store pageId - pageClassName map in the Session. Then when
PageAccessSynchronizer is requested to lock a page by id use that
id
to
resolve the class name and to decide what timeout to use.
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Thu, Oct 23, 2014 at 5:44 PM, Guillaume Smet
guillaume.s...@gmail.com
wrote:
Hi Martin,
On Wed, Oct 22, 2014 at 9:51 AM, Martin Grigorov
mgrigo...@apache.org
wrote:
I'd like to avoid moving the logic that gets the timeout from
Session.PageAccessSynchronizerProvider to PageAccessSynchronizer
because
this way it will use Application.get() everytime and most apps
don't
need
to pay for this.
A way to make it possible for you is to remove the 'final'
from org.apache.wicket.Session#getPageManager and introduce
overridable
PageAccessSynchronizer#getTimeout(). This way you can use your
own
PageAccessSynchronizer.
http://pastie.org/9667070
After a few experiments, here I am!
So, it mostly works: I thought it would be better to add something
like:
protected IProviderPageAccessSynchronizer
newPageAccessSynchronizerProvider()
{
return new PageAccessSynchronizerProvider();
}
in Session and call it from the constructor instead of removing
the
final so I did that in my code.
It works pretty well BUT I haven't found a way to get the page
class
in getTimeout without having the risk to trigger a
resolvePageInstance
which will try to lock and then call getTimeout leading to a
wonderful
stack overflow exception when dealing with
ListenerInterfaceRequestHandler.
Obviously (...) what interests me the most is the getTimeout in
ListenerInterfaceRequestHandler as it's often actions on buttons
which
are long to run.
Here is what I have in mind for my Session class:
https://gist.github.com/gsmet/3b9e2775d25fadcef5ef
I must admit that an advice would be welcome as I wouldn't like to
have stack overflow errors popping out in weird edge cases.
Thanks!
--
Guillaume
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Lock timeout per page class
Hi Martin,
I got something working with the following changes in Wicket:
https://github.com/openwide-java/wicket/commit/6374a4a7c6fb66841143a88933523f97305cf1a4
Do you consider this commitable? If so, I can create a JIRA issue and push a PR.
Having the pageId in the getTimeout call is quite nice as I don't have
to get it again from the PageRequestHandlerTracker.
Thanks for your feedback.
On Fri, Oct 24, 2014 at 9:16 AM, Martin Grigorov mgrigo...@apache.org wrote:
If you have a base page then BasePage#onInitialize() should be a good place.
Or you could add the pageIds of the special/slow pages only in the map.
Otherwise you may use PageRequestHandlerTracker#getLastHandler in a custom
IRequestCycleListener#onDetach().
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Fri, Oct 24, 2014 at 10:11 AM, Guillaume Smet guillaume.s...@gmail.com
wrote:
Hi Martin,
Yeah, I thought about that too but I'm not sure of the best place to
build the pageId - pageClassName map. Any advice about this?
Once I'll get this working, I'll build a PR for the few changes I made
in Wicket (based on what you proposed earlier). Would be nice to have
them in 6.18.
On Fri, Oct 24, 2014 at 8:59 AM, Martin Grigorov mgrigo...@apache.org
wrote:
Hi Guillaume,
Sorry for not thinking more carefully about this the first time!
I'm afraid it is not possible to do it the way I suggested.
PageAccessSynchronizer is the entry point to start using a page and it
works only with pageId!
Here is a new hackish approach:
Store pageId - pageClassName map in the Session. Then when
PageAccessSynchronizer is requested to lock a page by id use that id to
resolve the class name and to decide what timeout to use.
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Thu, Oct 23, 2014 at 5:44 PM, Guillaume Smet
guillaume.s...@gmail.com
wrote:
Hi Martin,
On Wed, Oct 22, 2014 at 9:51 AM, Martin Grigorov mgrigo...@apache.org
wrote:
I'd like to avoid moving the logic that gets the timeout from
Session.PageAccessSynchronizerProvider to PageAccessSynchronizer
because
this way it will use Application.get() everytime and most apps don't
need
to pay for this.
A way to make it possible for you is to remove the 'final'
from org.apache.wicket.Session#getPageManager and introduce
overridable
PageAccessSynchronizer#getTimeout(). This way you can use your own
PageAccessSynchronizer.
http://pastie.org/9667070
After a few experiments, here I am!
So, it mostly works: I thought it would be better to add something like:
protected IProviderPageAccessSynchronizer
newPageAccessSynchronizerProvider()
{
return new PageAccessSynchronizerProvider();
}
in Session and call it from the constructor instead of removing the
final so I did that in my code.
It works pretty well BUT I haven't found a way to get the page class
in getTimeout without having the risk to trigger a resolvePageInstance
which will try to lock and then call getTimeout leading to a wonderful
stack overflow exception when dealing with
ListenerInterfaceRequestHandler.
Obviously (...) what interests me the most is the getTimeout in
ListenerInterfaceRequestHandler as it's often actions on buttons which
are long to run.
Here is what I have in mind for my Session class:
https://gist.github.com/gsmet/3b9e2775d25fadcef5ef
I must admit that an advice would be welcome as I wouldn't like to
have stack overflow errors popping out in weird edge cases.
Thanks!
--
Guillaume
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Lock timeout per page class
Hi Martin,
Yeah, I thought about that too but I'm not sure of the best place to
build the pageId - pageClassName map. Any advice about this?
Once I'll get this working, I'll build a PR for the few changes I made
in Wicket (based on what you proposed earlier). Would be nice to have
them in 6.18.
On Fri, Oct 24, 2014 at 8:59 AM, Martin Grigorov mgrigo...@apache.org wrote:
Hi Guillaume,
Sorry for not thinking more carefully about this the first time!
I'm afraid it is not possible to do it the way I suggested.
PageAccessSynchronizer is the entry point to start using a page and it
works only with pageId!
Here is a new hackish approach:
Store pageId - pageClassName map in the Session. Then when
PageAccessSynchronizer is requested to lock a page by id use that id to
resolve the class name and to decide what timeout to use.
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Thu, Oct 23, 2014 at 5:44 PM, Guillaume Smet guillaume.s...@gmail.com
wrote:
Hi Martin,
On Wed, Oct 22, 2014 at 9:51 AM, Martin Grigorov mgrigo...@apache.org
wrote:
I'd like to avoid moving the logic that gets the timeout from
Session.PageAccessSynchronizerProvider to PageAccessSynchronizer because
this way it will use Application.get() everytime and most apps don't need
to pay for this.
A way to make it possible for you is to remove the 'final'
from org.apache.wicket.Session#getPageManager and introduce overridable
PageAccessSynchronizer#getTimeout(). This way you can use your own
PageAccessSynchronizer.
http://pastie.org/9667070
After a few experiments, here I am!
So, it mostly works: I thought it would be better to add something like:
protected IProviderPageAccessSynchronizer
newPageAccessSynchronizerProvider()
{
return new PageAccessSynchronizerProvider();
}
in Session and call it from the constructor instead of removing the
final so I did that in my code.
It works pretty well BUT I haven't found a way to get the page class
in getTimeout without having the risk to trigger a resolvePageInstance
which will try to lock and then call getTimeout leading to a wonderful
stack overflow exception when dealing with
ListenerInterfaceRequestHandler.
Obviously (...) what interests me the most is the getTimeout in
ListenerInterfaceRequestHandler as it's often actions on buttons which
are long to run.
Here is what I have in mind for my Session class:
https://gist.github.com/gsmet/3b9e2775d25fadcef5ef
I must admit that an advice would be welcome as I wouldn't like to
have stack overflow errors popping out in weird edge cases.
Thanks!
--
Guillaume
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Lock timeout per page class
Hi Martin,
On Wed, Oct 22, 2014 at 9:51 AM, Martin Grigorov mgrigo...@apache.org wrote:
I'd like to avoid moving the logic that gets the timeout from
Session.PageAccessSynchronizerProvider to PageAccessSynchronizer because
this way it will use Application.get() everytime and most apps don't need
to pay for this.
A way to make it possible for you is to remove the 'final'
from org.apache.wicket.Session#getPageManager and introduce overridable
PageAccessSynchronizer#getTimeout(). This way you can use your own
PageAccessSynchronizer.
http://pastie.org/9667070
After a few experiments, here I am!
So, it mostly works: I thought it would be better to add something like:
protected IProviderPageAccessSynchronizer newPageAccessSynchronizerProvider()
{
return new PageAccessSynchronizerProvider();
}
in Session and call it from the constructor instead of removing the
final so I did that in my code.
It works pretty well BUT I haven't found a way to get the page class
in getTimeout without having the risk to trigger a resolvePageInstance
which will try to lock and then call getTimeout leading to a wonderful
stack overflow exception when dealing with
ListenerInterfaceRequestHandler.
Obviously (...) what interests me the most is the getTimeout in
ListenerInterfaceRequestHandler as it's often actions on buttons which
are long to run.
Here is what I have in mind for my Session class:
https://gist.github.com/gsmet/3b9e2775d25fadcef5ef
I must admit that an advice would be welcome as I wouldn't like to
have stack overflow errors popping out in weird edge cases.
Thanks!
--
Guillaume
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Lock timeout per page class
Hi, We have a few pages in our application which might take a long time to generate. This is definitely not the usual case but there are a few of them. Thus we were forced to define a high lockTimeout to be sure these pages can be served. The fact is that we would really like to have a far lower default timeout except for these pages. Is there a way to configure the lockTimeout on a per page basis (I haven't found one)? If not, would it be a good idea to provide a way to do so? Thanks for your feedback. -- Guillaume - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Lock timeout per page class
Thanks Martin! We will give it a try and post what we got. -- Guillaume On Tue, Oct 21, 2014 at 1:19 PM, Martin Grigorov mgrigo...@apache.org wrote: Hi Guillaume, You can use org.apache.wicket.request.cycle.PageRequestHandlerTracker#getFirstHandler() to check what is the requested page in your own org.apache.wicket.settings.def.RequestCycleSettings#getTimeout Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Tue, Oct 21, 2014 at 1:12 PM, Guillaume Smet guillaume.s...@gmail.com wrote: Hi, We have a few pages in our application which might take a long time to generate. This is definitely not the usual case but there are a few of them. Thus we were forced to define a high lockTimeout to be sure these pages can be served. The fact is that we would really like to have a far lower default timeout except for these pages. Is there a way to configure the lockTimeout on a per page basis (I haven't found one)? If not, would it be a good idea to provide a way to do so? Thanks for your feedback. -- Guillaume - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Lock timeout per page class
Hi Martin, On Tue, Oct 21, 2014 at 1:19 PM, Martin Grigorov mgrigo...@apache.org wrote: You can use org.apache.wicket.request.cycle.PageRequestHandlerTracker#getFirstHandler() to check what is the requested page in your own org.apache.wicket.settings.def.RequestCycleSettings#getTimeout Cute trick but it doesn't work: the timeout is determined once and for all when the PageAccessSynchronizer is instantiated (see Session$PageAccessSynchronizerProvider). And AFAICS, the PageAccessSynchronizer is too low level to be a good place to manipulate the RequestCycle. Or am I wrong? -- Guillaume - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [ANNOUNCE] Apache Wicket 6.17.0 released
On Tue, Sep 9, 2014 at 9:08 AM, Guillaume Smet guillaume.s...@gmail.com wrote: I reported it to Sonatype: https://getsatisfaction.com/sonatype/topics/wicket-6-17-0-in-central-but-not-on-search-maven-org Joel fixed it. -- Guillaume - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [ANNOUNCE] Apache Wicket 6.17.0 released
Hi, On Tue, Sep 9, 2014 at 8:46 AM, Martin Grigorov mgrigo...@apache.org wrote: I use this URL to check: http://central.maven.org/maven2/org/apache/wicket/wicket-core/6.17.0/ Most probably the index of search.maven.org is broken ... I reported it to Sonatype: https://getsatisfaction.com/sonatype/topics/wicket-6-17-0-in-central-but-not-on-search-maven-org . We use search.maven.org at artifact-listener.org so Wicket 6.17.0 is still unannounced there too... -- Guillaume - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket / OAuth2
Hi, We use Spring Security for Artifact Listener but I think the general principle should be the same: https://github.com/openwide-java/artifact-listener/ and you might find it interesting to see how we did it. Martin already mentioned it earlier but we use pac4j for OpenId/OAuth/whatever. -- Guillaume On Tue, Sep 2, 2014 at 12:11 PM, Martin Grigorov mgrigo...@apache.org wrote: Hi Sebastien, The button is just a UI. But the idea is the same. The difference is that the OAuth provider is rather an authentication service than an authorization one. Usually the user of some social network doesn't want to share his details with random apps (like yours and mine). So when you create an application at Twitter, Facebook, ... you have to specify what kind of details you want to be sent to the callback url. When an user authenticates (s)he is asked whether (s)he is willing to share these details (e.g. username, email, gender, ...). In my experience users use OAuth for authentication: 1) to reduce the number of accounts they have 2) to reduce the information they provide to random apps So (usually) the OAuth provider doesn't send much info about the authenticated user when calling your callback. I haven't seen anything like roles and privileges in the OAuth responses. It could be that I don't have enough experience with OAuth but I think the authorization part is left to the application. About your use case: - the user tries to load some protected resource/page - the application should: -- store the details about the requested resource (url + post data) -- redirect to the authentication url of the OAuth provider by passing the callback url - if the user agrees to share the required data then your callback url is called with the data. You should use it like normal authentication token, create a User in the session, etc. P.S. I have used a popup window for the authentication because if the user is not willing to share all the required info then the oauth provider may not call the callback url and your user may not return to your app and make a normal account Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Tue, Sep 2, 2014 at 12:46 PM, Sebastien seb...@gmail.com wrote: Hi Martin, The question is not much about having a signin button to authenticate the user but more how to make it work with AuthenticatedWebApplication (or a custom OAuthWebApplication for instance). The final goal is to keep IRoleCheckingStrategy working ie: the user access an @AuthorizeInstantiation annotated page, #restartResponseAtSignInPage (for instance) redirect to the OAuth url, the OAuth service redirect to a callback, which callback is a wicket IRequestHandler, the handler sets isSigninedIn to true, sets the roles and then call #redirectToOriginalDestination. That's how I see things, but I don't see any existing wicket solutions... Is the usecase more clear? Thanks again, Sebastien. On Tue, Sep 2, 2014 at 9:06 AM, Martin Grigorov mgrigo...@apache.org wrote: Hi Sebastien, What exactly do you need ? I have used https://github.com/fernandezpablo85/scribe-java to create Authenticate with Xyz buttons for signing in (e.g. with Facebook, Twitter and LinkedIn). The developer of Scribe doesn't like OAuth2 (as many other developers) and at some point he stated that he will not merge any new PRs for OAuth2 impls. I don't see this statement in the README now, so he may have changed his mind. Another auth client provider is https://github.com/leleuj/pac4j. I don't have experience with it but it looks like well maintained. Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Mon, Sep 1, 2014 at 6:58 PM, Sebastien seb...@gmail.com wrote: Hi all, AFAIS, there is nothing about a OAuth2 client in Wicket out-of-the-box or through a satellite project... Does somebody knows a *simple* solution for integrating OAuth2 into Wicket (like a OAuthWebApplication, or maybe a ready-to-use Filter, just giving Consumer Key, Consumer Secret URLs), without using spring-security and still keeping advantage of the role-based @AuthorizeInstantiation annotation for instance? Thanks a lot in advance, Sebastien. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: DiskDataStore errors in production
On Wed, May 14, 2014 at 9:59 PM, eaglei22 jchojnack...@gmail.com wrote: What can be causing these errors? is this more of a Tomcat thing or Wicket? Hard to guess. Get the pid of your Tomcat process and use lsof -p pid. You'll see which files are opened by your Tomcat. HTH -- Guillaume - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Connecting... in Firefox's tab title
Hi Sven, On Fri, Jun 7, 2013 at 10:36 PM, Sven Meier s...@meiers.net wrote: Yes please. And don't forget to add the collected information to it. Done: https://issues.apache.org/jira/browse/WICKET-5222 Quickstart and patch attached: it fixes the problem for us. Thanks. -- Guillaume - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Connecting... in Firefox's tab title
Hi, For quite a while now, we are seeing a weird behavior with Firefox: as soon as Wicket does an Ajax call, the tab title is changed to Connecting... and it doesn't get back to the original page title at all, even after the Ajax call returned. Does anybody else see this behavior? We don't see it with any other site doing Ajax calls, just with Wicket app. It looks like a detail but it's quite annoying to have a bunch of tabs named Connecting Thanks for your feedback. -- Guillaume - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Connecting... in Firefox's tab title
Hi,
After some digging, it's related to the multipart ajax request via
posting an iframe.
The iframe is removed in the onload of the iframe ( see
https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/ajax/res/js/wicket-ajax-jquery.js#L868
) and it seems to be problematic for Firefox.
Looks like there is some literature about it here:
http://stackoverflow.com/questions/7285866/never-ending-connecting-message-after-ajax-form-submit
and using a pattern like the following should fix it:
iframe.onload = function(){
// Do work with the content of the iframe…
setTimeout(function(){
iframe.parentNode.removeChild(iframe);
}, 0);
}
Note: we are using Wicket 6.8.0 and Firefox 21.
Should I open a JIRA and should I attach a quickstart to it? I'm AFK
till monday but should be able to do it on monday if needed.
Thanks.
--
Guillaume
On Fri, Jun 7, 2013 at 4:34 PM, Guillaume Smet guillaume.s...@gmail.com wrote:
Hi,
For quite a while now, we are seeing a weird behavior with Firefox: as
soon as Wicket does an Ajax call, the tab title is changed to
Connecting... and it doesn't get back to the original page title at
all, even after the Ajax call returned.
Does anybody else see this behavior?
We don't see it with any other site doing Ajax calls, just with Wicket app.
It looks like a detail but it's quite annoying to have a bunch of tabs
named Connecting
Thanks for your feedback.
--
Guillaume
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Mount a page class more than once.
On Fri, May 31, 2013 at 9:37 AM, Martin Grigorov mgrigo...@apache.org wrote: #mountPage(/test1.html, MyPageClass1.class) Moreover, it's usually a good idea to have different classes so you can build your link to these pages easily. -- Guillaume - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
New Open Source application using Wicket : artifact-listener.org
Hi, We wanted to present you our first Open Source application powered by Wicket. We use Wicket since 1.3 but it's the first application we can release as an Open Source project. It's a Maven Central notification service built on Wicket 6.8.0. Reason why we thought it might be interesting to post this on the list: - it's in Wicket and Open Source: https://github.com/openwide-java/artifact-listener/ and it might contain a few good ideas (at least, we hope so) - it can be handy to keep track of Wicket releases: https://www.artifact-listener.org/ Contributions/ideas/questions welcome. It's a very simple service we plan to maintain for a long time as we use it to keep track of all the Java components we use in our core framework. We have a lot of additional features in mind so stay tuned. Happy wicketing! -- Guillaume - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Link generation from outside of Wicket - was Re: [ANNOUNCE] Apache Wicket 6.7.0 Released!
Hi, On Thu, Apr 18, 2013 at 11:36 AM, Martijn Dashorst dasho...@apache.org wrote: Render a page or component to a String ComponentRenderer exposes two methods: `renderComponent` and `renderPage` and they do exactly what their names suggest. Happy emailing! This is really nice. We did it in a quite complicated way before that. Any chance the same could be done to generate links from outside of Wicket, which is also quite difficult to get right at the moment? I'm especially thinking about this recent thread on this subject: http://markmail.org/thread/a34vmcm6ulxgr3ed -- Guillaume - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Link generation from outside of Wicket - was Re: [ANNOUNCE] Apache Wicket 6.7.0 Released!
On Fri, Apr 19, 2013 at 4:30 PM, Martin Grigorov mgrigo...@apache.org wrote: What exactly you mean by outside of Wicket ? What Wicket objects you have access to ? The application name will be needed and a base url. Usually the current request's baseUrl is used to construct a full url. Without the base url Wicket can generate only context-absolute url. I'm in exactly the same situation as Martin Dietze. I have to generate URL to a Wicket page in a batch scheduled by Spring or Quartz. We did it following the guidance you gave to Martin but it's quite complicated. As you mentioned it, we have in a configuration parameter the scheme/host/port information and we generate an URL to a wicket page from there by getting the application by its name and building a fake request and a fake RequestCycle. FWIW, here is the current version of what we use: https://gist.github.com/gsmet/5421471 -- Guillaume - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Prioritize header items in html templates
On Wed, Mar 20, 2013 at 11:48 PM, Guillaume Smet guillaume.s...@gmail.com wrote: On Wed, Mar 20, 2013 at 12:58 PM, Martin Grigorov mgrigo...@apache.org wrote: Another user asked the same question so I added it to my demo app: https://github.com/martin-g/blogs/commit/d5a248a3a3d5369c9cdc66604eba384428e9d0a0 FWIW, the following does the trick for me: getResourceSettings().setHeaderItemComparator(new PriorityFirstComparator(true)); The parameter of the PriorityFirstComparator constructor is renderPageFirst. The default HeaderItemComparator is new PriorityFirstComparator(false); -- Guillaume - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Prioritize header items in html templates
On Wed, Mar 20, 2013 at 12:58 PM, Martin Grigorov mgrigo...@apache.org wrote: Another user asked the same question so I added it to my demo app: https://github.com/martin-g/blogs/commit/d5a248a3a3d5369c9cdc66604eba384428e9d0a0 Thanks Martin. Very helpful. -- Guillaume - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Prioritize header items in html templates
Hi, On Tue, Mar 19, 2013 at 2:07 PM, Martin Grigorov mgrigo...@apache.org wrote: You can use StringHeaderItem.forString(meta ...) and wrap it in PriotityHeaderItem/FilterHeaderItem if needed. We had the same question. Starting with Wicket 6, title and so on are lost in the resources lines. It was quite nice to have them on top of the head and the resources at the bottom of the head, especially when a customer starts to look at the HTML produced. I'm not sure having all these tags in the Java code is a good solution for this issue. It's mostly cosmetic so it's probably not worth spending too much time on this but if there is an easy solution for this issue, it might be worth it. -- Guillaume - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: documentation
Hi Philippe, On Tue, Jan 22, 2013 at 5:53 PM, Philippe Demaison ph.demai...@gmail.com wrote: Are you kidding ? First thing first, while everyone agrees that a good documentation is a good thing, you should consider that you don't pay anyone to write it. There are a couple of very good books about Wicket you can purchase at Amazon. And the Wicket examples library is really nice to understand how Wicket works and understand the best practices and how you should build your application. It took me a couple of hours to start developing my first components with Wicket, mainly by reading the examples. Probably less than the time you spent writing your emails. http://www.playframework.org/documentation/2.0.4/Home http://tapestry.apache.org/documentation.html I don't know these 2 frameworks and they might (or might not) have a better documentation than Wicket. The quality of a documentation isn't measured by the number of pages. You measure it by the time you spend learning the framework and how useful it is. https://developers.google.com/web-toolkit/doc/latest/DevGuide Well, while you might think at first glance GWT documentation is better, you're definitely wrong. And, considering the number of misarchitectured GWT applications I studied (and helped getting them fixed) for our customers, I'm pretty sure it's not that easy to get it right from the documentation. http://www.springsource.org/spring-framework#documentation Spring is a framework. Compare with the Spring MVC documentation if you want to compare Wicket's documentation with something. That said, I agree that Spring MVC documentation is really good but what really helps to understand the best practices is the sample applications developed by SpringSource. Really try to start learning Wicket by using the available documentation and especially http://www.wicket-library.com/wicket-examples/index.html and you'll see that it's efficient and a good starting point to learn the framework. If you don't want to give it a try and see by yourself, well, it's your choice. But before complaining about the quality of the documentation available, please consider reading it. -- Guillaume - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: WiQuery SortableBehavior/DroppableBehavior questions
Hi Benedikt, On Thu, Oct 25, 2012 at 6:30 PM, Benedikt Schlegel codecab.dri...@googlemail.com wrote: And i'm having an issue where the drop event isn't fired, when an item is dropped at the first position of another sortable. Is anyone else experiencing something similar or am I doing it wrong? This is due to the version of jQuery UI shipped with wiQuery 6.0 (jQuery UI 1.8.16 isn't compatible with jQuery 1.7, see http://bugs.jqueryui.com/ticket/7852 ). It's fixed in master as we upgraded jQuery UI to 1.8.24. I can't help you with the rest of your questions though. -- Guillaume - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: WiQuery 6.0
Hi Nick, On Tue, Oct 23, 2012 at 1:28 AM, Nick Pratt nbpr...@gmail.com wrote: I do see the imports of jquery and jquery.ui.autocomplete (which I checked are available and served by the web server) - there's just no wiquery-gen-uniqueid script in the page This is a bug. See my pending pull request here: https://github.com/WiQuery/wiquery/pull/9 If you don't use autoUpdate, this pull request is sufficient to get the autocomplete working. I'm working on another patch to get the autoUpdate feature working. -- Guillaume - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket 1.5.6, Ajax and expired page
Hi Martin, On Tue, May 15, 2012 at 8:44 AM, Martin Grigorov mgrigo...@apache.org wrote: Since https://issues.apache.org/jira/browse/WICKET-4014 (Wicket 1.5.1) Wicket is able to handle automatically page expiration for mounted pages. I.e. if the user clicks a link and the page is already expired then depending on I followed that and it's quite appreciated to reduce the number of page expired errors for our users. The problem I saw yesterday evening on our app is that the Ajax response was the entire HTML page (raw HTML output) and not a valid Ajax XML response. I don't think that's something expected. -- Guillaume - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Wicket 1.5.6, Ajax and expired page
Hi, I noticed this evening that when a page is expired, if we make an Ajax call from this page (autocomplete for example), the Ajax call returns a 302 and then the entire page content (and not a valid XML Ajax response) - I investigated it with Firebug as there's no error anywhere. Could it be related to WICKET-4454 ? We upgraded to 1.5.6 a few days ago. It might be that I never waited long enough to see the problem before but I'm pretty sure it was working correctly in previous versions. Thanks for your feedback. -- Guillaume - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Invalid URL generated when jsessionid is present
Hi Martin, On Fri, May 11, 2012 at 9:43 AM, Martin Grigorov mgrigo...@apache.org wrote: Upgrade to 1.5.6. Oh? I haven't found any JIRA on this very subject but I might have missed it. I usually upgrade very quickly after a release but the issue with stateless page + feedback fixed after the release is kinda annoying for us. That said, I'll test 1.5.6 to see if it fixes the problem and I'll decide what I do after that. Thanks for your quick answer and have a nice day. -- Guillaume - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Invalid URL generated when jsessionid is present
On Fri, May 11, 2012 at 11:05 AM, Martin Grigorov mgrigo...@apache.org wrote: There is a workaround for this. See the ticket for 1.5.7. Thanks for the pointer. I can confirm that the problem is fixed in 1.5.6. Thanks. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Invalid URL generated when jsessionid is present
Hi, Under certain circumstances when we navigate on our Wicket site, Wicket generates the following URL for a bookmarkable page link: /mount/point/.;jsessionid=C94BC23C58FD2972B34E5DE145C076BB The dot before the ;jsessionid= makes the mount point not recognized by Wicket. The problem is when I click on a link pointing to the exact same page I'm visiting. Any idea on how to fix it? Thanks. -- Guillaume - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: mapping / mounting of PIE.htc for IE
Hi Bert, On Tue, Apr 3, 2012 at 11:25 AM, Bert taser...@gmail.com wrote: I have to switch to absolute URLs for this. Thanks for reading It's not exactly the best solution in the world but, considering that PIE.htc is a hack, we use a pretty hackish solution: we declare all the styles on which we want to enable the PIE.htc filter directly in the page surrounded by a test on the IE version. This way, we can easily get the relative PIE.htc URL from Wicket. -- Guillaume - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Wicket 1.5 and weird error on redirect
Hello,
We are currently migrating our applications from Wicket 1.4 to 1.5.
I have a problem with a pattern we use for logout, namely:
public class LogoutPage extends WebPage {
public LogoutPage() {
AuthenticatedWebSession session = AuthenticatedWebSession.get();
if (session != null) {
session.invalidate();
}
setResponsePage(CoreWicketAuthenticatedApplication.get().getSignInPageClass());
}
}
In Wicket 1.4, it worked perfectly. The only change I made is that I
had to remove the setRedirect(true) for 1.5.
With 1.5, when I click on a bookmarkable link pointing to LogoutPage,
I have the following error:
org.apache.wicket.markup.MarkupNotFoundException: Can not determine
Markup. Component is not yet connected to a parent. [Page class =
fr.openwide.core.wicket.more.security.page.LogoutPage, id = 86, render
count = 1]
at org.apache.wicket.Component.getMarkup(Component.java:731)
at org.apache.wicket.Component.internalRender(Component.java:2312)
at org.apache.wicket.Component.render(Component.java:2275)
at org.apache.wicket.Page.renderPage(Page.java:1035)
at
org.apache.wicket.request.handler.render.WebPageRenderer.renderPage(WebPageRenderer.java:105)
at
org.apache.wicket.request.handler.render.WebPageRenderer.respond(WebPageRenderer.java:224)
at
org.apache.wicket.request.handler.RenderPageRequestHandler.respond(RenderPageRequestHandler.java:167)
at
org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:750)
at
org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64)
at
org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:252)
at
org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:209)
at
org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:280)
at
org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:162)
at
org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:218)
Any idea on why it doesn't work anymore and how I can fix it?
Thanks.
--
Guillaume
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket 1.5 and weird error on redirect
Hi Dan, On Sun, Dec 18, 2011 at 11:29 PM, Dan Retzlaff dretzl...@gmail.com wrote: Try throwing RestartResponseException instead of calling setResponsePage. This will stop the construction of your StopPage immediately. Thanks for your answer. Using throw new RestartResponseException(clazz); was indeed my next move but I was wondering if this behaviour with setResponsePage() was expected. It works with the exception so I'll go change that everywhere I use setResponsePage in a page. Regards, -- Guillaume - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
