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 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
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 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 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
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: 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 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 > 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 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" >>> 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 >>> > 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 av
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 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
> 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
>> 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
>> >> 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 IProvider
>> >> 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 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
> wrote:
>
>> Hi Martin,
>>
>> On Wed, Oct 22, 2014 at 9:51 AM, Martin Grigorov
>> 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 IProvider
>> 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 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 IProvider 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, On Tue, Oct 21, 2014 at 1:19 PM, Martin Grigorov 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: 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 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 > 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
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: [ANNOUNCE] Apache Wicket 6.17.0 released
On Tue, Sep 9, 2014 at 9:08 AM, Guillaume Smet 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 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 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 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 >> 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 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 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 . 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 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
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 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
"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
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
Re: Mount a page class more than once.
On Fri, May 31, 2013 at 9:37 AM, Martin Grigorov 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
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 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
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 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: Prioritize header items in html templates
On Wed, Mar 20, 2013 at 11:48 PM, Guillaume Smet wrote: > On Wed, Mar 20, 2013 at 12:58 PM, Martin Grigorov > 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 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 wrote:
> You can use StringHeaderItem.forString("") and wrap it in
> PriotityHeaderItem/FilterHeaderItem if needed.
We had the same question. Starting with Wicket 6, and so on
are lost in the resources lines. It was quite nice to have them on top
of the and the resources at the bottom of the ,
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 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 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 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- 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 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
On Fri, May 11, 2012 at 11:05 AM, Martin Grigorov 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
Re: Invalid URL generated when jsessionid is present
Hi Martin, On Fri, May 11, 2012 at 9:43 AM, Martin Grigorov 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
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 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
Re: Wicket 1.5 and weird error on redirect
Hi Dan, On Sun, Dec 18, 2011 at 11:29 PM, Dan Retzlaff 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
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
