Re: wicket version definition in maven poms

[Korbinian Bachl]

Any idea when that was and what module failed? 

I switched to it in 2018 for my main project and at that time it was a bit of a 
hard start, but thats long ago now.

- Ursprüngliche Mail -
> Von: "Ernesto Reinaldo Barreiro" 
> An: "dev" 
> Gesendet: Mittwoch, 19. Juni 2024 11:48:52
> Betreff: Re: wicket version definition in maven poms

> Hum... I have the vague idea that I asked the same questions long long time
> ago and someone pointed me to some maven plugin bug
> 
> On Wed, Jun 19, 2024 at 2:33 AM Korbinian Bachl
>  wrote:
> 
>> Hi,
>>
>> is there any reason wicket has static
>> 9.19.0-SNAPSHOTversion>
>> everywhere, even in modules
>>
>> 
>> org.apache.wicket
>> wicket-parent
>> 9.19.0-SNAPSHOTversion>
>> ../pom.xml
>> parent>
>>
>>
>>
>> instead of a single defined properties in Wicket Parent:
>>
>> ${revision}${changelist}version>
>> ...
>> 
>> 9.19.0
>> -SNAPSHOT
>> ...
>> properties>
>>
>>
>> and in submodules:
>>
>> 
>> org.apache.wicket
>> wicket-parent
>> ${revision}${changelist}version>
>> parent>
>>
>>
>> That feature was introduced in maven 3.5 in 2017.
>>
>> KB
>>
> 
> 
> --
> Regards - Ernesto Reinaldo Barreiro

wicket version definition in maven poms

[Korbinian Bachl]

Hi, 

is there any reason wicket has static 
9.19.0-SNAPSHOT 
everywhere, even in modules 

 
org.apache.wicket 
wicket-parent 
9.19.0-SNAPSHOT 
../pom.xml 
 



instead of a single defined properties in Wicket Parent: 

${revision}${changelist} 
... 
 
9.19.0 
-SNAPSHOT 
... 
 


and in submodules: 

 
org.apache.wicket 
wicket-parent 
${revision}${changelist} 
 


That feature was introduced in maven 3.5 in 2017. 

KB 

Re: ModalWindow and wicket 10

[Korbinian Bachl]

My apologies for asking, 
did you have any time for having a look at it yet?

If not, do you need any help with it?

- Ursprüngliche Mail -
> Von: "Sven Meier" 
> An: "dev" 
> Gesendet: Freitag, 20. Oktober 2023 12:16:53
> Betreff: Re: ModalWindow and wicket 10

> Hi,
> 
> I thought we already moved the old implementation to wicket-stuff, but
> apparently I forgot to do it actually.
> 
> For explanation: the old ModalWindow is riddled with JS and dynamically
> generated HTML markup which we didn't want to maintain any more.
> 
> Sven
> 
> 
> On 20.10.23 11:22, Korbinian Bachl wrote:
>> Hi,
>>
>> just a short question. Since wicket 10 removed ModalWindow and insists now on
>> using ModalDialog even so many features of ModalWindow aren't in ModalDialog
>> existing
>> (for example closeCallback, resize, move, header, closebutton, init of width,
>> height etc.etc).
>>
>> Would it maybe possible if the removal of ModalWindow gets postponed to 
>> wicket
>> 11?
>>
>> Problem is one can't use wicket 9 with jakarta (last lib that holds us back) 
>> and
>> we have the ModalWindows over so many places with usages that arent really
>> existing in ModalDialog anymore.
>> (Or maybe a ModalWindow from WicketStuff?)
>>
>> Best,
>>
> > KB

Re: ModalWindow and wicket 10

[Korbinian Bachl]

wicket-stuff would be really nice :)


- Ursprüngliche Mail -
> Von: "Sven Meier" 
> An: "dev" 
> Gesendet: Freitag, 20. Oktober 2023 12:16:53
> Betreff: Re: ModalWindow and wicket 10

> Hi,
> 
> I thought we already moved the old implementation to wicket-stuff, but
> apparently I forgot to do it actually.
> 
> For explanation: the old ModalWindow is riddled with JS and dynamically
> generated HTML markup which we didn't want to maintain any more.
> 
> Sven
> 
> 
> On 20.10.23 11:22, Korbinian Bachl wrote:
>> Hi,
>>
>> just a short question. Since wicket 10 removed ModalWindow and insists now on
>> using ModalDialog even so many features of ModalWindow aren't in ModalDialog
>> existing
>> (for example closeCallback, resize, move, header, closebutton, init of width,
>> height etc.etc).
>>
>> Would it maybe possible if the removal of ModalWindow gets postponed to 
>> wicket
>> 11?
>>
>> Problem is one can't use wicket 9 with jakarta (last lib that holds us back) 
>> and
>> we have the ModalWindows over so many places with usages that arent really
>> existing in ModalDialog anymore.
>> (Or maybe a ModalWindow from WicketStuff?)
>>
>> Best,
>>
> > KB

ModalWindow and wicket 10

[Korbinian Bachl]

Hi,

just a short question. Since wicket 10 removed ModalWindow and insists now on 
using ModalDialog even so many features of ModalWindow aren't in ModalDialog 
existing
(for example closeCallback, resize, move, header, closebutton, init of width, 
height etc.etc).

Would it maybe possible if the removal of ModalWindow gets postponed to wicket 
11?

Problem is one can't use wicket 9 with jakarta (last lib that holds us back) 
and we have the ModalWindows over so many places with usages that arent really 
existing in ModalDialog anymore. 
(Or maybe a ModalWindow from WicketStuff?)

Best,

KB

Re: Time for Wicket M1?

[Korbinian Bachl]

When looking at 
https://cwiki.apache.org/confluence/display/WICKET/Migration+to+Wicket+10.0

I wondered what Jakarta version is required? 
Is Jakarta 9.0 enough? Because, it says Java 17 needed - this is even above 
Jakarta 9.1 abd 10 that both have a JDK 11 baseline? 


Oh and also what does this remove of component-queuing mean?

Best,

KB

- Ursprüngliche Mail -
> Von: "Martin Grigorov" 
> An: "dev" 
> Gesendet: Donnerstag, 9. Februar 2023 07:45:50
> Betreff: Re: Time for Wicket M1?

> Please update
> https://cwiki.apache.org/confluence/display/WICKET/Migration+to+Wicket+10.0
> that the Component Queueing is gone
> 
> Before releasing M1 I think we need to:
> 1) update all dependencies to their latest stable version
> 2) copy over commons-fileupload2 classes to wicket-util or a new Maven
> module
> 
> 
> On Thu, Feb 9, 2023 at 7:49 AM Ernesto Reinaldo Barreiro 
> wrote:
> 
>> Hi Sven!
>>
>> On Wed, Feb 8, 2023 at 9:30 PM Sven Meier  wrote:
>>
>> > I've removed queuing on branch
>> > https://github.com/apache/wicket/tree/remove-queuing
>> > Still ready to be merged.
>> >
>> > We agreed to remove it from Wicket 10, didn't we?
>> >
>>
>> Yes! Many many thanks for your work. I remember someone complaining in
>> wicket's user list when thai was introduced about wicket being slower after
>> queuing.
>>
>> +1 to get rid of this.
>>
>>
>> > Sven
>> >
>> >
>> > On 08.02.23 12:54, Ernesto Reinaldo Barreiro wrote:
>> > > No idea. There was some effort (by Sven) to remove component
>> queueing...
>> > No
>> > > idea if that landed on the master branch?
>> > >
>> > > On Wed, Feb 8, 2023 at 1:03 PM Andrea Del Bene 
>> > wrote:
>> > >
>> > >> Hi,
>> > >>
>> > >> I've seen that lately there have been some activities and questions
>> > related
>> > >> to Wicket 10. Although we have some pending issues before proposing a
>> > >> release candidate, I think it's the right time for a first milestone
>> > >> release. What do you think?
>> > >>
>> > >> --
>> > >> Andrea Del Bene.
>> > >> Apache Wicket committer.
>> > >>
>> > >
>> >
>>
>>
>> --
>> Regards - Ernesto Reinaldo Barreiro

Re: an idea: wicket-resilient mode?

[Korbinian Bachl]

- Ursprüngliche Mail -
> 
> If you are ok with a 80% failing page, I cannot help you, because in that
> case you can simply come up with another fallback which works 80%. You know
> this leads/creeps to exponential growth of failures and work, yes?
> 
> The right way to handle it is to inform the user that something has failed,
> suggest the user to retry (or you can retry once programmatically if you
> think the problem is rare).
> 
> And receive alerts from such problems in production and find the root cause
> and fix it, for example by fixing a race condition issue by adding blocking
> queues or whatever best suits your use case.

Well, for me the thing is: if the whole page fails you need to fix it asap - if 
only 10% of the page fails you could ignore it some time and have it fixed at a 
later point in time when you have resources
free. 

I see this as a pure business administration problem: save money if possible... 
I know this is not something a programmer likes but nobody of us programms for 
free :)


> 
> And from my experience I never expect my code to not have bugs in it, so it
>> will fail at some point. I mean, why do we have so many regular wicket
>> releases if its bug free? ;)
>>
> 
> Is not about being bug free, but how to respond to bugs and how to curb
> bugs and how to curb the impact of bugs.

Right: have a way to ignore it a maximum amount of time till you fix it... 
based on the impact of the bug itself. 
In case the bug takes down everything you need to fix it asap. If it takes down 
only a part: depending on the part itself you react...

Re: an idea: wicket-resilient mode?

[Korbinian Bachl]

> ti 11. lokak. 2022 klo 11.12 Korbinian Bachl (korbinian.ba...@whiskyworld.de)
> kirjoitti:
> 
>>
>> >
>> > It is your application so you must know/design how to recover from the
>> > error. You either re-render the same page or redirect the user to a
>> > suitable error page.
>> >
>> > **
>> > Martin
>> >
>>
>> Thats exactly the misunderstanding. If one of 100s of components fails -
>> not even necessarily "made" by myself (.g.: some null pointer down the
>> drain of a Panel) - why should the whole rest of the page fail, too?
>> Why should we redirect and not just ignore the single root cause (a "bad"
>> component/ panel) silently?
>>
>> I mean, most of errors that occur in Prod for us are because something
>> happens that was never meant to be. Be it that backend data came in that
>> violated the contract (because of update of a third party service without
>> notice / or in error) or something else that is not know in advance.
>>
>> Point is: if a page consists of 1000 Components and only 1 of it fails:
>> why has this single point of failure the need to take down the rest of the
>> page?
>>
> 
> I think you should think of it like a transaction. A well designed page is
> like a transaction. If there is a fault, it should rollback everything.
> Otherwise, you need to design very carefully which faults you want to allow
> and which ones not. A quick-and-dirty way is to add catches to the sub
> panel rendering phases so that they don't care about the faults, but you
> will run a risk that your user is not getting consistent information. This
> might be a problem or it might not be.
> 
> Also, if you have lots of these, you probably have some sort of systematic
> design flaw in your application, try to debug heuristically it and solve it.
> 
> In my experience, the only situations where exceptions are "normal" in
> wicket is when there is some kind of invalid session and parts of the page
> attempt rendering while some other parts fail to render, and the correct
> action in such case is to discard rendering and redirect to login.
> 
> But your case might be different and you need to investigate the root
> cause. Otherwise you run risk of steering your product like a lost ship on
> the vast ocean with some unexpected harm ahead.
> 
> To summarize, unexpected exceptions in wicket are not normal, you should
> not allow them.
> 
> **
> Martin


I understand your point of view while not sure this is the correct interpretion 
to see a page as a "transaction". If there are forms, maybe you can see it that 
way but a page is usually a way to present information/ data.

I had some time to work with RoR lately and the way it evolved in the last 
years and also solved many problems with clever convention over configuration 
let me rethink some of my previous ways. 
Also backend frameworks like e.g. micronaut have baked in things like retryable 
or CircuitBreaker because they just *expect* it that something will fail 
anytime anyhow.

In our prod app we got a 500 because of a dumb null pointer that happend 
because of a rare race condition depending on the backend... something that was 
clearly a fault initially but only with the current way to fail the whole page 
made it a problem. 

The idea is just to not fail a whole page but only the part of the page that 
fails - while logging in the backend so that the usage of the page is not 0 but 
maybe still 80%

And from my experience I never expect my code to not have bugs in it, so it 
will fail at some point. I mean, why do we have so many regular wicket releases 
if its bug free? ;)

PS: can you elaborate how to globally alter the sub panel phases?

Re: an idea: wicket-resilient mode?

[Korbinian Bachl]

 
> 
> It is your application so you must know/design how to recover from the
> error. You either re-render the same page or redirect the user to a
> suitable error page.
> 
> **
> Martin
> 

Thats exactly the misunderstanding. If one of 100s of components fails - not 
even necessarily "made" by myself (.g.: some null pointer down the drain of a 
Panel) - why should the whole rest of the page fail, too? 
Why should we redirect and not just ignore the single root cause (a "bad" 
component/ panel) silently?

I mean, most of errors that occur in Prod for us are because something happens 
that was never meant to be. Be it that backend data came in that violated the 
contract (because of update of a third party service without notice / or in 
error) or something else that is not know in advance.

Point is: if a page consists of 1000 Components and only 1 of it fails: why has 
this single point of failure the need to take down the rest of the page?

Re: an idea: wicket-resilient mode?

[Korbinian Bachl]

Hello Martin,

thanks for the advise and I looked at it, however, I am not sure how to solve 
my original idea here.

I can swallow any error thats RuntimeException in onException in 
IRequestCycleListener, but this leads not to the rest of the page magically 
working, does it?

I mean I can add a new RequestCycleListener with 

@Override
public IRequestHandler onException(RequestCycle cycle, Exception ex) {
..

if(ex instanceof RuntimeException) {
//swallow it
return null;
}


in it. But as soon as we got a e.g.: 

throw new RuntimeException("test");

anywhere in the constructor/onInit of any component the error is again 500, with
ERROR [org.apache.wicket.DefaultExceptionMapper] Unexpected error occurred
java.lang.RuntimeException: test 
[...]

behind it.

My idea is that the component - and only that single component - that fails 
gets "blanked" out as it is not existing while the rest of the page would work 
regular. 


Or did I missunderstand anything here?

Best,

KB




- Ursprüngliche Mail -
> Von: "Martin Terra" 
> An: "dev" 
> Gesendet: Montag, 10. Oktober 2022 10:03:34
> Betreff: Re: an idea: wicket-resilient mode?

> It has evolved a bit:
> https://cwiki.apache.org/confluence/display/WICKET/Migration+to+Wicket+1.5#MigrationtoWicket1.5-RequestCycle
> 
> **
> Martin
> 
> ma 10. lokak. 2022 klo 10.11 Martin Terra (martin.te...@koodaripalvelut.com)
> kirjoitti:
> 
>> Yes. You can override runtime handling yourself @
>> RequestCycle.onRuntimeException (at least used to be with such name)
>>
>> In production it is recommended to do so as you best see fit.
>>
>> **
>> Martin
>>
>> ma 10. lokak. 2022 klo 9.45 Korbinian Bachl (
>> korbinian.ba...@whiskyworld.de) kirjoitti:
>>
>>> Hi,
>>>
>>> we use wicket for many years now and so far it is a great framework to
>>> use. One thing that however seems still a bit of a problem is the way
>>> wicket handles (runtime) errors.
>>> If you look at a page then the content is often composed of 100's of
>>> panels and components.
>>> As long as every single component is working all is fine... but if just 1
>>> of the many 100 components has any kind of runtime-errors it leads to a 500
>>> server error.
>>> So I wondered: what stops us from letting wicket have a "resilient mode"?
>>> - A mode where an runtime error in any component doesnt lead to the error
>>> beeing done as a 500 but instead only let this single component/panel
>>> silently fail (by not outputting it - as if it would be .visible(false))
>>> and do this gracefully in the background?
>>> While wicket doing error-logging in the background?
>>> All beeing done by having a setting to let wicket be gracefully/resilient
>>> in deploymode?
>>>
>>> What do you think about this approach?
>>>
>>> Best,
>>>
>>> Korbinian
>>>
>>>
>>>

an idea: wicket-resilient mode?

[Korbinian Bachl]

Hi,

we use wicket for many years now and so far it is a great framework to use. One 
thing that however seems still a bit of a problem is the way wicket handles 
(runtime) errors. 
If you look at a page then the content is often composed of 100's of panels and 
components. 
As long as every single component is working all is fine... but if just 1 of 
the many 100 components has any kind of runtime-errors it leads to a 500 server 
error. 
So I wondered: what stops us from letting wicket have a "resilient mode"? 
- A mode where an runtime error in any component doesnt lead to the error 
beeing done as a 500 but instead only let this single component/panel silently 
fail (by not outputting it - as if it would be .visible(false)) and do this 
gracefully in the background?
While wicket doing error-logging in the background?
All beeing done by having a setting to let wicket be gracefully/resilient in 
deploymode?

What do you think about this approach?

Best,

Korbinian

Re: [DISCUSSION] Shall we clean-up git branches?

[Korbinian Bachl]

I wouldn't drop any of the wicket-x.x branches as these were the releases and 
imagine you had to use wicket 1.4 in an old app and need a fix asap?


- Ursprüngliche Mail -
> Von: "Maxim Solodovnik" 
> An: "dev" 
> Gesendet: Donnerstag, 28. April 2022 09:01:09
> Betreff: Re: [DISCUSSION] Shall we clean-up git branches?

> Maybe we can drop all branches older than 2 years ago? :)
> 
> On Thu, 28 Apr 2022 at 13:30, Maxim Solodovnik  wrote:
>>
>> Merged are dropped
>> 121 branch remains :)
>>
>> On Thu, 28 Apr 2022 at 12:54, Martin Grigorov  wrote:
>> >
>> > Hi,
>> >
>> > Easy win is to delete all branches which are already merged.
>> > The next step is to review the "closed" ones.
>> >
>> > On Thu, Apr 28, 2022 at 5:55 AM Maxim Solodovnik 
>> > wrote:
>> >
>> > > Hello All,
>> > >
>> > > Currently we have 130 git branches:
>> > > https://github.com/apache/wicket/branches
>> > > Maybe we can perform clean-up? :))
>> > >
>> > > --
>> > > Best regards,
>> > > Maxim
>> > >
>>
>>
>>
>> --
>> Best regards,
>> Maxim
> 
> 
> 
> --
> Best regards,
> Maxim

Re: wicket 9.9.0 - MarkupExceptions after upgrade - any idea why I get this?

[Korbinian Bachl]

PS: with "rendering" I mean the kind of page composition from changed HTML 
source, not the rerendering in terms of changed on page content due to Java 
code... 

I think I have expressed myself not clear and good here. Sorry :(

- Ursprüngliche Mail -
> Von: "Korbinian Bachl" 
> An: "dev" 
> Gesendet: Freitag, 1. April 2022 12:27:19
> Betreff: Re: wicket 9.9.0 - MarkupExceptions after upgrade - any idea why I 
> get this?

> Hi Thomas,
> 
> it is indeed WICKET-6963. The reason from my understanding is the way we 
> "treat"
> pages & components here. I tried to make a small wicket quickstart to show the
> problem but I wasn't able to reproduce the problem. I then tried to reproduce
> it with our cms base (https://github.com/brix-cms/brix-cms) and then it 
> happens
> on rare occasions (even DEMO works... one just must hammer it with jmeter or
> sth like that - much concurrence needed).
> 
> See, we use brix cms and this has custom tags tiles etc. as well as a custom
> page that renders the content:
> https://github.com/brix-cms/brix-cms/blob/master/brix-core/src/main/java/org/brixcms/web/nodepage/BrixNodeWebPage.java
> https://github.com/brix-cms/brix-cms/blob/master/brix-core/src/main/java/org/brixcms/markup/web/BrixMarkupNodeWebPage.java
> 
> What brix does is, basically spoken, it takes a node from a JCR and 
> understands
> this as a kind of receipe to create a wicket page, decorate it with tiles
> (special kind of wicket-panels in brix terms), header items etc. Thus 
> rendering
> and rerendering pages often... very often (contrary to regular wicket apps...
> these usually only render once as HTML-sources stays fixed - see
> https://github.com/brix-cms/brix-cms/wiki/Templating ).
> When now many concurrenct requests come in and at the same time it rerenders
> something then the final static with the "wrong" flag gets leaked into the
> wrong rendering and therefore creates this 503 errors.
> 
> AFAIK a "static final" even allows java to reuse this item in any other 
> threads
> without any limitations as only the reference is thread safe but not the
> contents - am I right here?
> 
> 
> Anyway, I can asure you that I made a nearly similar mistake by myself not 
> long
> ago when I thought I optimize some fields to final static and only production
> errors let me know :X
> 
> 
> Do you know when a 9.9.1 will be out?
> 
> Best,
> 
> KB
> 
> 
> 
> 
> 
> - Ursprüngliche Mail -
>> Von: "Thomas Heigl"
>> An: "dev" 
>> Gesendet: Donnerstag, 31. März 2022 11:35:45
>> Betreff: Re: wicket 9.9.0 - MarkupExceptions after upgrade - any idea why I 
>> get
>> this?
> 
>> It's just a single commit. I have reverted it for both 9.x and master.
>> 
>> Best,
>> 
>> Thomas
>> 
>> On Thu, Mar 31, 2022 at 11:06 AM Andrea Del Bene
>> wrote:
>> 
>>> On Thu, Mar 31, 2022 at 10:33 AM Thomas Heigl  wrote:
>>>
>>> > Ok I had a closer look at AssociatedMarkupSourcingStrategy and the code
>>> > related to this flag is quite convoluted and full of TODOs and WHY
>>> > comments. I think I will have to do another take on this and replace the
>>> > field with a parameter, but this will take some time.
>>> >
>>> > I would suggest we revert WICKET-6963 for now and release 9.9.1.
>>> >
>>> > Sorry for that! I was confident that my change was good, because it
>>> worked
>>> > without problems in our production environment.
>>> >
>>> >
>>>  Don't worry, these things happened :-) . Could you take care of reverting
>>> WICKET-6963 on git? Or if it's just a commit I can do it by myself.
>>>
>>>
>>> > Thomas
>>> >
>>> > On Thu, Mar 31, 2022 at 10:18 AM Thomas Heigl
>>> wrote:
>>> >
>>> > > Although the JavaDoc states that this should be possible:
>>> > >
>>> > >   // reset for each render in case the strategy is re-used
>>> > > noMoreWicketHeadTagsAllowed = false;
>>> > >
>>> > > It would be great if we had a failing test-case for this. In my
>>> > production
>>> > > environment with about 5000 panels, there are none of these issues.
>>> > >
>>> > > Thomas
>>> > >
>>> > > On Thu, Mar 31, 2022 at 10:14 AM Thomas Heigl
>>> > wrote:
>>> > >
>>> > >> I think we will have to revert WICKET-6963.
>>> > 

Re: wicket 9.9.0 - MarkupExceptions after upgrade - any idea why I get this?

[Korbinian Bachl]

Hi Thomas,

it is indeed WICKET-6963. The reason from my understanding is the way we 
"treat" pages & components here. I tried to make a small wicket quickstart to 
show the problem but I wasn't able to reproduce the problem. I then tried to 
reproduce it with our cms base (https://github.com/brix-cms/brix-cms) and then 
it happens on rare occasions (even DEMO works... one just must hammer it with 
jmeter or sth like that - much concurrence needed).

See, we use brix cms and this has custom tags tiles etc. as well as a custom 
page that renders the content:
https://github.com/brix-cms/brix-cms/blob/master/brix-core/src/main/java/org/brixcms/web/nodepage/BrixNodeWebPage.java
 
https://github.com/brix-cms/brix-cms/blob/master/brix-core/src/main/java/org/brixcms/markup/web/BrixMarkupNodeWebPage.java

What brix does is, basically spoken, it takes a node from a JCR and understands 
this as a kind of receipe to create a wicket page, decorate it with tiles 
(special kind of wicket-panels in brix terms), header items etc. Thus rendering 
and rerendering pages often... very often (contrary to regular wicket apps... 
these usually only render once as HTML-sources stays fixed - see 
https://github.com/brix-cms/brix-cms/wiki/Templating ). 
When now many concurrenct requests come in and at the same time it rerenders 
something then the final static with the "wrong" flag gets leaked into the 
wrong rendering and therefore creates this 503 errors.

AFAIK a "static final" even allows java to reuse this item in any other threads 
without any limitations as only the reference is thread safe but not the 
contents - am I right here?


Anyway, I can asure you that I made a nearly similar mistake by myself not long 
ago when I thought I optimize some fields to final static and only production 
errors let me know :X


Do you know when a 9.9.1 will be out?

Best,

KB





- Ursprüngliche Mail -
> Von: "Thomas Heigl" 
> An: "dev" 
> Gesendet: Donnerstag, 31. März 2022 11:35:45
> Betreff: Re: wicket 9.9.0 - MarkupExceptions after upgrade - any idea why I 
> get this?

> It's just a single commit. I have reverted it for both 9.x and master.
> 
> Best,
> 
> Thomas
> 
> On Thu, Mar 31, 2022 at 11:06 AM Andrea Del Bene 
> wrote:
> 
>> On Thu, Mar 31, 2022 at 10:33 AM Thomas Heigl  wrote:
>>
>> > Ok I had a closer look at AssociatedMarkupSourcingStrategy and the code
>> > related to this flag is quite convoluted and full of TODOs and WHY
>> > comments. I think I will have to do another take on this and replace the
>> > field with a parameter, but this will take some time.
>> >
>> > I would suggest we revert WICKET-6963 for now and release 9.9.1.
>> >
>> > Sorry for that! I was confident that my change was good, because it
>> worked
>> > without problems in our production environment.
>> >
>> >
>>  Don't worry, these things happened :-) . Could you take care of reverting
>> WICKET-6963 on git? Or if it's just a commit I can do it by myself.
>>
>>
>> > Thomas
>> >
>> > On Thu, Mar 31, 2022 at 10:18 AM Thomas Heigl 
>> wrote:
>> >
>> > > Although the JavaDoc states that this should be possible:
>> > >
>> > >   // reset for each render in case the strategy is re-used
>> > > noMoreWicketHeadTagsAllowed = false;
>> > >
>> > > It would be great if we had a failing test-case for this. In my
>> > production
>> > > environment with about 5000 panels, there are none of these issues.
>> > >
>> > > Thomas
>> > >
>> > > On Thu, Mar 31, 2022 at 10:14 AM Thomas Heigl 
>> > wrote:
>> > >
>> > >> I think we will have to revert WICKET-6963.
>> > >>
>> > >> I somehow overlooked the non-final field noMoreWicketHeadTagsAllowed
>> > >> in AssociatedMarkupSourcingStrategy. If this flag gets set, the
>> > singleton
>> > >> strategy doesn't work.
>> > >>
>> > >> Thomas
>> > >>
>> > >> On Thu, Mar 31, 2022 at 10:11 AM Thomas Heigl 
>> > >> wrote:
>> > >>
>> > >>> This is probably caused by my change in
>> > >>> https://issues.apache.org/jira/browse/WICKET-6963
>> > >>>
>> > >>> I have been using this code in production for a couple of weeks now
>> > >>> without issues, but there seem to be cases where the singleton
>> strategy
>> > >>> doesn't work.
>> > >>>
>> > >>> Can you reproduce this issue in a

Re: wicket 9.9.0 - MarkupExceptions after upgrade - any idea why I get this?

[Korbinian Bachl]

I've looked at 
https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/markup/html/panel/AssociatedMarkupSourcingStrategy.java
 
and I somehow wonder if we couldn't get rid of this 
private boolean noMoreWicketHeadTagsAllowed = false;

at all?

It seems to be questioned in the past already:

"// wicket:head must be before border, panel or extend
// @TODO why is that? Why can't it be anywhere? (except inside wicket:fragment)"

my 2cents...



- Ursprüngliche Mail -
> Von: "Thomas Heigl" 
> An: "dev" 
> Gesendet: Donnerstag, 31. März 2022 10:18:12
> Betreff: Re: wicket 9.9.0 - MarkupExceptions after upgrade - any idea why I 
> get this?

> Although the JavaDoc states that this should be possible:
> 
>  // reset for each render in case the strategy is re-used
> noMoreWicketHeadTagsAllowed = false;
> 
> It would be great if we had a failing test-case for this. In my production
> environment with about 5000 panels, there are none of these issues.
> 
> Thomas
> 
> On Thu, Mar 31, 2022 at 10:14 AM Thomas Heigl  wrote:
> 
>> I think we will have to revert WICKET-6963.
>>
>> I somehow overlooked the non-final field noMoreWicketHeadTagsAllowed
>> in AssociatedMarkupSourcingStrategy. If this flag gets set, the singleton
>> strategy doesn't work.
>>
>> Thomas
>>
>> On Thu, Mar 31, 2022 at 10:11 AM Thomas Heigl  wrote:
>>
>>> This is probably caused by my change in
>>> https://issues.apache.org/jira/browse/WICKET-6963
>>>
>>> I have been using this code in production for a couple of weeks now
>>> without issues, but there seem to be cases where the singleton strategy
>>> doesn't work.
>>>
>>> Can you reproduce this issue in a test-case?
>>>
>>> Thomas
>>>
>>> On Thu, Mar 31, 2022 at 10:06 AM Maxim Solodovnik 
>>> wrote:
>>>
>>>> " tags are only allowed before , ,
>>>> 
>>>> etc. tag"
>>>> sounds reasonable :)
>>>>
>>>> On Thu, 31 Mar 2022 at 14:56, Korbinian Bachl <
>>>> korbinian.ba...@whiskyworld.de> wrote:
>>>>
>>>> > Hi,
>>>> >
>>>> > I deployed our app on 9.9.0 this morning and after initializing a
>>>> crawl of
>>>> > the page I ended up getting a low quote of 503s.
>>>> >
>>>> > The 503s are always the same:
>>>> > 2022-03-31 09:35:05,031 ERROR
>>>> [org.apache.wicket.DefaultExceptionMapper]
>>>> > Unexpected error occurred
>>>> > org.apache.wicket.markup.MarkupException:  tags are only
>>>> > allowed before , ,  etc. tag
>>>> > at
>>>> >
>>>> org.apache.wicket.markup.html.panel.AssociatedMarkupSourcingStrategy.nextHeaderMarkup(AssociatedMarkupSourcingStrategy.java:341)
>>>> > ~[wicket-core-9.9.0.jar:9.9.0]
>>>> > at
>>>> >
>>>> org.apache.wicket.markup.html.panel.AssociatedMarkupSourcingStrategy.renderHeadFromAssociatedMarkupFile(AssociatedMarkupSourcingStrategy.java:236)
>>>> > ~[wicket-core-9.9.0.jar:9.9.0]
>>>> > at
>>>> >
>>>> org.apache.wicket.markup.html.panel.AssociatedMarkupSourcingStrategy.renderHead(AssociatedMarkupSourcingStrategy.java:204)
>>>> > ~[wicket-core-9.9.0.jar:9.9.0]
>>>> > at
>>>> > org.apache.wicket.Component.internalRenderHead(Component.java:2649)
>>>> > ~[wicket-core-9.9.0.jar:9.9.0]
>>>> > 
>>>> > at
>>>> >
>>>> org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:569)
>>>> > [nucleus-grizzly-all.jar:?] at
>>>> >
>>>> org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:549)
>>>> > [nucleus-grizzly-all.jar:?] at java.lang.Thread.run(Thread.java:829)
>>>> [?:?]
>>>> >
>>>> > Any idea how to debug this or where it may come from (race condition in
>>>> > our code as wicket became faster?)?
>>>> > It somehow seems to be a happen when requests coming in at the same
>>>> > time with 9.8.0 we got no such errors.
>>>> >
>>>> > Best,
>>>> >
>>>> > KB
>>>> >
>>>> >
>>>> >
>>>> >
>>>>
>>>> --
>>>> Best regards,
>>>> Maxim
>>>>

Re: wicket 9.9.0 - MarkupExceptions after upgrade - any idea why I get this?

[Korbinian Bachl]

Well, the only thing I did was change wicket-9.8.0 to wicket-9.9.0 
then I get these errors in production. After reverting to 9.8.0 these are 
gone 
I never touched any HTML files in between the deploys :X

What has happened here?

- Ursprüngliche Mail -
> Von: "Maxim Solodovnik" 
> An: "dev" 
> Gesendet: Donnerstag, 31. März 2022 10:06:34
> Betreff: Re: wicket 9.9.0 - MarkupExceptions after upgrade - any idea why I 
> get this?

> " tags are only allowed before , , 
> etc. tag"
> sounds reasonable :)
> 
> On Thu, 31 Mar 2022 at 14:56, Korbinian Bachl <
> korbinian.ba...@whiskyworld.de> wrote:
> 
>> Hi,
>>
>> I deployed our app on 9.9.0 this morning and after initializing a crawl of
>> the page I ended up getting a low quote of 503s.
>>
>> The 503s are always the same:
>> 2022-03-31 09:35:05,031 ERROR [org.apache.wicket.DefaultExceptionMapper]
>> Unexpected error occurred
>> org.apache.wicket.markup.MarkupException:  tags are only
>> allowed before , ,  etc. tag
>> at
>> org.apache.wicket.markup.html.panel.AssociatedMarkupSourcingStrategy.nextHeaderMarkup(AssociatedMarkupSourcingStrategy.java:341)
>> ~[wicket-core-9.9.0.jar:9.9.0]
>> at
>> org.apache.wicket.markup.html.panel.AssociatedMarkupSourcingStrategy.renderHeadFromAssociatedMarkupFile(AssociatedMarkupSourcingStrategy.java:236)
>> ~[wicket-core-9.9.0.jar:9.9.0]
>> at
>> org.apache.wicket.markup.html.panel.AssociatedMarkupSourcingStrategy.renderHead(AssociatedMarkupSourcingStrategy.java:204)
>> ~[wicket-core-9.9.0.jar:9.9.0]
>> at
>> org.apache.wicket.Component.internalRenderHead(Component.java:2649)
>> ~[wicket-core-9.9.0.jar:9.9.0]
>> 
>> at
>> org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:569)
>> [nucleus-grizzly-all.jar:?] at
>> org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:549)
>> [nucleus-grizzly-all.jar:?] at java.lang.Thread.run(Thread.java:829) [?:?]
>>
>> Any idea how to debug this or where it may come from (race condition in
>> our code as wicket became faster?)?
>> It somehow seems to be a happen when requests coming in at the same
>> time with 9.8.0 we got no such errors.
>>
>> Best,
>>
>> KB
>>
>>
>>
>>
> 
> --
> Best regards,
> Maxim

wicket 9.9.0 - MarkupExceptions after upgrade - any idea why I get this?

[Korbinian Bachl]

Hi, 

I deployed our app on 9.9.0 this morning and after initializing a crawl of the 
page I ended up getting a low quote of 503s. 

The 503s are always the same: 
2022-03-31 09:35:05,031 ERROR [org.apache.wicket.DefaultExceptionMapper] 
Unexpected error occurred
org.apache.wicket.markup.MarkupException:  tags are only allowed 
before , ,  etc. tag 
at 
org.apache.wicket.markup.html.panel.AssociatedMarkupSourcingStrategy.nextHeaderMarkup(AssociatedMarkupSourcingStrategy.java:341)
 ~[wicket-core-9.9.0.jar:9.9.0]
at 
org.apache.wicket.markup.html.panel.AssociatedMarkupSourcingStrategy.renderHeadFromAssociatedMarkupFile(AssociatedMarkupSourcingStrategy.java:236)
 ~[wicket-core-9.9.0.jar:9.9.0]
at 
org.apache.wicket.markup.html.panel.AssociatedMarkupSourcingStrategy.renderHead(AssociatedMarkupSourcingStrategy.java:204)
 ~[wicket-core-9.9.0.jar:9.9.0]
at org.apache.wicket.Component.internalRenderHead(Component.java:2649) 
~[wicket-core-9.9.0.jar:9.9.0] 
 
at 
org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:569)
 [nucleus-grizzly-all.jar:?] at 
org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:549)
 [nucleus-grizzly-all.jar:?] at java.lang.Thread.run(Thread.java:829) [?:?] 

Any idea how to debug this or where it may come from (race condition in our 
code as wicket became faster?)? 
It somehow seems to be a happen when requests coming in at the same time 
with 9.8.0 we got no such errors. 

Best, 

KB 

Re: Rails 7 features

[Korbinian Bachl]

>>
>> I'm a bit short on time currently but what I meant with the fewer
>> redeploys is not anywhere near this livereload jvm. Why? well, I dont think
>> wicket is used that much in "small" projects but in rather larger ones.
>> (I know DHL uses it for the GK-Portal - the solution any smaller customer
>> uses to print labels and do shipments, thats no way a single server setup
>> or trivial by the kind of forms they are having there)
>> Even our own apps require a complete application server with EJB, JNDI
>> etc. - like payara.
>> If I would do a small app that has no need for outer things or is in the
>> microservice area I would go with micronaut or quarkus already.
>> No, what I mean was something that tapestry had included some time ago (
>> https://tapestry.apache.org/class-reloading.html ) - I must admit that I
>> never used it, just read about it some time ago. I didnt think much of this
>> feature to be honest till I got it for free when using micronaut.
>>
> 
> https://github.com/apache/wicket/blob/cd297625ad1df0399ebb5022d65e9c23a1965376/wicket-core/src/main/java/org/apache/wicket/protocol/http/ReloadingWicketFilter.java
> 
> 

Thats new to me! Will try it!
I didnt see any trace of it on the documentation however...?
https://ci.apache.org/projects/wicket/guide/8.x/single.html

Re: Rails 7 features

[Korbinian Bachl]

- Ursprüngliche Mail -
>> >
>> Could you make a quickstart example use case and we could maybe brainstorm
>> about it together, what would actually be the leanest solution?
>>
> 
> http://wicketinaction.com/2014/07/build-resources-with-node.js/
> https://github.com/davidB/livereload-jvm
> Someone did this 7 years ago ...
> 

I'm a bit short on time currently but what I meant with the fewer redeploys is 
not anywhere near this livereload jvm. Why? well, I dont think wicket is used 
that much in "small" projects but in rather larger ones. 
(I know DHL uses it for the GK-Portal - the solution any smaller customer uses 
to print labels and do shipments, thats no way a single server setup or trivial 
by the kind of forms they are having there)
Even our own apps require a complete application server with EJB, JNDI etc. - 
like payara. 
If I would do a small app that has no need for outer things or is in the 
microservice area I would go with micronaut or quarkus already.
No, what I mean was something that tapestry had included some time ago ( 
https://tapestry.apache.org/class-reloading.html ) - I must admit that I never 
used it, just read about it some time ago. I didnt think much of this feature 
to be honest till I got it for free when using micronaut.

Regarding the quickstart: Its hard to demonstrate what can go wrong with 
erratic include positions of javascript when you only have 2 or 3 panels as 
long as you dont let them insert in a loop in random order each time the page 
is generated.
Example: when we started our main brix app we had 10 tiles. Easy to compose 
pages and all ok.. now, years later we have over 60 different tiles that can be 
composed on the page in realtime by an author - and this complexetiy is it that 
can break things fast when you add to the header and cant give it any kind of 
positioning or prioritization.

KB



> 
>>
>> **
>> Martin
>>
>>

Re: Rails 7 features

[Korbinian Bachl]

Hi Martin,

thanks for the details, please see below.

- Ursprüngliche Mail -
> 
> From what I've understood you know just some parts of Wicket and this makes
> you think some things are hard or even imposible.
> Have you considered using Wicket's mounted resource ? it is something
> similar to plain Servlet, but you have access to RequestCycle, Session and
> Application. Check
> http://wicketinaction.com/2011/07/wicket-1-5-mounting-resources/ for some
> examples and the "localized" resources at
> https://examples9x.wicket.apache.org/mappers/.
> You can even go one step further and use WicketStuff RestAnnotations (
> https://github.com/wicketstuff/core/tree/master/wicketstuff-restannotations-parent)
> - an integration between Wicket and JAX-RS.
> This way your React/Angulat/Vue/... frontend could talk to the backend
> without dealing with Wicket.Ajax (and jQuery), which is a convenience for
> talking to Wicket behaviors/components (something you seem to not need
> anyway) for this use case.

I must admit that it may have sounded like that. In reality our main 
application is still based on the wicket brix cms and works very well with it, 
even will push it to wicket 9 in the next half year as we gear up for java 11 
now (sounds crazy as 17 got released yesterday). Also our backend app is pure 
wicket. However, now someone needs some improvement here and there and its most 
often just some additional JS or helpers. If you have to use plain wicket for 
all (even ajax) its often more cumbersome than to just slap a small react app 
into it (you need to think of react beeing able to just control a/ some small 
part(s) of the page - this works nice for things wicket just renders but as 
soon as you try to enhance forms etc. youll end up in hell (or Im to 
incompetent for it)).
What I really find very inspiring by the rails guys is that they not only see 
their "product" as not "the silver bullet" but that they see the need to slap 
together multiple techs (server side rendering like wicket with frontend things 
like react, vue etc. and so they interoperte instead of seperate). 
I did know the resource mounting and the header-items (however with the header 
items I often had nothing but headaches in the past, e.g.: how to prioritize? 
how to level?  how to bundle? etc. etc. - I wont even talk about partial in 
header and partial off header JS inclusion, problem is here: positions of 
different parts matter). 
The RestAnnotations seem to come closer to what I talked about and Im diving 
deeper into them - at least for my next "BrixTile" they might be used as it 
will be some kind of product configuration thing. 
I love wicket - I use it very much and it shelters so much trouble off me as 
long as Im away of JS with it. Oh and "re"-deploys... if you work with 
micronaut (or quarkus even I dont like that one) you'll miss the save-file, 
gets compiled and is live before you even switch to the browser thing


I hope my last mail didn't come off as pure complaining but to just be a voice 
how to make wicket better on the frontend side so its still as alive (or even 
more) in 2030 as it is in 2020 :)


Best,

KB


>
> About positioning things in the  - have you heard of
>  (
> https://ci.apache.org/projects/wicket/guide/8.x/single.html#_header_contributors_positioning)
> ? But this won't be needed too if you make Ajax calls to mounted resources.
> 
> And yes, Wicket is not a silver bullet that you should use for all types of
> applications!
> 
> Whenever you have specific questons about Wicket please ask at
> us...@wicket.apache.org!
> We will try to help you or even recommend you another library/framework
> when Wicket is not the best solution!
> 
> Martin
> 

Re: Rails 7 features

[Korbinian Bachl]

Hi,

I've read the article about rails 7 and the way of its javascript multiple 
times - yet I'm not 100% sure I understood everything - but for me it sounds 
somehow awesome. You'll seem to end up getting a choice:
3 choices to be exact. 

A, use rails as an api backend, meaning you can have your custom JS FE 
framework you like like e.g. Angular, React and so on...
B, Turbo/Stimulus via an import-mapped Hotwire, meaning you seem to be able to 
have encapsulated components that get made production ready on the compile time 
and auto enable high dynamic pages - this will be the default
C, manual and classic kind of JS development and bundling via a bundler you 
choose as rails chose the way to "embrace" JS development from its version 5 on 
(https://weblog.rubyonrails.org/2017/2/23/Rails-5-1-beta1/) - this was the 
"old" default


In any way of thinking about it I really do like the choices that get offered 
here and the way the people behind rails try to adapt to reality. Now, if I 
think about my own development today its very much different to what I did when 
I started over 10 years ago to use wicket. 
Nowadays you are often "forced" to use some kind of frontendtech and wicket - 
at least to me - seems to be not flexible enough if you have to use certain 
webcomponents or techniques. Wickets Ajax is great as long as you stay in that 
"pure" usage mode but when you leave it... it gets kind of unintuitive - at 
least for me.
When I had the need to create a connector piece of software (that also needs an 
webinterface) a year ago I ended up using micronaut as the base. It was awesome 
how fast I could do some REST and JSON APIs. When I then needed a webfrontend I 
fast learned that wicket wouldnt be easy to use if it would be even possible at 
all! 
Why? Well, since its a connector for an SAP system it was necessary to use the 
SAP stuff and thats supplied by webcomponents 
(https://sap.github.io/ui5-webcomponents/) - and if you want to have it working 
dynamically you can use already ready react version (thats maintained as well) 
or do all from scratch by yourself (obviously not really possible). Of course 
wicket is still a webframework but shouldnt it be easy to integrate it with 
todays JS flow? 

I mean if I look at the wicket 8 doc here ( 
https://ci.apache.org/projects/wicket/guide/8.x/single.html#_an_example_of_integration_with_javascript
 ) what I have to do to connect it to my custom JS is far away from beeing 
intuitive or easy IMHO. 
Even if I look at the JavascriptHeaderItem here 
https://ci.apache.org/projects/wicket/apidocs/9.x/org/apache/wicket/markup/head/JavaScriptHeaderItem.html
 then there is not even a way to prioritize it anyway - Nor how to handle it if 
multiple components add some reference to the same JS sources (no, the String 
id doesnt cut it enough). JS Versions? Or this jQuery nightmare? - yep, I had 
this as well leading to disable the jQuery in wicket at all and instead do it 
in the HTML template part as the version mismatch that might occur could breake 
some things... I even faced situations where the ordering of header items 
changed between compiles/ deploys.

What really would be necessary IMHO is that you could have some global JS 
variable in your wicket page where all necessary things like callback url, 
possible functions etc. are propagated in the header before any (!) headerItem 
is even used (so basically on line 1 after ) so that you can simply pick 
up the config needed and dont require that AbstractDefaultAjaxBehavior dance. I 
mean you can embedd a react app easy on the page. The problem with wicket 
occurs the moment you need to "talk" to the page by loading data, writing data 
etc. 

I love wicket for static and simple dynamic webapps and pages - it would be 
cool if it could somehow embrace todays JS worklow anywhow.


my 2c





- Ursprüngliche Mail -
> Von: "Andrea Del Bene" 
> An: "dev" 
> Gesendet: Montag, 13. September 2021 13:15:29
> Betreff: Re: Rails 7 features

> Thanks Martijn! Could point out which features you consider "palatable" for
> Wicket? Sorry but so far I hadn't the chance to read the article in depth.
> 
> On Thu, Sep 9, 2021 at 5:38 PM Martijn Dashorst 
> wrote:
> 
>>
>> https://world.hey.com/dhh/rails-7-will-have-three-great-answers-to-javascript-in-2021-8d68191b
>>
>> Somehow I think that a couple of these features would be a great fit for
>> Wicket.
>>
>> But I don't know if they are easy or neigh impossible to implement.
>>
>> Martijn
>>
> 
> 
> --
> Andrea Del Bene.
> Apache Wicket committer.

Re: Wicket 10 based on jakarta.** APIs ?

[Korbinian Bachl]

I didnt mean to say ES 6 covers all from jQuery, but more that at least ES 6 is 
a common base in the browsers
wicket 10 is the master under 
https://github.com/apache/wicket
?

- Ursprüngliche Mail -
> Von: "Martin Grigorov" 
> An: "dev" 
> Gesendet: Freitag, 3. September 2021 14:12:15
> Betreff: Re: Wicket 10 based on jakarta.** APIs ?

> On Fri, Sep 3, 2021 at 3:08 PM Korbinian Bachl <
> korbinian.ba...@whiskyworld.de> wrote:
> 
>> Oh, ok.
>> Why hold on it?
>> IE is dead and ECMAScript 2015 (ES6) is here in all major browsers?
>> And Wicket 10 is like 2022?
>>
> 
> I guess because no one volunteered to do it.
> Saying that ES6 covers everything that we use from jQuery APIs is a bit
> strong.
> Try to do it!
> 
>

Re: Wicket 10 based on jakarta.** APIs ?

[Korbinian Bachl]

Oh, ok.
Why hold on it? 
IE is dead and ECMAScript 2015 (ES6) is here in all major browsers?
And Wicket 10 is like 2022?



- Ursprüngliche Mail -
> Von: "Martin Grigorov" 
> An: "dev" 
> Gesendet: Freitag, 3. September 2021 12:12:23
> Betreff: Re: Wicket 10 based on jakarta.** APIs ?

> On Fri, Sep 3, 2021, 12:08 Korbinian Bachl 
> wrote:
> 
>> Apologies for hijacking this, but can we assume now the following?
>>
>> wicket 8: java 8 + java apis + servlet 3.1 + jQuery
>> wicket 9: java 11 + java apis  + servlet 3.1 + JQery
>> wicket 10: java 17 + jakarta apis + servlet 5.x + no jQuery
>>
> 
> So far no one is going to remove jQuery
> 
> 
>> ??
>>
>>
>> - Ursprüngliche Mail -
>> > Von: "Andrea Del Bene" 
>> > An: "dev" 
>> > Gesendet: Freitag, 3. September 2021 10:45:03
>> > Betreff: Re: Wicket 10 based on jakarta.** APIs ?
>>
>> > not a big deal imho :-)
>> >
>> > On Fri, Sep 3, 2021 at 9:47 AM Martin Grigorov 
>> wrote:
>> >
>> >> On Fri, Apr 2, 2021 at 2:58 PM Martin Grigorov 
>> >> wrote:
>> >>
>> >> > Hi,
>> >> >
>> >> > Now since we have 9.3.0 released is it time to start thinking/working
>> on
>> >> > Wicket 10 ?
>> >> >
>> >> > Here are few ideas what to break :-)
>> >> >
>> >> > 1) Move to Servlet 5.x, i.e. jakarta.servlet.**
>> >> > 2) Use @Inject + @Named instead of @SpringBean. If everything is
>> covered
>> >> > by @Inject we may deprecate @SpringBean in 9.x
>> >> > 3) Depending on the release date we may even bump Java to 17 (it is
>> going
>> >> > to be released this September and it is going to be LTS). I expect
>> Wicket
>> >> > 10.0.0 to be released in 1-2 years from now, so by this time Java 17
>> >> should
>> >> > be mainstream! :-) I know that this is too brave. Most projects still
>> use
>> >> > Java 8 for some reason.
>> >> >
>> >>
>> >> Spring people announced their plans for supporting Jakarta EE -
>> >>
>> >>
>> https://spring.io/blog/2021/09/02/a-java-17-and-jakarta-ee-9-baseline-for-spring-framework-6
>> >> It is planned for Q4 2022 and it will require Java 17 !
>> >>
>> >> It seems we will be forced to require Java 17 too.
>> >>
>> >>
>> >> > Regards,
>> >> > Martin
>> >> >
>> >>
>> >
>> >
>> > --
>> > Andrea Del Bene.
>> > Apache Wicket committer.

Re: Wicket 10 based on jakarta.** APIs ?

[Korbinian Bachl]

Apologies for hijacking this, but can we assume now the following?

wicket 8: java 8 + java apis + servlet 3.1 + jQuery
wicket 9: java 11 + java apis  + servlet 3.1 + JQery
wicket 10: java 17 + jakarta apis + servlet 5.x + no jQuery

??


- Ursprüngliche Mail -
> Von: "Andrea Del Bene" 
> An: "dev" 
> Gesendet: Freitag, 3. September 2021 10:45:03
> Betreff: Re: Wicket 10 based on jakarta.** APIs ?

> not a big deal imho :-)
> 
> On Fri, Sep 3, 2021 at 9:47 AM Martin Grigorov  wrote:
> 
>> On Fri, Apr 2, 2021 at 2:58 PM Martin Grigorov 
>> wrote:
>>
>> > Hi,
>> >
>> > Now since we have 9.3.0 released is it time to start thinking/working on
>> > Wicket 10 ?
>> >
>> > Here are few ideas what to break :-)
>> >
>> > 1) Move to Servlet 5.x, i.e. jakarta.servlet.**
>> > 2) Use @Inject + @Named instead of @SpringBean. If everything is covered
>> > by @Inject we may deprecate @SpringBean in 9.x
>> > 3) Depending on the release date we may even bump Java to 17 (it is going
>> > to be released this September and it is going to be LTS). I expect Wicket
>> > 10.0.0 to be released in 1-2 years from now, so by this time Java 17
>> should
>> > be mainstream! :-) I know that this is too brave. Most projects still use
>> > Java 8 for some reason.
>> >
>>
>> Spring people announced their plans for supporting Jakarta EE -
>>
>> https://spring.io/blog/2021/09/02/a-java-17-and-jakarta-ee-9-baseline-for-spring-framework-6
>> It is planned for Q4 2022 and it will require Java 17 !
>>
>> It seems we will be forced to require Java 17 too.
>>
>>
>> > Regards,
>> > Martin
>> >
>>
> 
> 
> --
> Andrea Del Bene.
> Apache Wicket committer.

Re: Wicket 10 ideas

[Korbinian Bachl]

Hi,

we dont use queueing but we use enclosures in quite a few places. Getting rid 
of it would mean we have to switch to markup containers holding the content and 
add additonal layer of complexity and boilerplatecode for us.

Beside that: can wicket 10 finally get rid of jQuery? Since IE is now 
definitely dead I dont see any reason why this is still needed

Best,
KB


- Ursprüngliche Mail -
> Von: "Ernesto Reinaldo Barreiro" 
> An: dev@wicket.apache.org
> Gesendet: Freitag, 23. April 2021 12:04:34
> Betreff: Re: Wicket 10 ideas

> Hi,
> 
> On Fri, Apr 23, 2021 at 11:58 AM Sven Meier  wrote:
> 
>> x) remove/rework enclosures and component queueing.
>>
> 
> It would be interesting to know how many people really use queuing
> 
> 
>>
>> Have fun
>> Sven
>>
>>
>> On 02.04.21 13:58, Martin Grigorov wrote:
>> > Hi,
>> >
>> > Now since we have 9.3.0 released is it time to start thinking/working on
>> > Wicket 10 ?
>> >
>> > Here are few ideas what to break :-)
>> >
>> > 1) Move to Servlet 5.x, i.e. jakarta.servlet.**
>> > 2) Use @Inject + @Named instead of @SpringBean. If everything is covered
>> > by @Inject we may deprecate @SpringBean in 9.x
>> > 3) Depending on the release date we may even bump Java to 17 (it is going
>> > to be released this September and it is going to be LTS). I expect Wicket
>> > 10.0.0 to be released in 1-2 years from now, so by this time Java 17
>> should
>> > be mainstream! :-) I know that this is too brave. Most projects still use
>> > Java 8 for some reason.
>> >
>> > Regards,
>> > Martin
>> >
>>
> 
> 
> --
> Regards - Ernesto Reinaldo Barreiro

Re: Wicket site with adblocker @ MS Edge

[Korbinian Bachl]

Option 3:
1) wait for MS to apply the switch to the chromium engine (ditching the current 
edge engine completely - see: 
https://www.computerworld.com/article/3325333/web-browsers/with-move-to-rebuild-edge-atop-googles-chromium-microsoft-raises-white-flag-in-browser-war.html
 )
2) relax while doing 1)

IMHO: this is an edge case affecting nearly nobody - since nearly nobody uses 
edge anyway. It was the worst browser from beginning since MS never put any 
real work in it and if anyone has a problem he can switch to FF or Chrome or 
maybe even the 1 user in 10 000 disable his plugins for the wicket page? Better 
put the time needed into work for wicket; In the end, next week a user of lynx 
will come and complain the the wicket page isnt as good as expected 

my 2c;


PS: I dont know any (!) developer using solely 1 browser anyway - especially 
since the developer tools in either IE or edge are such useless... Everytime I 
needed to fix a major IE or EDGE issue in the past it was horrible compared to 
such a task in FF or Chrome

- Ursprüngliche Mail -
> Von: "Maxim Solodovnik" gmail.com>
> An: dev@wicket.apache.org
> Gesendet: Freitag, 25. Januar 2019 04:12:33
> Betreff: Re: Wicket site with adblocker @ MS Edge

> Hello @Devs,
> 
> I was able to reproduce the issue, and I believe it can be fixed if we will
> Option 0:
> 1) provide PNG instead of SVG
> 
> Option 1:
> 1) check if embedded web font exist using JS
> 2) if not will insert PNG image of SVG currently being used
> 
> Option 2:
> 1) modify SVG to have circle and crown only
> 2) move text and web-font outside SVN to be regular DIV elements
> 
> WDYT?
> 
> On Tue, 22 Jan 2019 at 21:29, Vit Rozkovec  wrote:
> 
>> So no extra configuration whatsoever.
>>
>> úterý 22. ledna 2019 Vit Rozkovec  napsal(a):
>> > He had uBlock Original 1.15, configuration status unknown.
>> >
>> > Wouldn't simple svg fix that?
>> >
>> >
>> > úterý 22. ledna 2019 Maxim Solodovnik gmail.com> napsal(a):
>> >> @Vit, maybe you can share which AdBlocker have you used and how it was
>> >> configured?
>> >>
>> >> On Tue, 22 Jan 2019 at 18:56, Martijn Dashorst <
>> martijn.dasho...@gmail.com>
>> >> wrote:
>> >>
>> >>> My guess is that if a web font from same origin is blocked, JavaScript
>> >>> will fail as well.
>> >>>
>> >>> Martijn
>> >>>
>> >>> On Tue, Jan 22, 2019 at 12:25 PM Maxim Solodovnik <
>> solomax...@gmail.com>
>> >>> wrote:
>> >>> >
>> >>> > Maybe something like this
>> >>> >
>> >>> >
>> >>>
>>
>> https://stackoverflow.com/questions/1271477/changing-body-font-size-based-on-font-family-with-jquery
>> >>> >
>> >>> > can be used?
>> >>> >
>> >>> > On Tue, 22 Jan 2019 at 17:27, Andrea Del Bene delb...@gmail.com>
>> >>> wrote:
>> >>> >
>> >>> > > I've checked uBlock with Firefox and AdBlocker with Chrome, both
>> with
>> >>> > > default configs, and I see no problem. Obviously IE/Edge always
>> >>> behaves in
>> >>> > > its own, peculiar way :-).
>> >>> > >
>> >>> > > On Tue, Jan 22, 2019 at 11:12 AM Martijn Dashorst <
>> >>> > > martijn.dasho...@gmail.com> wrote:
>> >>> > >
>> >>> > > > Well, we did everything well: the fonts are hosted at Apache, not
>> >>> > > > loaded from external site that tracks their usage (looking at you
>> >>> > > > fonts.google.com), the SVG even embeds the font file in a data
>> uri.
>> >>> If
>> >>> > > > the adblocker then still blocks the font, what can we do?
>> Introduce a
>> >>> > > > 4MB PNG file? Or should the adblocker at least honor same domain
>> >>> > > > requests for resources and not block data URI's?
>> >>> > > >
>> >>> > > > The font face used for the logo is narrow and there are no
>> web-safe
>> >>> > > > fonts that render correctly in this instance: I've tried with
>> Arial
>> >>> > > > Narrow and sans-serif as a fallback: the logo still looks badly
>> >>> > > > broken.
>> >>> > > >
>> >>> > > > AFAIK we can't detect whether someone uses an adblocker that
>> >>> > > > specifically blocks web fonts, serve them the 8GB binary images,
>> and
>> >>> > > > serve the rest of the world the 80kb SVG file.
>> >>> > > >
>> >>> > > > I understand the need for an adblocker, but when you use one
>> >>> (wrongly)
>> >>> > > > you are responsible for when shit breaks.
>> >>> > > >
>> >>> > > > Martijn
>> >>> > > >
>> >>> > > >
>> >>> > > > On Tue, Jan 22, 2019 at 9:46 AM Vit Rozkovec <
>> vit.rozko...@gmail.com
>> >>> >
>> >>> > > > wrote:
>> >>> > > > >
>> >>> > > > > HI,
>> >>> > > > >
>> >>> > > > > please see this screenshot:
>> >>> > > > > https://screenshots.firefox.com/v4PQv7WIKAv1TiUA/null
>> >>> > > > >
>> >>> > > > > This is how is the site visible when you browse it with adblock
>> >>> that
>> >>> > > > > blocks also some fonts.
>> >>> > > > >
>> >>> > > > > Discovered when one my colleague who is learning Wicket and
>> uses
>> >>> > > Windows
>> >>> > > > > wanted to show it to someone else, not a very good first
>> >>> impression :)
>> >>> > > > >
>> >>> > > > > I think it would be good to have a default that 

wicket 8 migration guide errors

[Korbinian Bachl]

Hi,

under https://cwiki.apache.org/confluence/display/WICKET/Migration+to+Wicket+8.0

I get various errors in the document like 

"Unable to locate Jira server for this macro. It may be due to Application Link 
configuration."

and 

"Fehler beim Ausführen des Makros 'jira'

Unable to locate Jira server for this macro. It may be due to Application Link 
configuration."

see under Removals and Environment headlines

Best,
KB

Re: [VOTE] Release Apache Wicket 8.0.0

[Korbinian Bachl]

+1


- Ursprüngliche Mail -
> Von: "Emond Papegaaij" 
> An: dev@wicket.apache.org
> Gesendet: Freitag, 18. Mai 2018 11:58:43
> Betreff: Re: [VOTE] Release Apache Wicket 8.0.0

> +1
> 
> Tested our application with the complete test suite
> Checked signatures and hashes
> 
> I did notice some misplaced managed dependencies in the root pom for projects
> that no longer exist, but that should not stop the release.
> 
> Best regards,
> Emond
> 
> On donderdag 17 mei 2018 22:30:20 CEST Pedro Santos wrote:
>> +1
>> 
>> cheers
>> 
>> Pedro Santos
>> 
>> On Thu, May 17, 2018 at 4:33 PM, Andrea Del Bene 
>> 
>> wrote:
>> > +1 tested my main app
>> > 
>> > On Thu, May 17, 2018, 4:46 AM Maxim Solodovnik 
>> > 
>> > wrote:
>> > > +1
>> > > 
>> > > Tested
>> > > 1) signatures
>> > > 2) build from sources
>> > > 3) our main application
>> > > 
>> > > On Thu, May 17, 2018 at 3:39 AM, Tobias Soloschenko <
>> > > 
>> > > tobiassolosche...@googlemail.com> wrote:
>> > > > +1
>> > > > 
>> > > > kind regards
>> > > > 
>> > > > Tobias
>> > > > 
>> > > > > Am 16.05.2018 um 22:01 schrieb Andrea Del Bene > > > > > 
>> > > > > 
>> > > > > This is a vote to release Apache Wicket 8.0.0
>> > > > > 
>> > > > > Please download the source distributions found in our staging area
>> > > > > linked below.
>> > > > > 
>> > > > > I have included the signatures for both the source archives. This
>> > 
>> > vote
>> > 
>> > > > > lasts for 72 hours minimum.
>> > > > > 
>> > > > > [ ] Yes, release Apache Wicket 8.0.0
>> > > > > [ ] No, don't release Apache Wicket 8.0.0, because ...
>> > > > > 
>> > > > > Distributions, changelog, keys and signatures can be found at:
>> > > > >     https://dist.apache.org/repos/dist/dev/wicket/8.0.0
>> > > > > 
>> > > > > Staging repository:
>> > > https://repository.apache.org/content/repositories/orgapachewicket-1110
>> > > 
>> > > > > The binaries are available in the above link, as are a staging
>> > > > > repository for Maven. Typically the vote is on the source, but
>> > > > > should
>> > > > > you find a problem with one of the binaries, please let me know, I
>> > 
>> > can
>> > 
>> > > > > re-roll them some way or the other.
>> > > > > 
>> > > > > Staging git repository data:
>> > > > >     Repository:  g...@github.com:bitstorm/wicket.git
>> > > > >     Branch:      build/wicket-8.0.0
>> > > > >     Release tag: rel/wicket-8.0.0
>> > > 
>> > > 
>> > > 
>> > > > >     The signatures for the source release artefacts:
>> > > > > Signature for apache-wicket-8.0.0.zip:
>> > > > >     -BEGIN PGP SIGNATURE-
>> > > > > 
>> > > > > iQIzBAABCgAdFiEE0a6YZHC1pJw+aieyh48B+qjTVuEFAlr8jGsACgkQh48B+qjT
>> > > > > VuHk1xAAnJ2iPogwXIc1ieWjPatVvWGB258zYmrOtuhgwil5ThWF/Fx3PrNfhUVQ
>> > > > > l1oiFSvRftuJm7YKIKZyg2sMQjosVx1o8ELOHxyvZWlyycycfjdggQCkEGIdP3Ot
>> > > > > oNHu2aIqbO1fwFPiXzQUPP5cYYw7/5AXcBYOanasjYbtPDtmcrQlKo6NJZOyxjF+
>> > > > > Oi2/J+yC0RGa0NaYGsrWvi0ZgYNbyA2XinnpWm0FOiyCtNv86/tWPUoJUNnx2t2k
>> > > > > nEwgrcmpJAer3o85xFhO/KXG/Ibd9Fa62GcFi9H13lD/A4XoZ169xVaeujMTSCVR
>> > > > > JIcCFmUuibnCd75MLqoWHwu8cGkxMQ5xgBvgp2AUAflki/iv2Uw4enF0+GV/1mCq
>> > > > > Age/HHiTtBif7vGQ6yHCak7woLnCucMgVHulT3HIXgLbDu5PIpVGbJtJvB0PgOiM
>> > > > > vOthGtisMrwQujj3m432ONG0aAAHEWvfmIdyXVZhRa3vwQ8JxwM6HeNYdpsbVezW
>> > > > > gTinuMktBnmZzJeTEqXYxnC5AOfARAsx/GY45aSaSLZobloau2b+CpaHP3MVkDr6
>> > > > > 44BjpoCffpDF90iFh6UEfwF3zGR8CkWLWxU4LHaQDXqWQ5dLCoQ/Dj7sJYE5ylgm
>> > > > > QujE4mkLFcFPRO+wsKK503lfYOjz0Ud9wf43Q2m/DNiRqkbEeMM=
>> > > > > =b1+3
>> > > > > -END PGP SIGNATURE-
>> > > > > 
>> > > > > Signature for apache-wicket-8.0.0.tar.gz:
>> > > > >     -BEGIN PGP SIGNATURE-
>> > > > > 
>> > > > > iQIzBAABCgAdFiEE0a6YZHC1pJw+aieyh48B+qjTVuEFAlr8jGsACgkQh48B+qjT
>> > > > > VuHbxQ//UpfnaQUxkEUzUp04lZ7nMrh/RblfvhQOHRD+EXo/2CgbyMXSkzZV6oLd
>> > > > > APF6QTEoSJnxvuH7x1wlTUeleJ3VQw3+3pPh/6AcsoQ9KnN///rGtIL8YDDrP6FD
>> > > > > L5MPw8l9g2z73dioVv/OCRJD1Q6DjG/uiB0yYD+BpAWAvsZX5L22tBKl0Bsho3IV
>> > > > > nc/xPI91NPXkv0Jouxfa6VMbjvCNBYRFoYQP2OSmoVOmyflRAeINysSmdQoyaLXD
>> > > > > Q22CTRQCxmANb/5r3jN7cmCQIOMTDMQqmgvJKqbOYwgi0SPPYBCRBy07394uWXNu
>> > > > > 3yo6yPu0dtdLH33pbk7yBpS6aY3JAs9RuHuJ++a5N10veEqbhh0sNHy7tlRkGhWa
>> > > > > sHNSY0ez3wqnL2rYEI6FALWGGyXEAgYr1yqkZiLLxm1YLW08PQO46Zv5ybf5vtky
>> > > > > MLYK+zYNKK8MQiMWsU6QjmVrWNl1/upfAyJSCLskFMpZ5hPwBn+3jXc0kFjT26MB
>> > > > > WCcbaJhDWgo0XMIyZPO54ELeKzz4FTuwQtViIkLUC4KLX4Abxza5DPAS2KPOBviY
>> > > > > FBm/LdFTte1WN/YU0qKwEvYuRqt7mEXyUbQuVT27R6kRfWoXF/dTJCrjbLv5g8ze
>> > > > > cqwRxMPaZgKMSKpBlOnwWS5l6q1jN8FSFLdunm9Hdnn06aQbrdI=
>> > > > > =OAcW
>> > > > > -END PGP SIGNATURE-
>> > > 
>> > > 
>> > > 
>> > > > >     CHANGELOG for 8.0.0:
>> > > > > ** Bug
>> > > > > 
>> > > > >     * [WICKET-6473] - Double slash break 404page

Re: [DISCUSSION] Java future and Wicket

[Korbinian Bachl]

But wasn't that the hole point of the renaming change from wicket 1.4 / 1.5 to 
wicket 6, wicket 7, wicket 8?

I myself dont give anything about version numbers anyway, just curious 

- Ursprüngliche Mail -
> Von: "Martin Grigorov" <mgrigo...@apache.org>
> An: dev@wicket.apache.org
> Gesendet: Montag, 16. April 2018 16:37:04
> Betreff: Re: [DISCUSSION] Java future and Wicket

> I think we should not relate Wicket version to anything.
> Wicket 9 will be released when there is enough new features. And the team
> decides when enough is enough.
> It should be build with the latest LTS JDK whatever it is at the moment.
> The version of EE4J / Servlet specs are also not relevant to Wicket's
> version.
> 
> On Mon, Apr 16, 2018 at 4:03 PM, Korbinian Bachl <
> korbinian.ba...@whiskyworld.de> wrote:
> 
>> Maybe stupid question but: why not align with Java EE?
>>
>> -> Java EE8 relies on JDK8, not JDK 9 - and wicket 8 relies on JDK 8
>> -> Java EE9 (or whatever naming scheme comes) might rely on Java 11 lts ->
>> so align wicket 9 (or whatever EE naming scheme) with JDK 11?
>>
>> In the end the Java version itself is not so imprtant for Wicket as IMHO
>> the EE is as its all in EE space in view to the web-server-side...
>> (wicket needs servlet and thats part of EE)
>>
>>
>>
>>
>> - Ursprüngliche Mail -
>> > Von: "Martijn Dashorst" <martijn.dasho...@gmail.com>
>> > An: dev@wicket.apache.org
>> > Gesendet: Montag, 16. April 2018 11:52:55
>> > Betreff: [DISCUSSION] Java future and Wicket
>>
>> > All,
>> >
>> > With the new release schedule of Java where they will (have)
>> > release(d) Java 9, 10 and 11 in one year, what will we do with
>> > Wicket's dependency on Java?
>> >
>> > Will we move with the Long Term Support versions? AFAIK this will
>> > require us to upgrade every year to a new major version.
>> >
>> > Or will we stay with LTS-- as our major supported Java version?
>> >
>> > If so, how do we work with deprecated technologies that we (or our
>> > dependencies) use when they get removed, or Wicket plain stops working
>> > on Java 10 (or Java 11), or stops building on one such version?
>> >
>> > In the long run, I don't think it is possible for us to align Wicket
>> > versions with major Java versions as we could in the previous years:
>> >
>> > - wicket 1.5 -> Java 5 (actually Wicket 1.4, but who's counting)
>> > - wicket 6 -> Java 6
>> > - wicket 7 -> Java 7
>> > - wicket 8 -> Java 8
>> >
>> > would the next major version of Wicket be 11?
>> >
>> > - wicket 11 -> Java 11?
>> >
>> > Martijn

Re: [DISCUSSION] Wicket 8 Release

[Korbinian Bachl]

+1 to release



- Ursprüngliche Mail -
> Von: "Maxim Solodovnik" 
> An: dev@wicket.apache.org
> Gesendet: Dienstag, 3. April 2018 16:36:35
> Betreff: [DISCUSSION] Wicket 8 Release

> Hello All,
> 
> I believe it is time to release :)
> Do we have any blockers?
> 
> Some non-technical blockers should be already resolved :)))
> 
> --
> WBR
> Maxim aka solomax

Re: [DISCUSSION] WICKET-6544 mobile browser detection

[Korbinian Bachl]

- Ursprüngliche Mail -
>> even in 2009 it was considered bad: https://www.sitepoint.com/why-
>> browser-sniffing-stinks/
>> and in case that is not enough, read what the guy that invented modernizr
>> has to say:
>> http://farukat.es/journal/2011/02/499-lest-we-forget-or-
>> how-i-learned-whats-so-bad-about-browser-sniffing/
>>
>>
> I do not trust anyone who says "don't do it this way" but doesn't say how
> to do it!
> 
> There are several of "if (isBrowserX()) {...} else {...}" in Wicket JS code
> and they served well for the last decade.
> Since there are several other *Java* libraries for user agent detection
> this means that someone still finds them useful despite what other people
> claim.

unreliable things wont get reliably by pointing into the past and then telling 
that your fater did it the same way

nowadays you would use feature detection, see: 

https://developer.mozilla.org/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/Feature_detection

> 
> 
>> btw:
>> https://github.com/HaraldWalker/user-agent-utils -> this is EOL, guess
>> why...
>> https://github.com/pieroxy/java-user-agent-detection/releases -> last
>> release from september 2017...
>>
>>
> Sep 2017 is like yesterday

(all only MAJOR releases!)

28. September 2017 - Firefox 56 
14. November 2017 - Firefox 57 Quantum
23. Januar 2018 - Firefox 58
13. März 2018 - Firefox 59

2017-09-05 - Chrome 61.0.3163
2017-10-17 - Chrome 62.0.3202
2017-12-05 - Chrome 63.0.3239
2018-01-23 - Chrome 64.0.3282
2018-03-06 - Chrome 65.0.3325

and this is just 2 desktop ones! I dont want to talk about the loads of updates 
my android device got in that time (firefox mobile, chrome and samsung 
internet!) - oh, and btw: they still lie about the user agent all time dont 
get me wrong, but sep 17 is freaking old in case you need to reliably detect 
the browser!

Re: [VOTE] Release Apache Wicket 8.0.0-M9

[Korbinian Bachl]

in short: since IE 11 and chrome as well as FF the browsers dont fire the 
DOMContentLoaded of scripts the way one would expect. This happens as the 
browsers branch multiple threads that each thread put together execution groups 
of orders leading to inline-JS getting executed and events on these fired 
without the knowledge of other JS resources as long as these are defered and / 
or / asnyc'd

Even worse, an app that may work well in local mode may break in production as 
network timing as well as client CPU count (influences thread) and speed of CPU 
and or GPU (yep... ) may change the timings the event DOMContentLoaded  gets 
fired;

even JQuery guys are plagued by this and have no real solution to it now IMHO 
https://github.com/jquery/jquery/issues/3271

I think we can get a real working one for wicket but had no time yet to try it 
out; Idea is to create the wicket object in the head at first inline script 
before any JS resources (defered or not) so that the page itself cant break 
because of this


- Ursprüngliche Mail -
> Von: "Andrea Del Bene" <an.delb...@gmail.com>
> An: dev@wicket.apache.org
> Gesendet: Donnerstag, 15. Februar 2018 16:48:18
> Betreff: Re: [VOTE] Release Apache Wicket 8.0.0-M9

> Hi,
> 
> I need your help. what's exactly the caveat about  WICKET-6498? It uses
> javascript events that might not be supported buy browser?
> 
> On Sun, Feb 11, 2018 at 6:16 PM, Korbinian Bachl <
> korbinian.ba...@whiskyworld.de> wrote:
> 
>> +1 to release for M9
>>
>> IMHO a warning should be added with regards to WICKET-6498 as it is not
>> yet working in a reliable way but may break depending on client specifics;
>>
>> - Ursprüngliche Mail -
>> > Von: "Andrea Del Bene" <an.delb...@gmail.com>
>> > An: dev@wicket.apache.org
>> > Gesendet: Sonntag, 11. Februar 2018 17:34:08
>> > Betreff: [VOTE] Release Apache Wicket 8.0.0-M9
>>
>> > This is a vote to release Apache Wicket 8.0.0-M9
>> >
>> > Please download the source distributions found in our staging area
>> > linked below.
>> >
>> > I have included the signatures for both the source archives. This vote
>> > lasts for 72 hours minimum.
>> >
>> > [ ] Yes, release Apache Wicket 8.0.0-M9
>> > [ ] No, don't release Apache Wicket 8.0.0-M9, because ...
>> >
>> > Distributions, changelog, keys and signatures can be found at:
>> >
>> > https://dist.apache.org/repos/dist/dev/wicket/8.0.0-M9
>> >
>> > Staging repository:
>> >
>> > https://repository.apache.org/content/repositories/orgapachewicket-1105/
>> >
>> > The binaries are available in the above link, as are a staging
>> > repository for Maven. Typically the vote is on the source, but should
>> > you find a problem with one of the binaries, please let me know, I can
>> > re-roll them some way or the other.
>> >
>> > Staging git repository data:
>> >
>> > Repository:  g...@github.com:bitstorm/wicket.git
>> > Branch:  build/wicket-8.0.0-M9
>> > Release tag: rel/wicket-8.0.0-M9
>> >
>> >
>> > 
>> >
>> > The signatures for the source release artefacts:
>> >
>> >
>> > Signature for apache-wicket-8.0.0-M9.zip:
>> >
>> > -BEGIN PGP SIGNATURE-
>> > Version: GnuPG v1
>> >
>> > iQIcBAABAgAGBQJagFiiAAoJEIePAfqo01bhPxsP/jgrMjf/3IVHWSOftoHEYf+j
>> > Wtb8gvB0Y3sY8L6syj5GQCuhceaovbq3NCnAz0qrn/tLRuUnybyj8GfyMrQv4wNP
>> > rDj7zPRqhsldgbSTsjDP98b0V99F5ct68HsxOr3LzxNijFNFRxIDnF+73QZNjUcA
>> > YL4xuxP80WvMb1mmwASg+l9MxhEWpeYWoyOBHNWFmjgI/4r3ineq2YSjAq3MZKOC
>> > Vu4CqYS+ajEFMqduHU4aa9j4Lj4X81by34c9xCKERaioI7kFhoZzhws6ufoA/wNo
>> > EPBPBft9oG72rUfX9VwyZxHMBmU50eKmEtFeCtWXqu5v8Js2rVTxmw4EGKENj3+8
>> > Kiup7+zXu9t07mvoS4mCJ8fcl7P+g24e02pdqHDBea/a7zAKUdrIe6MCMJ2Qlw0g
>> > E/xlDJ4utPcU7E88IQiCLpmarN3uBZKnivzm3Uir5U0dJtffu4IacABg5Svp3DAl
>> > TcUOmM9QxKYjD8Ey6uORoGTm3gZmx4FcnNjSw0ch27fyNUpYVfEyU88KH9vz2dQP
>> > Tcs9LxRpII4pBGXu0nK5zWZfXBgqxYfUUrIroCrzVWub+wqEw8pXo2K9GdrUYpcg
>> > K12TIpW3X43zNG7L6lTJtFe2yffVLdyS1DDoqU3QI4gHe/vdIC3atd4BP0Aeauj1
>> > jIvOQJKU+bwlubLLneTg
>> > =MOtP
>> > -END PGP SIGNATURE-
>> >
>> > Signature for apache-wicket-8.0.0-M9.tar.gz:
>> >
>> > -BEGIN PGP SIGNATURE-
>> > Version: GnuPG v1
>> >
>> > iQIcBAABAgAGBQJagFihAAoJEIePAfqo01bheU8QAIkUJK3zjjVeAR

Re: [VOTE] Release Apache Wicket 8.0.0-M9

[Korbinian Bachl]

thanks a lot Sven!

- Ursprüngliche Mail -
> Von: "Sven Meier" <s...@meiers.net>
> An: dev@wicket.apache.org
> Gesendet: Sonntag, 11. Februar 2018 21:24:53
> Betreff: Re: [VOTE] Release Apache Wicket 8.0.0-M9

> Hi,
> 
> JavaScriptDeferHeaderResponse is an *alternative* to
> JavaScriptFilteredIntoFooterHeaderResponse, it doesn't break anything -
> but even if you wanted to, you could use both simultaneously.
> 
> Regarding WICKET-6498's experimental status - I've added the following
> to the JavaDoc:
> 
>  * Note: This solution depends on the execution order of JavaScript in
> the browser:
>  * The 'DOMContentLoaded' event has to be fired after all
> deferred JavaScript
>  * resources have been loaded. This doesn't seem to be the case in all
> browsers, thus
>  * this class should be considered experimental.
> 
> IMHO this is warning enough.
> 
> Sven
> 
> 
> Am 11.02.2018 um 20:03 schrieb Andrea Del Bene:
>> Good point. We should also underline that WICKET-6498 breaks custom
>> response decoration that might be used to place JavaScript inside body
>> tag.
>>
>>
>> On 11/02/2018 18:16, Korbinian Bachl wrote:
>>> +1 to release for M9
>>>
>>> IMHO a warning should be added with regards to WICKET-6498 as it is
>>> not yet working in a reliable way but may break depending on client
>>> specifics;
>>>
>>> - Ursprüngliche Mail -
>>>> Von: "Andrea Del Bene" <an.delb...@gmail.com>
>>>> An: dev@wicket.apache.org
>>>> Gesendet: Sonntag, 11. Februar 2018 17:34:08
>>>> Betreff: [VOTE] Release Apache Wicket 8.0.0-M9
>>>> This is a vote to release Apache Wicket 8.0.0-M9
>>>>
>>>> Please download the source distributions found in our staging area
>>>> linked below.
>>>>
>>>> I have included the signatures for both the source archives. This vote
>>>> lasts for 72 hours minimum.
>>>>
>>>> [ ] Yes, release Apache Wicket 8.0.0-M9
>>>> [ ] No, don't release Apache Wicket 8.0.0-M9, because ...
>>>>
>>>> Distributions, changelog, keys and signatures can be found at:
>>>>
>>>>  https://dist.apache.org/repos/dist/dev/wicket/8.0.0-M9
>>>>
>>>> Staging repository:
>>>>
>>>> https://repository.apache.org/content/repositories/orgapachewicket-1105/
>>>>
>>>>
>>>> The binaries are available in the above link, as are a staging
>>>> repository for Maven. Typically the vote is on the source, but should
>>>> you find a problem with one of the binaries, please let me know, I can
>>>> re-roll them some way or the other.
>>>>
>>>> Staging git repository data:
>>>>
>>>>  Repository:  g...@github.com:bitstorm/wicket.git
>>>>  Branch:  build/wicket-8.0.0-M9
>>>>  Release tag: rel/wicket-8.0.0-M9
>>>>
>>>>
>>>> 
>>>>
>>>>
>>>>  The signatures for the source release artefacts:
>>>>
>>>>
>>>> Signature for apache-wicket-8.0.0-M9.zip:
>>>>
>>>>  -BEGIN PGP SIGNATURE-
>>>> Version: GnuPG v1
>>>>
>>>> iQIcBAABAgAGBQJagFiiAAoJEIePAfqo01bhPxsP/jgrMjf/3IVHWSOftoHEYf+j
>>>> Wtb8gvB0Y3sY8L6syj5GQCuhceaovbq3NCnAz0qrn/tLRuUnybyj8GfyMrQv4wNP
>>>> rDj7zPRqhsldgbSTsjDP98b0V99F5ct68HsxOr3LzxNijFNFRxIDnF+73QZNjUcA
>>>> YL4xuxP80WvMb1mmwASg+l9MxhEWpeYWoyOBHNWFmjgI/4r3ineq2YSjAq3MZKOC
>>>> Vu4CqYS+ajEFMqduHU4aa9j4Lj4X81by34c9xCKERaioI7kFhoZzhws6ufoA/wNo
>>>> EPBPBft9oG72rUfX9VwyZxHMBmU50eKmEtFeCtWXqu5v8Js2rVTxmw4EGKENj3+8
>>>> Kiup7+zXu9t07mvoS4mCJ8fcl7P+g24e02pdqHDBea/a7zAKUdrIe6MCMJ2Qlw0g
>>>> E/xlDJ4utPcU7E88IQiCLpmarN3uBZKnivzm3Uir5U0dJtffu4IacABg5Svp3DAl
>>>> TcUOmM9QxKYjD8Ey6uORoGTm3gZmx4FcnNjSw0ch27fyNUpYVfEyU88KH9vz2dQP
>>>> Tcs9LxRpII4pBGXu0nK5zWZfXBgqxYfUUrIroCrzVWub+wqEw8pXo2K9GdrUYpcg
>>>> K12TIpW3X43zNG7L6lTJtFe2yffVLdyS1DDoqU3QI4gHe/vdIC3atd4BP0Aeauj1
>>>> jIvOQJKU+bwlubLLneTg
>>>> =MOtP
>>>> -END PGP SIGNATURE-
>>>>
>>>> Signature for apache-wicket-8.0.0-M9.tar.gz:
>>>>
>>>>  -BEGIN PGP SIGNATURE-
>>>> Version: GnuPG v1
>>>>
>>>> iQIcBAABAgAGBQJagFihAAoJEIePAfqo01bheU8QAIkUJK3zjjVeARkA

Re: [VOTE] Release Apache Wicket 8.0.0-M9

[Korbinian Bachl]

+1 to release for M9

IMHO a warning should be added with regards to WICKET-6498 as it is not yet 
working in a reliable way but may break depending on client specifics;

- Ursprüngliche Mail -
> Von: "Andrea Del Bene" 
> An: dev@wicket.apache.org
> Gesendet: Sonntag, 11. Februar 2018 17:34:08
> Betreff: [VOTE] Release Apache Wicket 8.0.0-M9

> This is a vote to release Apache Wicket 8.0.0-M9
> 
> Please download the source distributions found in our staging area
> linked below.
> 
> I have included the signatures for both the source archives. This vote
> lasts for 72 hours minimum.
> 
> [ ] Yes, release Apache Wicket 8.0.0-M9
> [ ] No, don't release Apache Wicket 8.0.0-M9, because ...
> 
> Distributions, changelog, keys and signatures can be found at:
> 
>     https://dist.apache.org/repos/dist/dev/wicket/8.0.0-M9
> 
> Staging repository:
> 
> https://repository.apache.org/content/repositories/orgapachewicket-1105/
> 
> The binaries are available in the above link, as are a staging
> repository for Maven. Typically the vote is on the source, but should
> you find a problem with one of the binaries, please let me know, I can
> re-roll them some way or the other.
> 
> Staging git repository data:
> 
>     Repository:  g...@github.com:bitstorm/wicket.git
>     Branch:  build/wicket-8.0.0-M9
>     Release tag: rel/wicket-8.0.0-M9
> 
> 
> 
> 
>     The signatures for the source release artefacts:
> 
> 
> Signature for apache-wicket-8.0.0-M9.zip:
> 
>     -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
> 
> iQIcBAABAgAGBQJagFiiAAoJEIePAfqo01bhPxsP/jgrMjf/3IVHWSOftoHEYf+j
> Wtb8gvB0Y3sY8L6syj5GQCuhceaovbq3NCnAz0qrn/tLRuUnybyj8GfyMrQv4wNP
> rDj7zPRqhsldgbSTsjDP98b0V99F5ct68HsxOr3LzxNijFNFRxIDnF+73QZNjUcA
> YL4xuxP80WvMb1mmwASg+l9MxhEWpeYWoyOBHNWFmjgI/4r3ineq2YSjAq3MZKOC
> Vu4CqYS+ajEFMqduHU4aa9j4Lj4X81by34c9xCKERaioI7kFhoZzhws6ufoA/wNo
> EPBPBft9oG72rUfX9VwyZxHMBmU50eKmEtFeCtWXqu5v8Js2rVTxmw4EGKENj3+8
> Kiup7+zXu9t07mvoS4mCJ8fcl7P+g24e02pdqHDBea/a7zAKUdrIe6MCMJ2Qlw0g
> E/xlDJ4utPcU7E88IQiCLpmarN3uBZKnivzm3Uir5U0dJtffu4IacABg5Svp3DAl
> TcUOmM9QxKYjD8Ey6uORoGTm3gZmx4FcnNjSw0ch27fyNUpYVfEyU88KH9vz2dQP
> Tcs9LxRpII4pBGXu0nK5zWZfXBgqxYfUUrIroCrzVWub+wqEw8pXo2K9GdrUYpcg
> K12TIpW3X43zNG7L6lTJtFe2yffVLdyS1DDoqU3QI4gHe/vdIC3atd4BP0Aeauj1
> jIvOQJKU+bwlubLLneTg
> =MOtP
> -END PGP SIGNATURE-
> 
> Signature for apache-wicket-8.0.0-M9.tar.gz:
> 
>     -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
> 
> iQIcBAABAgAGBQJagFihAAoJEIePAfqo01bheU8QAIkUJK3zjjVeARkAbN3Zi1hE
> b5qnaSiXkuxZyTfVzDS4Ui7OZwIOY1RJ1YlJ4fZwio+BJhpxnCiPjPLRC1VNwA4q
> oMBsOfwePU92kJYQERfVfJgNkk1ixyh52k3qsoS4EIdKT+bOW52hT8zaXRNazhG3
> nwyDTe00c/ibj5KM68L7R4LXef6tbnZAjegKBDNUsvWQltwE2xc1lVapnNoqtOAM
> B26gWh5G8QDQxjWJESk9ik+Vyyg9We8lABV5+Hkqrugv3yECiD9ObcYE29bE/OHN
> hfgzo5EX+umXzTkoHltQ0ZxAxPiWWquH3tjsy1/z/8r3BT4YBZs+PIoOCSPem6kK
> aUoJiBEZ55WsBVd5NdYY7PiSwZ2KWsuE1XmqADY+USuhytPln04YNK9srdVESnCL
> sBxGP0kgHKrD92O1aTLpzan3VhD1O8KzjH/8MMEWJxevQbW/gorlAjh7+iCVcH7g
> YurqMjtq91YFFlZwU5YlczfhnZmR4/Efp3/O57S76HOyaMWYloj0vs2OQH3TJTm7
> GLvO/b9R46mgnnlHVhxN2z1f0xTOFwpeXIjchb+jHs0SuxOVAqrIpGmsFG8Siv/V
> 3spQEzAzM/Enl2PgaCNlU0aus/i35FRLEmlCf7nyuwVQCbsE3d5W/fKLYeJOD9Wq
> CCJOHO3iofZ0wlGnB5J7
> =/qPh
> -END PGP SIGNATURE-
> 
> 
> 
>     CHANGELOG for 8.0.0-M9:
> 
> ** Bug
> 
>     * [WICKET-6332] - NullPointerException in PageParameters#equals()
>     * [WICKET-6441] - MockHttpSession and MockSessionStore don't call
> onInvalidate() on invalidate()
>     * [WICKET-6448] - Provide behavior that disables a button after click
>     * [WICKET-6477] - Component.getDefaultModelObject() wraps in
> RuntimeException instead of WicketRuntimeException
>     * [WICKET-6484] - Wicket.Cookie.set does not set 'secure' flag
>     * [WICKET-6489] - Exception when "identifier|code" javascript is
> not start on PrependJavaScript
>     * [WICKET-6491] - AjaxDownload is not working in blob mode for
> Microsoft browsers
>     * [WICKET-6492] - javascript files are not minified in deployment
> mode and not united
>     * [WICKET-6493] - WebSocket SessionIds are wrong (HttpSession one
> used instead of Websocket one) + NPE if no HttpSession is found during
> Handshake Request
>     * [WICKET-6496] - Duplicate definition of interface JSONString
>     * [WICKET-6501] - DefaultPageManagerProvider does not honour
> StoreSettings.setAsynchronous(false)
>     * [WICKET-6506] - Performance issue when large component isn't visible
>     * [WICKET-6512] - pageId is being reset during
> Session::replaceSession() call
>     * [WICKET-6513] - NullPointerException at
> PageStoreManager$SessionEntry after login
>     * [WICKET-6518] - Memory leaks on quickstart restart in tomcat
>     * [WICKET-6522] - ThreadLocal leak in PageStoreManager
>     * [WICKET-6523] - Two AbstractAjaxTimerBehaviors on same component
> 

Re: 8.0.0 blockers

[Korbinian Bachl]

Hello Kamil,

be careful when using this feature in production as there is a race condition 
meaning it depends on network, browser and client thread count if it works or 
not.



- Ursprüngliche Mail -
> Von: "Kamil Paśko" <kamil.pa...@solsoft.pl>
> An: dev@wicket.apache.org
> Gesendet: Samstag, 3. Februar 2018 21:31:43
> Betreff: Re: 8.0.0 blockers

> +1
> 
> I could test this "deferred javascript" issue on real application
> 
> 
>> I'm for a new release too. We have a lot of fixes to release also for 7.x
>> branch.
>>
>> On Feb 3, 2018 11:50 AM, "Martin Grigorov" <martin.grigo...@gmail.com>
>> wrote:
>>
>>> On Feb 3, 2018 09:03, "Maxim Solodovnik" <solomax...@gmail.com> wrote:
>>>
>>> Thanks a lot Andrea!
>>>
>>> Not sure if I can do more for the site update :(
>>>
>>> @Martijn maybe you can provide text for the upcoming release?
>>>
>>> @All, I'm not real fan of it, but maybe it worth to release another "M"?
>>>
>>>
>>> I think it would be better to release another M or RC because there were
>>> some bigger changes lately.
>>>
>>>
>>>
>>> WBR, Maxim
>>> (from mobile, sorry for the typos)
>>>
>>>
>>> On Fri, Feb 2, 2018, 16:25 Andrea Del Bene <an.delb...@gmail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> I've updated copyright year. You don't see 2018 post because it has a
>>>> future date, but you can use flag future:true to show it.
>>>>
>>>> On Fri, Feb 2, 2018 at 4:23 AM, Maxim Solodovnik <solomax...@gmail.com>
>>>> wrote:
>>>>
>>>>> Hello All,
>>>>>
>>>>> I have question regarding site generation.
>>>>>
>>>>> I have added following file: 2018/_posts/2018-02-12-wicket-
>>>>> 8.0.0-released.md
>>>>> But news for 2018 are not being generated
>>>>>
>>>>> Is there any debugger I can use?
>>>>> Or maybe I miss something?
>>>>>
>>>>> Copyright year is also 2017 :(
>>>>>
>>>>>
>>>>> On Fri, Feb 2, 2018 at 12:09 AM, Sven Meier <s...@meiers.net> wrote:
>>>>>
>>>>>> Hi Korbinian,
>>>>>>
>>>>>> no problem at all!
>>>>>>
>>>>>> With the new JavaScriptFilteredHeaderResponse we can continue to
>>>> improve
>>>>>> deferred loading, without having to change anything in Wicket's core
>>>> Ajax
>>>>>> handling.
>>>>>>
>>>>>> Sven
>>>>>>
>>>>>>
>>>>>>
>>>>>> Am 01.02.2018 um 17:39 schrieb Korbinian Bachl:
>>>>>>
>>>>>>> Im really sorry Sven but I broke your defer patch :/
>>>>>>>
>>>>>>> see comment here:
>>>>>>> https://issues.apache.org/jira/browse/WICKET-6498
>>>>>>>
>>>>>>> A solution to it is provided :)
>>>>>>>
>>>>>>>
>>>>>>> - Ursprüngliche Mail -
>>>>>>>
>>>>>>>> Von: "Sven Meier" <s...@meiers.net>
>>>>>>>> An: dev@wicket.apache.org
>>>>>>>> Gesendet: Donnerstag, 1. Februar 2018 14:15:11
>>>>>>>> Betreff: Re: 8.0.0 blockers
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Am I right thinking Wicket 1.5 will be discontinued and Wicket6
>>> will
>>>> be
>>>>>>>> moved to "security updates only" mode?
>>>>>>>>
>>>>>>>> Yes I think so.
>>>>>>>>
>>>>>>>> Sven
>>>>>>>>
>>>>>>>> ⁣Gesendet mit Blue
>>>>>>>>
>>>>>>>> Am 1. Feb. 2018, 14:00, um 14:00, Maxim Solodovnik <
>>>>> solomax...@gmail.com
>>>>>>>> schrieb:
>>>>>>>>
>>>>>>>>> Hello All,
>>>>>>>>>
>>>>>>>>> I have created wicket-8 branch in wicket-site repository.
>>>>>>>>> I believe the main work should be done in 2018/_posts/
&

Re: 8.0.0 blockers

[Korbinian Bachl]

Hi Martin,

i think we dont see jQuery as problem, but mere the current integration of all 
wicket JS and ajax and the depending on it. Its more an adaption to current 
standards, where old IEs and other quirks in browsers aren't needed anymore - 
so to say. 

Currently wicket has a real big problem with first page impression and high 
speed rendering on mobile devices as all JS resources are limited by wicket in 
not beeing able to get deffered or even async'd. Ideally the wicket JS 
integration not only should accept defer but be built around full async into 
the JS part - that however would not be possible with jQuery as this one only 
allows defer at max as the ordering matters here...

Best,

KB


- Ursprüngliche Mail -
> Von: "Martin Grigorov" <mgrigo...@apache.org>
> An: dev@wicket.apache.org
> Gesendet: Dienstag, 2. Januar 2018 12:43:41
> Betreff: Re: 8.0.0 blockers

> Hi,
> 
> 1) one can always replace the version with JavaScriptLibrarySettings
> 2.x is used as default because most jQuery plugins are not migrated to 3.x,
> JS folks moved to more modern JS solutions (React, Angular, Vue, ...)
> 
> 2) wicket-ajax-*jquery*.js is named this way because it depends on jQuery!
> One can always implement the Wicket.xyz JS APIs on top of vanilla JS, Dojo
> 2.x, Angular 5.x, ... And use it via
> JavaScriptLibrarySettings#setWicketAjaxReference()
> Such alternative implementation can be introduced at any version of Wicket.
> 
> 
> But what exactly is the problem with jQuery (in Wicket) ?
> Why its event listeners do not work for this use case ?
> 
> 
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
> 
> On Tue, Jan 2, 2018 at 12:54 PM, Sven Meier <s...@meiers.net> wrote:
> 
>> Please take a look at the pull request:
>>
>>   https://github.com/apache/wicket/pull/253
>>
>> As you can see, there are many places that have to work together - do you
>> see a good way to make that configurable?
>>
>> I'd prefer to support a single solution only:
>> addEventListener() instead of jQuery "domready"/"load" and maybe a central
>> hook allowing to defer all JavaScript resources (perhaps there's already
>> one I'm not aware of).
>>
>> This way users can defer JavaScript if they want to, but we don't force it
>> on everyone (e.g. if they still need JavaScriptHeaderItems).
>> IMHO moving the framework away from jQuery is the right direction anyway
>> (see http://youmightnotneedjquery.com/), but perhaps Wicket 8 (or shortly
>> before the 8.0.0 release) is not the right moment for it.
>>
>> Regards
>> Sven
>>
>>
>>
>> Am 02.01.2018 um 11:34 schrieb Martin Makundi:
>>
>>> If configuration option is final solution then yes, otherwise it opens a
>>> new can of worms for backwards (and on-site branching) compatibility.
>>>
>>> **
>>> Martin
>>> +0.02
>>>
>>> 2018-01-02 12:29 GMT+02:00 Korbinian Bachl <korbinian.bachl@whiskyworld.d
>>> e>:
>>>
>>> May I ask why not a simple Config option? When disabled current behaviour
>>>> (default) but when turned on new behaviour? That way it wont break
>>>> anything
>>>> and may be added to wicket any time?
>>>>
>>>> I just ask because this "not in that version" etc. usually is the reason
>>>> why some Frameworks seems less active/ agile as others. Maybe I miss the
>>>> big picture but I really would hate it if I have to wait for a new major
>>>> version of wicket each time we need to keep up with the developement of
>>>> the
>>>> browsers... long time ago there was a discussion what version of jQuery
>>>> should be in wicket and it went on 2, a sane idea at that time, but now
>>>> as
>>>> its 2018 I - for example - would instead now only ship JQuery 3.x default
>>>> for wicket as the time has changed.
>>>> I wonder how wicket will keep up with that if the cycle is so long each
>>>> time...
>>>>
>>>> Best
>>>>
>>>> KB
>>>>
>>>> PS: I know that you can override the jQuery version as you like, it is
>>>> just an example how the "best idea/ way to do it" changes over time
>>>>
>>>> - Ursprüngliche Mail -
>>>>
>>>>> Von: "Sven Meier" <s...@meiers.net>
>>>>> An: dev@wicket.apache.org
>>>>> Gesendet: Dienstag, 2. Januar 2018 10:57:39
>>>>> Betreff: Re: 8.0.0 blockers
>&g

Re: 8.0.0 blockers

[Korbinian Bachl]

May I ask why not a simple Config option? When disabled current behaviour 
(default) but when turned on new behaviour? That way it wont break anything and 
may be added to wicket any time?

I just ask because this "not in that version" etc. usually is the reason why 
some Frameworks seems less active/ agile as others. Maybe I miss the big 
picture but I really would hate it if I have to wait for a new major version of 
wicket each time we need to keep up with the developement of the browsers... 
long time ago there was a discussion what version of jQuery should be in wicket 
and it went on 2, a sane idea at that time, but now as its 2018 I - for example 
- would instead now only ship JQuery 3.x default for wicket as the time has 
changed. 
I wonder how wicket will keep up with that if the cycle is so long each time...

Best

KB

PS: I know that you can override the jQuery version as you like, it is just an 
example how the "best idea/ way to do it" changes over time

- Ursprüngliche Mail -
> Von: "Sven Meier" <s...@meiers.net>
> An: dev@wicket.apache.org
> Gesendet: Dienstag, 2. Januar 2018 10:57:39
> Betreff: Re: 8.0.0 blockers

> Hi Maxim,
> 
> I don't think WICKET-6498 will be part of Wicket 8:
> There are still conceptual open questions (who decides what resources to 
> defer)
> and implementation issues, i.e. does the proposed solution with
> addEventListener work in all browsers.
> 
> Thanks for testing this.
> Sven
> 
> ⁣Gesendet mit Blue 
> 
> Am 2. Jan. 2018, 09:13, um 09:13, Maxim Solodovnik <solomax...@gmail.com>
> schrieb:
>>I'll try to test WICKET-6498 today/tomorrow
>>
>>On Sun, Dec 31, 2017 at 5:04 PM, Martijn Dashorst <
>>martijn.dasho...@gmail.com> wrote:
>>
>>> I’m working on restyling the QuickStart to look like the new
>>examples. Not
>>> a blocker but would be awesome to include. Will work on it 2nd Jan
>>>
>>> Martijn
>>>
>>>
>>>
>>> Op vr 29 dec. 2017 om 20:28 schreef Korbinian Bachl <
>>> korbinian.ba...@whiskyworld.de>
>>>
>>> > May I also mention WICKET-6498?
>>> >
>>> > https://issues.apache.org/jira/browse/WICKET-6498
>>> >
>>> >
>>> >
>>> > - Ursprüngliche Mail -
>>> > > Von: "Sven Meier" <s...@meiers.net>
>>> > > An: dev@wicket.apache.org
>>> > > Gesendet: Freitag, 29. Dezember 2017 16:22:47
>>> > > Betreff: Re: 8.0.0 blockers
>>> >
>>> > > Not strictly necessary, but I would like to merge WICKET-6503:
>>> > >
>>> > > https://issues.apache.org/jira/browse/WICKET-6503
>>> > >
>>> > > Have fun
>>> > > Sven
>>> > >
>>> > >
>>> > > Am 29.12.2017 um 06:02 schrieb Maxim Solodovnik:
>>> > >> Hello All,
>>> > >>
>>> > >> Is it time for release?
>>> > >>
>>> > >> There are long holidays upcoming here, so I can send more time
>>on
>>> Wicket
>>> > >> :)))
>>> > >>
>>> > >>
>>> > >> On Thu, Nov 30, 2017 at 9:36 PM, Andrea Del Bene <
>>> an.delb...@gmail.com>
>>> > >> wrote:
>>> > >>
>>> > >>> On Thu, Nov 30, 2017 at 1:07 PM, Martijn Dashorst <
>>> > >>> martijn.dasho...@gmail.com> wrote:
>>> > >>>
>>> > >>>> No technical blockers AFAIK, however, we really should do the
>>> > marketing
>>> > >>>> right:
>>> > >>>>
>>> > >>>> - front page of website should feature 8 prominently
>>> > >>>> - work with Sally from PR for a press release to let the world
>>know
>>> we
>>> > >>> are
>>> > >>>> not Dead Yet™
>>> > >>>> - have a really great announcement to give to the world about
>>all
>>> the
>>> > >>>> benefits of Wicket 8
>>> > >>>>
>>> > >>>> What are the key features that necessitate upgrading to Wicket
>>8?
>>> > >>>>
>>> > >>>> Not blocking but really important:
>>> > >>>>
>>> > >>>> - have a story to answer "Why not just use XXX.js?"
>>> > >>>> - have a story to answer "Isn't

Re: 8.0.0 blockers

[Korbinian Bachl]

May I also mention WICKET-6498? 

https://issues.apache.org/jira/browse/WICKET-6498



- Ursprüngliche Mail -
> Von: "Sven Meier" 
> An: dev@wicket.apache.org
> Gesendet: Freitag, 29. Dezember 2017 16:22:47
> Betreff: Re: 8.0.0 blockers

> Not strictly necessary, but I would like to merge WICKET-6503:
> 
> https://issues.apache.org/jira/browse/WICKET-6503
> 
> Have fun
> Sven
> 
> 
> Am 29.12.2017 um 06:02 schrieb Maxim Solodovnik:
>> Hello All,
>>
>> Is it time for release?
>>
>> There are long holidays upcoming here, so I can send more time on Wicket
>> :)))
>>
>>
>> On Thu, Nov 30, 2017 at 9:36 PM, Andrea Del Bene 
>> wrote:
>>
>>> On Thu, Nov 30, 2017 at 1:07 PM, Martijn Dashorst <
>>> martijn.dasho...@gmail.com> wrote:
>>>
 No technical blockers AFAIK, however, we really should do the marketing
 right:

 - front page of website should feature 8 prominently
 - work with Sally from PR for a press release to let the world know we
>>> are
 not Dead Yet™
 - have a really great announcement to give to the world about all the
 benefits of Wicket 8

 What are the key features that necessitate upgrading to Wicket 8?

 Not blocking but really important:

 - have a story to answer "Why not just use XXX.js?"
 - have a story to answer "Isn't Java Server Side frameworks dead?"

>>> I (partially) covered these two issues in my presentation. Maybe it can be
>>> helpful for further considerations:
>>>
>>> http://events.linuxfoundation.org/sites/events/files/slides/
>>> Wicket_The_story_so_far_and_beyond.pdf
>>>
>>>
 - have a story to answer "Isn't Java dead"

>>> Java will never die :-)
>>>
>>>
 Have a call list for when a reporter wants to have contact about Wicket 8
 and its future (esp. related to questions above)

 Other things to consider:

 - prepare some articles to publish to dzone, voxxed, etc.?

>>> I'm preparing an article for dzone. You can find it here:
>>>
>>> https://www.dropbox.com/s/l9ec2plxyhe4aa2/article8.txt
>>>
>>> Any feedback is welcome!
>>>
>>>
 Martijn


 On Wed, Nov 29, 2017 at 3:32 AM, Maxim Solodovnik 
 wrote:

> Hello All,
>
> do we have any blockers for 8.0.0?
>
>
> --
> WBR
> Maxim aka solomax
>


 --
 Become a Wicket expert, learn from the best: http://wicketinaction.com

>>

Re: 8.0.0 blockers

[Korbinian Bachl]

Welcome to my world :)

Anyway thanks for the hints. Seems i need somehow to make brix-cms be able to 
at least put that into the footer area at least thats the only way I can 
think of right now;



- Ursprüngliche Mail -
> Von: "Maxim Solodovnik" <solomax...@gmail.com>
> An: dev@wicket.apache.org
> Gesendet: Mittwoch, 29. November 2017 10:08:15
> Betreff: Re: 8.0.0 blockers

> I love to help here
> But I don't see clear solution .
> 
> 
> On Wed, Nov 29, 2017 at 4:06 PM, Korbinian Bachl <
> korbinian.ba...@whiskyworld.de> wrote:
> 
>> Not really as were on brix-cms, meaning we dont usually touch wicket and
>> loading the complete JS in header is a bad idea as long as its not capable
>> of beeing defered - the performance gets worse then in our tries
>>
>> - Ursprüngliche Mail -
>> > Von: "Maxim Solodovnik" <solomax...@gmail.com>
>> > An: dev@wicket.apache.org
>> > Gesendet: Mittwoch, 29. November 2017 10:01:46
>> > Betreff: Re: 8.0.0 blockers
>>
>> > You can add your scripts to the "custom place"
>> > https://ci.apache.org/projects/wicket/guide/8.x/
>> single.html#_put_javascript_inside_page_body
>> > And provide your "minified and optimized JS file from webdesigner" jquery
>> > version as the main one for wicket .
>> >
>> > On Wed, Nov 29, 2017 at 3:57 PM, Korbinian Bachl <
>> > korbinian.ba...@whiskyworld.de> wrote:
>> >
>> >> Yes, you are right - it has to be optional at least, something even the
>> >> current jQuery reference isn't yet (you only can provide an empty one js
>> >> file - still a request);
>> >>
>> >> From my experience this all is worse than at the time before jQuery was
>> >> introduced to wicket as this really slows down the DOM process. In my
>> >> proposal I at least made the mistake that I didnt think of additional
>> >> libraries adding more JS header items - but it should end up with better
>> >> rendering overall IMHO?
>> >> Maybe a concentation of all these header things in an external resouce
>> >> file might be the better solution... (e.g.: 

Re: 8.0.0 blockers

[Korbinian Bachl]

Not really as were on brix-cms, meaning we dont usually touch wicket and 
loading the complete JS in header is a bad idea as long as its not capable of 
beeing defered - the performance gets worse then in our tries

- Ursprüngliche Mail -
> Von: "Maxim Solodovnik" <solomax...@gmail.com>
> An: dev@wicket.apache.org
> Gesendet: Mittwoch, 29. November 2017 10:01:46
> Betreff: Re: 8.0.0 blockers

> You can add your scripts to the "custom place"
> https://ci.apache.org/projects/wicket/guide/8.x/single.html#_put_javascript_inside_page_body
> And provide your "minified and optimized JS file from webdesigner" jquery
> version as the main one for wicket .
> 
> On Wed, Nov 29, 2017 at 3:57 PM, Korbinian Bachl <
> korbinian.ba...@whiskyworld.de> wrote:
> 
>> Yes, you are right - it has to be optional at least, something even the
>> current jQuery reference isn't yet (you only can provide an empty one js
>> file - still a request);
>>
>> From my experience this all is worse than at the time before jQuery was
>> introduced to wicket as this really slows down the DOM process. In my
>> proposal I at least made the mistake that I didnt think of additional
>> libraries adding more JS header items - but it should end up with better
>> rendering overall IMHO?
>> Maybe a concentation of all these header things in an external resouce
>> file might be the better solution... (e.g.: 

Re: 8.0.0 blockers

[Korbinian Bachl]

Yes, you are right - it has to be optional at least, something even the current 
jQuery reference isn't yet (you only can provide an empty one js file - still a 
request);

>From my experience this all is worse than at the time before jQuery was 
>introduced to wicket as this really slows down the DOM process. In my proposal 
>I at least made the mistake that I didnt think of additional libraries adding 
>more JS header items - but it should end up with better rendering overall 
>IMHO? 
Maybe a concentation of all these header things in an external resouce file 
might be the better solution... (e.g.: 

Re: 8.0.0 blockers

[Korbinian Bachl]

I'd like some comment on WICKET-6498, as that wicket-JS impl. currently is just 
not good IMHO as its blocking the DOM with JS;

Best,

KB



- Ursprüngliche Mail -
> Von: "Maxim Solodovnik" 
> An: dev@wicket.apache.org
> Gesendet: Mittwoch, 29. November 2017 03:32:48
> Betreff: 8.0.0 blockers

> Hello All,
> 
> do we have any blockers for 8.0.0?
> 
> 
> --
> WBR
> Maxim aka solomax

Re: Question regarding WICKET-6497 unify javascript files

[Korbinian Bachl]

Hello,

wouldn't option 2 put the Jjqery.js into it? 

Best,

KB

- Ursprüngliche Mail -
> Von: "Maxim Solodovnik" 
> An: dev@wicket.apache.org
> Gesendet: Mittwoch, 22. November 2017 07:21:22
> Betreff: Question regarding WICKET-6497 unify javascript files

> Hello,
> 
> I'm currently investigating "WICKET-6497 unify javascript files".
> As far as I understand Wicket unifies JS code blocks, but not JS references
> 
> So the only options are:
> 1) create 1 JS file and put contents of these 2 in it
> 2) perform combining at compile time using maven plugin [1]
> 
> I can implement 2) above. Would it be OK? Maybe there are better options?
> 
> [1] http://samaxes.github.io/minify-maven-plugin/usage.html
> 
> --
> WBR
> Maxim aka solomax

wicket 8 - js to asnyc and or defer?

[Korbinian Bachl]

Hi,

after WICKET-6492 seems to take care of the bug of minification and even 
uniting of the Javascript files of wicket, I wonder if wicket cant even get 
better in the js part. Currently each page having ajax somehow ends up with 
following in the head:

(1)
(2)
(3)

(4 - inline var and not really an issue)

/**/


(5)
/**/



While 1,2 and 3 could be easily made at least defer, script 5 makes this 
impossible so far, having all 4 scripts lead to a slower DOMContentLoaded 
(requestet and executed 1 by 1), even these are not needed at that time and 
could IMHO be easily postponed to a time when the rendering tree is ready (and 
so dont block it);

The real culprint IMHO is (5) and that it immediately needs the Wicket.Event 
object - so, I see 2 solutions for this: 

1st: outline this code into a request specific js-src file that can be loaded 
like e.g.: 

Re: WICKET-6481

[Korbinian Bachl]

and if you make it

Integer.MAX_VALUE - 1 

as default? :)

- Ursprüngliche Mail -
> Von: "Andrea Del Bene" 
> An: dev@wicket.apache.org
> Gesendet: Dienstag, 17. Oktober 2017 12:11:06
> Betreff: Re: WICKET-6481

> On Tue, Oct 17, 2017 at 9:32 AM, Martin Grigorov 
> wrote:
> 
>> Hi,
>>
>> MountedMapper should return higher compatibilityScore for "page/foo" than
>> PageInstanceMapper for the same path.
>>
> 
> This is not so easy as PageInstanceMapper already returns Integer.MAX_VALUE
> if it matches.
> 
> 
>> Even more strict: PageInstanceMapper should not deal with anything that has
>> more segments than "page".
>>
>>
> This is easier to do and less risky IMHO.
> 
> I think we should also check at startup time if someone has mounted a page
> to '/page' path (with DefaultMapperContext), which is totally incompatible
> with PageInstanceMapper
> 
> 
>> Martin Grigorov
>> Wicket Training and Consulting
>> https://twitter.com/mtgrigorov
>>
>> On Mon, Oct 16, 2017 at 6:35 PM, Andrea Del Bene 
>> wrote:
>>
>> > Hi,
>> >
>> > this issue is caused by a problem with mounted entities (pages,
>> resources,
>> > packages). If the path we use starts with segments from IMapperContext
>> the
>> > corresponding mapper is not resolved. For example a page mounted to
>> > 'page/foo' is handled with a PageInstanceMapper and not with its
>> > MountedMapper.
>> > What should we do? Should we check the path  when we mount it and rise an
>> > exception if it is not compatible with IMapperContext?
>> >
>> > Andrea.
>> >

Re: wicket8 : wickets js/ jquery integration

[Korbinian Bachl]

Hi Sven,

in theory you are right - but with wicket ajax on page you get an inline script 
like marting said.

> The problem is that the ondomready scripts depend on jquery and wicket-xyz 
> ones and there is no way to defer them.

So, you never can defer the jQuery currently as its from wicket itself and same 
is IMHO for the wicket js files.

The only way I can think of is to transfer the inline script into a base64 and 
embedd it this way:



Then the jQuery could be made defered - you can check it here: 
https://stackoverflow.com/questions/41394983/how-to-defer-inline-javascript

However, I'm not sure yet that every browser works with this. 

So the put to bottom is IMHO still the best way to do it. Or did I miss 
something here?

Also what do you think on allowing to not use the wicket jQuery at all? 
e.g.: getJavaScriptLibrarySettings().setJQueryReference(null);

Anyway, I think wicket should not block the rendering of the page by default, 
especially as mobile is becoming the 50%+ audience nowadays.


Best,

Korbinian




- Ursprüngliche Mail -
> Von: "Sven Meier" <s...@meiers.net>
> An: dev@wicket.apache.org
> Gesendet: Samstag, 7. Oktober 2017 22:22:56
> Betreff: Re: wicket8 : wickets js/ jquery integration

> Hi Korbinian,
> 
> using the "defer" attribute on script tags in the head section seems to
> be best practice now:
> 
> https://www.shivering-isles.com/the-science-of-loading-javascript/
> 
> Wicket supports the attribute since
> https://issues.apache.org/jira/browse/WICKET-5715
> 
> Have fun
> Sven
> 
> 
> Am 07.10.2017 um 19:49 schrieb Korbinian Bachl:
>> Hi,
>>
>> currently wicket renders all its jQuery and Ajax stuff right into the head, 
>> and
>> I wonder why.
>>   
>> Current best practice seems to defer all javascript till the end of the page
>> just right before the closing  tag to let the browser meanwhile get 
>> the
>> DOM and do some work and not get blocked by loading resources. So wouldnt it
>> maybe with wicket 8 be a good time to change this?
>>
>> e.g. Do
>>
>> 
>> all the stuff
>>
>> > src="../wicket/resource/org.apache.wicket.resource.JQueryResourceReference/jquery/jquery.js">
>> 
>> ajax stuff...
>> 
>> 
>>
>> by default? and since mostly today jQuery is already on the page maybe even
>> allow to apply a null at the
>> getJavaScriptLibrarySettings().setJQueryReference(null); to not have a wicket
>> reference on it at all? Many webapps nowadays tend to only have 1 app.js that
>> includes everything as its often build by tools like webpack.
>>
>> Would this be a good or bad idea?
>>
>> Best,
>>
>> Korbinian
>>
>> PS: in wicket 8 jquery 2.x is interchangable with jquery 3.x, am I right?

wicket8 : wickets js/ jquery integration

[Korbinian Bachl]

Hi,

currently wicket renders all its jQuery and Ajax stuff right into the head, and 
I wonder why.
 
Current best practice seems to defer all javascript till the end of the page 
just right before the closing  tag to let the browser meanwhile get the 
DOM and do some work and not get blocked by loading resources. So wouldnt it 
maybe with wicket 8 be a good time to change this?

e.g. Do 


all the stuff



ajax stuff...



by default? and since mostly today jQuery is already on the page maybe even 
allow to apply a null at the 
getJavaScriptLibrarySettings().setJQueryReference(null); to not have a wicket 
reference on it at all? Many webapps nowadays tend to only have 1 app.js that 
includes everything as its often build by tools like webpack.

Would this be a good or bad idea?

Best,

Korbinian

PS: in wicket 8 jquery 2.x is interchangable with jquery 3.x, am I right?

wicket-8 m8

[Korbinian Bachl]

Hi,

due to the problematic bugs in wicket8 up to m7 (2 x pagestore and 
filesystemresource-leak), would it be possible to release wicket8-m8 anytime 
soon?

Best,

Korbinian

Re: Major page store issue found in 7.8.0, release a 7.8.1?

[Korbinian Bachl]

Please also wicket 8 - this one is a real problem


- Ursprüngliche Mail -
> Von: "Emond Papegaaij" 
> An: dev@wicket.apache.org
> CC: "Martijn Dashorst" 
> Gesendet: Mittwoch, 30. August 2017 13:10:27
> Betreff: Re: Major page store issue found in 7.8.0, release a 7.8.1?

> I've applied to fix to 6.x, 7.x and 8 (master). IMHO this issue warrants a
> patch-release for at least 6 (6.27.1) and 7 (7.8.1).
> 
> Best regards,
> Emond
> 
> On dinsdag 29 augustus 2017 15:26:06 CEST Martijn Dashorst wrote:
>> https://issues.apache.org/jira/browse/WICKET-6387
>> 
>> The original fix apparently introduces the behavior that our logged out
>> users don't remove stale pages from the pagestore because the session is
>> marked "updating"
>> 
>> Any site with major traffic that uses the page store will be affected by
>> this. In Emond and my assessment this will necessitate a 7.8.1 fix as soon
>> as possible.
>> 
>> Does anyone have a better suggestion than Emond proposes in WICKET-6387? (I
>> owe you a beer then), and do you agree that a 7.8.1 should be rolled?
>> 
> > Martijn

Re: wicket 8 / javascript

[Korbinian Bachl]

Hi,

> 
>>
>> - JS Code is not compressed/ optimized for production; so far only
>> comments are stripped out but no real optimization in terms of newline
>> (nearly 3k!) and whitespaces are done
>>
> 
> Not true!
> At
> https://github.com/apache/wicket/tree/master/wicket-core/src/main/java/org/apache/wicket/ajax/res/js
> there are only non-compressed but in the produced wicket-core.jar there are
> .min.js next to them.
> 
> 

Thats irritating, on our deployed live app with wicket 8.0.0-M7 (in production 
mode) these are not compressed?


>>

>> Beside this, it is also noticable that the jQuery JS file gets stripped of
>> its copyright notice, see:
>>
> 
> This must be
> https://github.com/apache/wicket/blob/411aa0ee38d45232f075549bf7212e78a0c626ce/wicket-core/src/main/java/org/apache/wicket/javascript/DefaultJavaScriptCompressor.java
> You can disable it with getResourceSettings().setJavaScriptCompressor(null)
> 

I'm not sure this is legally enough... I mean by default wicket strips legal 
notices I know this is annoying;

wicket 8 / javascript

[Korbinian Bachl]

Hi,

after deploying our app with wicket 8, I've seen that the javacript files of 
AJAX are not really optimised.

Issues are:

- 2 Files - instead of putting out 1 file of JS for wicket, we get 2 (3 if we 
count jQuery); I dont see this as good especially since 1 of those files is 
quite small...

- JS Code is not compressed/ optimized for production; so far only comments are 
stripped out but no real optimization in terms of newline (nearly 3k!) and 
whitespaces are done

Beside this, it is also noticable that the jQuery JS file gets stripped of its 
copyright notice, see:

http://examples8x.wicket.apache.org/ajax/wicket/resource/org.apache.wicket.resource.JQueryResourceReference/jquery/jquery-2.2.4-ver-F9EE266EF993962AD59E804AD9DEBE66.js


Best,

KB

PS: we're on wicket 8 M7;

Re: [VOTE] Release Apache Wicket 8.0.0-M7

[Korbinian Bachl]

Hello Andrea,

currently the jira shows M7 as unreleased with 1 item toDo, see 
https://issues.apache.org/jira/projects/WICKET/versions/12340604

Best,

KB

- Ursprüngliche Mail -
> Von: "Andrea Del Bene" 
> An: dev@wicket.apache.org
> Gesendet: Samstag, 12. August 2017 17:02:58
> Betreff: Re: [VOTE] Release Apache Wicket 8.0.0-M7

> This vote passes with 3 binding votes.
> 
> Thank you all!!
> 
> Andrea.
> 
> 
> On 10/08/2017 14:52, Sebastien wrote:
>>   [x] Yes, release Apache Wicket 8.0.0-M7
>>
>> Tested upon wicket-jquery-ui samples

Re: Wicket 8 (M7) release

[Korbinian Bachl]

 Sun, Aug 6, 2017 at 7:34 PM, Maxim Solodovnik <solomax...@gmail.com>
> wrote:
> 
>> As far as I can see nothing blocks the release
>> +1 :)
>>
>> On Mon, Aug 7, 2017 at 12:25 AM, Andrea Del Bene <an.delb...@gmail.com>
>> wrote:
>> > I guess now we are ready to start the release of M7, right?
>> >
>> >
>> > On 05/08/2017 17:12, Maxim Solodovnik wrote:
>> >>
>> >> https://github.com/apache/wicket/pull/228
>> >>
>> >> On Sat, Aug 5, 2017 at 12:04 PM, Maxim Solodovnik <solomax...@gmail.com
>> >
>> >> wrote:
>> >>>
>> >>> OK, thanks
>> >>> will prepare PR
>> >>>
>> >>> On Sat, Aug 5, 2017 at 11:59 AM, Martin Grigorov
>> >>> <martin.grigo...@gmail.com> wrote:
>> >>>>
>> >>>> Hi Maxim,
>> >>>>
>> >>>> On Aug 5, 2017 3:28 AM, "Maxim Solodovnik" <solomax...@gmail.com>
>> wrote:
>> >>>>
>> >>>> Hello All,
>> >>>>
>> >>>> I would like to update version on libraries being used by wicket to
>> the
>> >>>> most recent versions is it OK?
>> >>>>
>> >>>>
>> >>>> Sure!
>> >>>>
>> >>>>
>> >>>> report can be get as follows (with some exceptions of course):
>> >>>>
>> >>>> mvn versions:display-dependency-updates
>> >>>>
>> >>>>
>> >>>>
>> >>>> On Sat, Aug 5, 2017 at 3:26 AM, Tobias Soloschenko <
>> >>>> tobiassolosche...@googlemail.com> wrote:
>> >>>>
>> >>>>> +1 for M7
>> >>>>>
>> >>>>> kind regards
>> >>>>>
>> >>>>> Tobias
>> >>>>>
>> >>>>>> Am 04.08.2017 um 18:56 schrieb Korbinian Bachl <
>> >>>>>
>> >>>>> korbinian.ba...@whiskyworld.de>:
>> >>>>>>
>> >>>>>> Please a thousand +1 (non-binding)
>> >>>>>>
>> >>>>>> :)
>> >>>>>>
>> >>>>>> - Ursprüngliche Mail -
>> >>>>>>>
>> >>>>>>> Von: "Andrea Del Bene" <an.delb...@gmail.com>
>> >>>>>>> An: dev@wicket.apache.org
>> >>>>>>> Gesendet: Freitag, 4. August 2017 17:12:43
>> >>>>>>> Betreff: Re: Wicket 8 (M7) release
>> >>>>>>> Hi,
>> >>>>>>>
>> >>>>>>> I think we are ready to promote Wicket 8 to GA but I would wait for
>> >>>>>>> September as August is usually a very quite month (at least in
>> >>>>>>> Europe)
>> >>>>>
>> >>>>> so
>> >>>>>>>
>> >>>>>>> it risks to be overlooked. But I have no objection to prepare a M7
>> in
>> >>>>>
>> >>>>> the
>> >>>>>>>
>> >>>>>>> meantime.
>> >>>>>>>
>> >>>>>>> What do you think?
>> >>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> WBR
>> >>>> Maxim aka solomax
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> WBR
>> >>> Maxim aka solomax
>> >>
>> >>
>> >>
>> >
>>
>>
>>
>> --
>> WBR
>> Maxim aka solomax

Re: Wicket 8 (M7) release

[Korbinian Bachl]

Please a thousand +1 (non-binding)

:)

- Ursprüngliche Mail -
> Von: "Andrea Del Bene" 
> An: dev@wicket.apache.org
> Gesendet: Freitag, 4. August 2017 17:12:43
> Betreff: Re: Wicket 8 (M7) release

> Hi,
> 
> I think we are ready to promote Wicket 8 to GA but I would wait for
> September as August is usually a very quite month (at least in Europe) so
> it risks to be overlooked. But I have no objection to prepare a M7 in the
> meantime.
> 
> What do you think?

wicket 8.0.0-M7? / FROM: [VOTE] Release Apache Wicket 7.8.0

[Korbinian Bachl]

Hello Maxim,

I've looked at the issue and I must say that I'm not sure how to properly fix 
that (in logic terms). One could now just use the 

public StringValue get(final String name) and
public StringValue get(final int index)

to use the locale provided by the session, but this would be a nightmare for 
anyone to migrate to 8 and not check all kind of stuff he gets into any params 
and the session locales that might get used IMHO (also one need to take care 
that a session might not even exist and not be desired by the time the value is 
called, so this has to be checked, too).

I would at a maximumg provide a 

public StringValue getLocalized(final String name) and
public StringValue getLocalized(final int index)

versions to access the values directly in need of a version to have respected 
the session locale. IMHO not something so big and special it has to be in 
wicket especially when it changes a behaviour that was in place from beginning;

Anyway, it is not my decision to make, just my 2c to it. Since wicket 
8.0.0.final seems to be halted by this, might you be able to release a 8.0.0-M7 
version?


Best,

KB


- Ursprüngliche Mail -
> Von: "Maxim Solodovnik" <solomax...@gmail.com>
> An: dev@wicket.apache.org
> Gesendet: Mittwoch, 12. Juli 2017 12:47:27
> Betreff: Re: [VOTE] Release Apache Wicket 7.8.0

> WICKET-6419 <https://issues.apache.org/jira/browse/WICKET-6419> might be
> blocker for 8.0.0 release ...
> 
> On Wed, Jul 12, 2017 at 5:46 PM, Korbinian Bachl <
> korbinian.ba...@whiskyworld.de> wrote:
> 
>> Would a wicket 8.0.0 release be possible soon?
>>
>> (I know I'm nagging :) )
>>
>> - Ursprüngliche Mail -
>> > Von: "Andrea Del Bene" <an.delb...@gmail.com>
>> > An: dev@wicket.apache.org
>> > Gesendet: Mittwoch, 12. Juli 2017 11:40:57
>> > Betreff: Re: [VOTE] Release Apache Wicket 7.8.0
>>
>> > This vote passes with 4 binding votes.
>> >
>> > Thank you all!!
>> >
>> > Andrea.
>> >
>> > On Tue, Jul 11, 2017 at 8:43 PM, Andrea Del Bene <an.delb...@gmail.com>
>> > wrote:
>> >
>> >> [ X ] Yes, release Apache Wicket 7.8.0
>> >>
>> >> tested tutorial examples and random examples from wicket-examples
>> >>
>> >> andrea.
>> >>
>> >>
>> >>
>> >> On 10/07/2017 10:28, Martin Grigorov wrote:
>> >>
>> >>> [ X ] Yes, release Apache Wicket 7.8.0
>> >>>
>> >>> Tested:
>> >>> - local build
>> >>> - Wicketstuff (staged at
>> >>> https://oss.sonatype.org/content/repositories/orgwicketstuff-1082/)
>> >>> - my main daily job application
>> >>>
>> >>> Martin Grigorov
>> >>> Wicket Training and Consulting
>> >>> https://twitter.com/mtgrigorov
>> >>>
>> >>> On Sat, Jul 8, 2017 at 6:41 PM, Andrea Del Bene <an.delb...@gmail.com>
>> >>> wrote:
>> >>>
>> >>> This is a vote to release Apache Wicket 7.8.0
>> >>>>
>> >>>> Please download the source distributions found in our staging area
>> >>>> linked below.
>> >>>>
>> >>>> I have included the signatures for both the source archives. This vote
>> >>>> lasts for 72 hours minimum.
>> >>>>
>> >>>> [ ] Yes, release Apache Wicket 7.8.0
>> >>>> [ ] No, don't release Apache Wicket 7.8.0, because ...
>> >>>>
>> >>>> Distributions, changelog, keys and signatures can be found at:
>> >>>>
>> >>>>  https://dist.apache.org/repos/dist/dev/wicket/7.8.0
>> >>>>
>> >>>> Staging repository:
>> >>>>
>> >>>>
>> >>>> https://repository.apache.org/content/repositories/
>> orgapachewicket-1095/
>> >>>>
>> >>>> The binaries are available in the above link, as are a staging
>> >>>> repository for Maven. Typically the vote is on the source, but should
>> >>>> you find a problem with one of the binaries, please let me know, I can
>> >>>> re-roll them some way or the other.
>> >>>>
>> >>>> Staging git repository data:
>> >>>>
>> >>>>  Repository:  g...@github.com:bitstorm/wicket.git
>> >>>>  Branch:  build/wicket-7.8.0
&

Re: [VOTE] Release Apache Wicket 7.8.0

[Korbinian Bachl]

Would a wicket 8.0.0 release be possible soon?

(I know I'm nagging :) )

- Ursprüngliche Mail -
> Von: "Andrea Del Bene" 
> An: dev@wicket.apache.org
> Gesendet: Mittwoch, 12. Juli 2017 11:40:57
> Betreff: Re: [VOTE] Release Apache Wicket 7.8.0

> This vote passes with 4 binding votes.
> 
> Thank you all!!
> 
> Andrea.
> 
> On Tue, Jul 11, 2017 at 8:43 PM, Andrea Del Bene 
> wrote:
> 
>> [ X ] Yes, release Apache Wicket 7.8.0
>>
>> tested tutorial examples and random examples from wicket-examples
>>
>> andrea.
>>
>>
>>
>> On 10/07/2017 10:28, Martin Grigorov wrote:
>>
>>> [ X ] Yes, release Apache Wicket 7.8.0
>>>
>>> Tested:
>>> - local build
>>> - Wicketstuff (staged at
>>> https://oss.sonatype.org/content/repositories/orgwicketstuff-1082/)
>>> - my main daily job application
>>>
>>> Martin Grigorov
>>> Wicket Training and Consulting
>>> https://twitter.com/mtgrigorov
>>>
>>> On Sat, Jul 8, 2017 at 6:41 PM, Andrea Del Bene 
>>> wrote:
>>>
>>> This is a vote to release Apache Wicket 7.8.0

 Please download the source distributions found in our staging area
 linked below.

 I have included the signatures for both the source archives. This vote
 lasts for 72 hours minimum.

 [ ] Yes, release Apache Wicket 7.8.0
 [ ] No, don't release Apache Wicket 7.8.0, because ...

 Distributions, changelog, keys and signatures can be found at:

      https://dist.apache.org/repos/dist/dev/wicket/7.8.0

 Staging repository:


 https://repository.apache.org/content/repositories/orgapachewicket-1095/

 The binaries are available in the above link, as are a staging
 repository for Maven. Typically the vote is on the source, but should
 you find a problem with one of the binaries, please let me know, I can
 re-roll them some way or the other.

 Staging git repository data:

      Repository:  g...@github.com:bitstorm/wicket.git
      Branch:      build/wicket-7.8.0
      Release tag: rel/wicket-7.8.0


 

      The signatures for the source release artefacts:


 Signature for apache-wicket-7.8.0.zip:

      -BEGIN PGP SIGNATURE-
 Version: GnuPG v1

 iQIcBAABAgAGBQJZYLxvAAoJEAzCjx+CMhBVTZYQAK+meFQ369uBzF9I5/slF5B7
 IDkchyU4HESUSJq6F+oGYYPBx5d6uDelk0yrGFC5h0jPys7PmjjjKzIrWrp8asbg
 b9arUJsbEYvXqxY3/6jv7cA5e8/jZQVmL4gn1Y0zOZLL4i71haS6syafmuSMhqrN
 +qcbr0X8SquDSlfBXHUGl5HYfggvM8ryfn9BHp0LXUmByHPvipCxaAW2iAH08Uws
 sUrkVgQxPlsDeb+TRqDU2oEO3JGMBam7lc5lL7OUJihIBiYXTKUAFmoHZ93w34uA
 HhkddE4IS+JppAgBJUYTtnZau8nwoimNlipmzPLbP7f81DRBAl4g7YyhN80uMRrC
 Hf+pfjhHDK9MDZDJ3fvZKJI3SRoLDDogkCO5VWdSrm327YU3noauJaQfI16CPQQ0
 KLv5oX8G2qnj1waJxrymPRfKv8H4EaODleH3SPY6tFez0YqVnPdVCN+8ivveS7LC
 Xhm27wiIBiBWqnYNdFXu1+bul06rVoZINjohMx5ehQ8Be5t/ffwd+abEBXPEZvWc
 82LuSzjZyTYztGwCq5zTjaqu07k1VEfs+YUwyMsxYhLiCE7FFvtBxprHJxW0pXni
 ZohPCJ/0Wu+4q9O9D02FieZQmJBqmWH5wND7JQw98LWZQVqz56rmA3qqJLzqezuK
 opP+d0HegKBF0uC2YvlE
 =Hwk8
 -END PGP SIGNATURE-

 Signature for apache-wicket-7.8.0.tar.gz:

      -BEGIN PGP SIGNATURE-
 Version: GnuPG v1

 iQIcBAABAgAGBQJZYLxvAAoJEAzCjx+CMhBVjy4P/0OGngs8Uk2GQ+dMmhnzo6d3
 yIg7CRnJtX16nZu58hyE5kUyWIq2ySpomlbD6cBxP16R1nzUHNDdijroWC8zAx2q
 y7F/f7vDXcKhW8P8y21lZqffGHhEwaey1b3aTmUmqiZGjohtvZx3ED+Y3JdIGxHL
 VmO7deEirPJGyptSB0pu+STcltbU3+9H1pcfuaPKxB9Ucr08AIEtTWwuZWg9DHdb
 5U26S5VX0gNNd2Otivf49I6G6BWml5Kpx5z4yBFolgajbKHJ+vveBOND0d8fw4te
 c6nKFV1hIR4eXXhfI584+MuLcI83V86Tc/sFQgNk/1uIGIdBE0mcRd7YqemNLu+u
 tF52Zii0HHScp8ocOU+B+lYL5Keek4WkCQ7oZqjKZx5rjZS9AsF1041PcZ31JDlk
 c8Y4qhF1Add/msFuyeo3nsiu6xky/wHef5pCTcjLi66+8X+53tjUQed8BqiZDCcm
 NeOfwOQ4MWUWNz7Sfs/gayI4vZ9uFksJik7g/XR/o2L2Dny+J0PsA/kCHurhT0rb
 IfhcyrGgLn6zDpDafullJv9N0mwyBUGW//4GhhHmM1SmCKr57sDobalZFjeMTv4p
 b/3JYMD6O7AdS5Eyj+LU6Pg2vK10oW2fP/H0clCKqIzsF5rdNDcjVTDCwnal5y+W
 S0QhZQSTWuzVS8MA4W4b
 =sf4k
 -END PGP SIGNATURE-

 

      CHANGELOG for 7.8.0:

 ** Bug

      * [WICKET-4324] - [wicket-ioc] LazyInitProxyFactory CGLIB proxies
 naming strategy may cause java.lang.IllegalAccessError
      * [WICKET-6362] - HeaderItems with different PageParameters are
 treated as identical
      * [WICKET-6366] - Autocomplete race condition makes page
 unresponsive
      * [WICKET-6373] - Edge not recognized in UserAgent
      * [WICKET-6374] - Exception caused by border extending another
 border
 with 
      * [WICKET-6376] - Ajax redirects to non http(s)-urls are interpreted
 as relative
      * [WICKET-6377] - Autolinking breaks hierarchy for nested elements
      * 

wicket8 - enclosure & onBeforeRender

[Korbinian Bachl]

Hi,

is it intended that any wicket:enclosure breaks if it is depending on a 
component that is not added in the constructor but in "onBeforeRender"?

e.g:



Bezeichnung:
value



with java:
public HomePage(final PageParameters parameters) {
super(parameters);
add(new Label("version", 
getApplication().getFrameworkSettings().getVersion()));
    }

works while if you delay it to:

@Override
protected void onBeforeRender() {
super.onBeforeRender();
add(new Label("version", 
getApplication().getFrameworkSettings().getVersion()));
}

it breaks with:

12:00:25.172 [main] WARN  RequestCycleExtra - 
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.666 sec <<< 
FAILURE! - in com.mycompany.TestHomePage
homepageRendersSuccessfully(com.mycompany.TestHomePage)  Time elapsed: 0.589 
sec  <<< ERROR!
org.apache.wicket.WicketRuntimeException: Could not find child with id: version 
in the wicket:enclosure
at 
org.apache.wicket.markup.html.internal.Enclosure.checkChildComponent(Enclosure.java:295)




Best,

KB

examples8x.wicket.apache.org / 503

[Korbinian Bachl]

Hello,

http://examples8x.wicket.apache.org/ is giving me a 503 for several days now. 
Can you please tell me who is in charge of it?

Best,

Korbinian

wicket 8 - state of it?

[Korbinian Bachl]

Hi,

according to jira 
(https://issues.apache.org/jira/projects/WICKET/versions/12340604) only 1 open 
issue before wicket8-m7 (WICKET-6406).

So I ask myself, humble wicket devs, how the current plan for the release might 
be. With JAVA 9 out soon (83 days) wouldnt it be time to move wicket8 at least 
into beta stage?


Best,

Korbiniam

wicket 6348 / now missing parameter

[Korbinian Bachl]

Hi,

in https://issues.apache.org/jira/browse/WICKET-6348 the way how to react on 
onSelectionChanged(Object object) got changed to now a usage of 

// Wicket 7.x
new CheckBox("id", model) {
protected boolean wantOnSelectionChangedNotifications() {
return true;
}
 
protected void onSelectionChanged(Boolean newSelection) {
// do something, page will be rerendered;
}
};
 
 
// Wicket 8.x
new CheckBox("id", model)
.add(new FormComponentUpdatingBehavior() {
protected void onUpdate() {
// do something, page will be rerendered;
}
 
protected void onError(RuntimeException ex) {
super.onError(ex);
}
});


My Problem is now that I try to get brix cms to compile and I have a code in 
there as:


form.add(new DropDownChoice("tileType", new PropertyModel(this, 
"newTileTypeName"), new TileTypeNamesModel(),
new TileTypeNameRenderer()) {
private static final long serialVersionUID = 1L;
[]

@Override
protected void onSelectionChanged(String tileTypeName) {
   [...]
}

}.setRequired(true));


How can one access the String tileTypeName now in usage of the new 
FormComponentUpdatingBehaviour as the onUpdate there has no parameter at all ???



Best,

KB

wicket 8 m5?

[Korbinian Bachl]

Hi,

is it planned to have a 8-m5 anytime soon? I ask because quite much changed 
(e.g.: BookmarkableListenerRequestHandler, other JSON) and I really had some 
time keeping up the current snapshot builds with my project. 

Also, any idea when can wicket-8.0 be expected?

Best,

Korbinian

Re: Use jQuery 3.x by default in 8.x

[Korbinian Bachl]

Hi Martin,

I dont want to retire jQuery in an "get it out asap" approach, but more closely 
migrate away from it slowly... I mean, if you ditch jQuery it would still be 
needed by my own apps and a load of others, too - as it just here yet :) 
Basically Emond got a great idea about that!

In its own way, jQuery 3.x is breaking with backwards-compatiblity; Ditching IE 
is one thing, but also older mobile ones will break. Plus: once on 3.x you 
can't easily use older plugins

I dont care if 1.12.x is used or 3.x - but 3.x will break much more than 1.12.x 
would... 



- Ursprüngliche Mail -
> Von: "Martin Grigorov" <mgrigo...@apache.org>
> An: dev@wicket.apache.org
> Gesendet: Montag, 20. März 2017 13:01:05
> Betreff: Re: Use jQuery 3.x by default in 8.x

> On Mon, Mar 20, 2017 at 12:47 PM, Andrea Del Bene <an.delb...@gmail.com>
> wrote:
> 
>> I see your point Korbinian, but JQuery still wildly used and removing it
>> would mean not just a lot of effort, but also to indefinitely postpone the
>> release of version 8.
>>
> 
> I also think it is too early to retire jQuery.
> 
> But anyone can replace wicket-ajax-jquery.js with
> getJavaScriptLibrarySettings().setWicketAjaxReference(...) !
> 
> 
>>
>> On Mon, Mar 20, 2017 at 11:33 AM, Korbinian Bachl <
>> korbinian.ba...@whiskyworld.de> wrote:
>>
>> > Hi,
>> >
>> > while I'm not one of the commiters I still like to respond to this. I'm
>> > fine with changing from 1.x to 3.x as IE 10 and lower really has no
>> > relevance anymore IMHO.
>> > However, the real question that came into my mind:
>> >
>> > Why not just use plain js / vanilla js?
>> >
>> > When it was decided to go to jQuery doing pure js at that time was a
>> > nightmare - every browser had its quirks (where every is mainly that MS
>> > pile of crap called IE), reacted differently etc. - but now in 2017 I
>> dont
>> > really see so much more difference here. The same basic JS code to find a
>> > dom in every browser is just now
>> >
>> > var matches = document.querySelectorAll('div.foo');
>> >
>> > while in jQuery its
>> >
>> > var matches = $.('div.foo');
>> >
>> > - no real difference here.
>> >
>> > Ajax? -
>> >
>> > $.ajax('/user/1')
>> > .done(function (data) {
>> >   var user = data;
>> > });
>> >
>> > vs
>> >
>> > fetch('/user/1')
>> > .then(function (response) {
>> >   return response.json();
>> > })
>> > .then(function (data) {
>> >   var user = data;
>> > });
>> >
>> >
>> > ok a small bit more and no IE support - but we just ditch that with
>> jquery
>> > 3.x anyway
>> > (if IE is needed: ugly XMLHttpRequest)
>> >
>> > Just my 2c,
>> >
>> > Best,
>> >
>> > KB
>> >
>> >
>> >
>> >
>> > - Ursprüngliche Mail -
>> > > Von: "Martin Grigorov" <mgrigo...@apache.org>
>> > > An: dev@wicket.apache.org
>> > > Gesendet: Montag, 20. März 2017 09:52:17
>> > > Betreff: Use jQuery 3.x by default in 8.x
>> >
>> > > Hi,
>> > >
>> > > It is 14 months since Microsoft droppped the support for IE 10 and less
>> > [0].
>> > > Do you agree that it is OK to use jQuery 3.x in Wicket 8.x by default ?
>> > >
>> > > Applications will still be able to set custom version (like 1.x) if
>> they
>> > > need so.
>> > > Also our JS tests will keep testing against jQuery 1.x, 2.x and 3.x
>> [1].
>> > >
>> > > 0. https://www.microsoft.com/en-us/WindowsForBusiness/End-of-
>> IE-support
>> > > 1.
>> > > https://github.com/apache/wicket/blob/1421ea2dc9207143cdadb735f3c794
>> > 21674d924d/testing/wicket-js-tests/Gruntfile.js#L111-L118
>> > >
>> > > Martin Grigorov
>> > > Wicket Training and Consulting
>> > > https://twitter.com/mtgrigorov
>> >

Re: Use jQuery 3.x by default in 8.x

[Korbinian Bachl]

Hi,

while I'm not one of the commiters I still like to respond to this. I'm fine 
with changing from 1.x to 3.x as IE 10 and lower really has no relevance 
anymore IMHO. 
However, the real question that came into my mind: 

Why not just use plain js / vanilla js? 

When it was decided to go to jQuery doing pure js at that time was a nightmare 
- every browser had its quirks (where every is mainly that MS pile of crap 
called IE), reacted differently etc. - but now in 2017 I dont really see so 
much more difference here. The same basic JS code to find a dom in every 
browser is just now 

var matches = document.querySelectorAll('div.foo');

while in jQuery its

var matches = $.('div.foo');

- no real difference here.

Ajax? - 

$.ajax('/user/1')
.done(function (data) {
  var user = data;
});

vs 

fetch('/user/1')
.then(function (response) {
  return response.json();
})
.then(function (data) {
  var user = data;
});


ok a small bit more and no IE support - but we just ditch that with jquery 3.x 
anyway 
(if IE is needed: ugly XMLHttpRequest)

Just my 2c,

Best,

KB




- Ursprüngliche Mail -
> Von: "Martin Grigorov" 
> An: dev@wicket.apache.org
> Gesendet: Montag, 20. März 2017 09:52:17
> Betreff: Use jQuery 3.x by default in 8.x

> Hi,
> 
> It is 14 months since Microsoft droppped the support for IE 10 and less [0].
> Do you agree that it is OK to use jQuery 3.x in Wicket 8.x by default ?
> 
> Applications will still be able to set custom version (like 1.x) if they
> need so.
> Also our JS tests will keep testing against jQuery 1.x, 2.x and 3.x [1].
> 
> 0. https://www.microsoft.com/en-us/WindowsForBusiness/End-of-IE-support
> 1.
> https://github.com/apache/wicket/blob/1421ea2dc9207143cdadb735f3c79421674d924d/testing/wicket-js-tests/Gruntfile.js#L111-L118
> 
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov

Re: WICKET-6088 / breaking of custom markup manipulation

[Korbinian Bachl]

Hi Martin,

did a report: https://issues.apache.org/jira/browse/WICKET-6251

Best,

Korbinian

- Ursprüngliche Mail -
> Von: "Martin Grigorov" <mgrigo...@apache.org>
> An: dev@wicket.apache.org
> Gesendet: Montag, 3. Oktober 2016 14:27:15
> Betreff: Re: WICKET-6088 / breaking of custom markup manipulation

> Hi Korbinian,
> 
> Ingo has already reported this issue few months ago:
> http://markmail.org/message/d4w4ffwcdbaehltv
> 
> The "component queueing" stuff broke (and still breaks) a lot of
> functionality in Wicket 7.x.
> Kudos to Andrea Del Bene for his efforts trying to fix all corner cases!
> 
> You could file a ticket at JIRA and hope that Andrea will find a fix for it.
> 
> IMO the component queueing was a mistake and should be removed in a future
> version of Wicket.
> 
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
> 
> On Mon, Oct 3, 2016 at 1:50 PM, Korbinian Bachl <
> korbinian.ba...@whiskyworld.de> wrote:
> 
>> Hello,
>>
>> I've just done some debugging work for Ingo Renner. His project is somehow
>> similar to the brix cms and the way of manipulating the components within
>> the markup stream resolution. This worked in 6.x and 7.0-7.2, but was
>> broken in 7.3+ with commit:
>>
>> https://github.com/apache/wicket/commit/309fb0801a91d1c8be078767243ace
>> 384729f7f0
>>
>> as the dequeueAutoComponents not longer was part of the process; A manual
>> execution of it alone in e.g.: onInitialize also won't work as only the
>> first rendering works, the following wont refresh the markup (since some
>> parts get cached contrary to previuous behavior).
>>
>> While I understand that its important to enhance wicket as a framework, I
>> really dont understand why this has to be done in a subversion. Why not in
>> e.g.: wicket 8? This way any upgrade from wicket 7.2 to 7.3 just may break
>> existing apps.
>>
>> Best,
>>
>> Korbinian
>>
>> --
>>
>> example from Ingo that breaks by just moving from 7.2 to 7.3:
>>
>>
>>
>>
>>
>>
>>
>>
>> @Override
>>
>> public IResourceStream getMarkupResourceStream(MarkupContainer container
>> , Class containerClass ) {
>>
>>
>>
>> // This simulates loading the template from external source
>>
>> InputStream src = HomePage. class .getResourceAsStream( "HomePageSrc.html"
>> );
>>
>> String srcStr = "" ;
>>
>> try {
>>
>> srcStr = Streams. readString ( src );
>>
>>
>>
>> // now replacing my special markup "tag" with a real html tag
>>
>> srcStr = srcStr .replace( "${tile}" , "wicket:id=\"tile\">" );
>>
>>
>>
>> // and adding the component to the page
>>
>> HomePage. this .add( new Label( "tile" , Model. of ( "Content of dynamic
>> component aka tile." )));
>>
>>
>>
>> } catch (IOException e ) {
>>
>> // TODO Auto-generated catch block
>>
>> e .printStackTrace();
>>
>> }
>>
>> StringResourceStream stringResourceStream = new StringResourceStream(
>> srcStr , "text/html" );
>>
>> return stringResourceStream ;
>>
>> }

WICKET-6088 / breaking of custom markup manipulation

[Korbinian Bachl]

Hello, 

I've just done some debugging work for Ingo Renner. His project is somehow 
similar to the brix cms and the way of manipulating the components within the 
markup stream resolution. This worked in 6.x and 7.0-7.2, but was broken in 
7.3+ with commit: 

https://github.com/apache/wicket/commit/309fb0801a91d1c8be078767243ace384729f7f0
 

as the dequeueAutoComponents not longer was part of the process; A manual 
execution of it alone in e.g.: onInitialize also won't work as only the first 
rendering works, the following wont refresh the markup (since some parts get 
cached contrary to previuous behavior). 

While I understand that its important to enhance wicket as a framework, I 
really dont understand why this has to be done in a subversion. Why not in 
e.g.: wicket 8? This way any upgrade from wicket 7.2 to 7.3 just may break 
existing apps. 

Best, 

Korbinian 

-- 

example from Ingo that breaks by just moving from 7.2 to 7.3: 








@Override 

public IResourceStream getMarkupResourceStream(MarkupContainer container , 
Class containerClass ) { 



// This simulates loading the template from external source 

InputStream src = HomePage. class .getResourceAsStream( "HomePageSrc.html" ); 

String srcStr = "" ; 

try { 

srcStr = Streams. readString ( src ); 



// now replacing my special markup "tag" with a real html tag 

srcStr = srcStr .replace( "${tile}" , "" ); 



// and adding the component to the page 

HomePage. this .add( new Label( "tile" , Model. of ( "Content of dynamic 
component aka tile." ))); 



} catch (IOException e ) { 

// TODO Auto-generated catch block 

e .printStackTrace(); 

} 

StringResourceStream stringResourceStream = new StringResourceStream( srcStr , 
"text/html" ); 

return stringResourceStream ; 

} 

Re: [VOTE] Release Apache Wicket 6.5.0

[Korbinian Bachl]

How can it be published there on 19th of January?

That's two (2) days before even the vote was closed!

--
Korbinian

- Ursprüngliche Mail -
 Von: Guillaume Smet guillaume.s...@gmail.com
 An: dev@wicket.apache.org
 Gesendet: Mittwoch, 23. Januar 2013 01:28:29
 Betreff: Re: [VOTE] Release Apache Wicket 6.5.0
 
 On Tue, Jan 22, 2013 at 10:09 PM, Andreas Pieber anpie...@gmail.com wrote:
  Will the release be available before at m2 central?
 
 It's already there:
 http://search.maven.org/#search|gav|1|g%3A%22org.apache.wicket%22%20AND%20a%3A%22wicket%22
 
 --
 Guillaume
 

wicket 6.0 - programmatic HTTPS switch

[Korbinian Bachl - privat]

Hello,

is it possible in wicket 6.0 to programatically switch to SSL mode? - 
I've read that according to the wiki:
HttpsMapper has been refactored to make subclassing easier - but 
couldnt find the jira for it?


Reason why I'm asking is that I'm trying to get Brix CMS working with 
wicket 5 or 6 and all time I'm hitting the wall when I need to tell 
wicket that this page now (!) is SSL required while next isn't (Hint to 
people unfamiliar with brix: all content is provided by same page 
creating its content from an jcr - so annotating the page @RequireHttps 
isn't possible - instead the decision if SSL or not needs to be 
calculated on every page instance rendering depending on the content);


What about the idea to give Component an overridiable enum var like:

ENUM Component.RequireqProtocol {
sslNotRequired, sslRequired, protocolPreserved
}

public Component.RequiredProtocol getSecurityRequirement() {
return Component.RequiredProtocol.protocolPreserved;
}

And anyone who needs it can just override it? - Compared to the 
annotation approach this can be implemented in a logic sensitive way if 
needed



Regards,

KB

Re: Ajax in Wicket.next

[Korbinian Bachl - privat]

Well, I think there is consent that we can say current wicket ajax is 
quite broken and a big pain in everyday usage.


The current ajax means loads of code in java for even trivial things. 
Triple-checking that a component knows its ajax and so on. So even *if* 
it will break api in future, I don't see a way around this!


Do we want all those AjaxRequestTargets, .setOutput**(boolean) and 
more of this even here in some years? Don't think so.


The other question is now what to do (from a higher perspective):

1st: do it on own
2nd: use somebody else's work

I would go for 2 and most specific go for a complete jQuery based 
wicket. Reasons are:


- jQuery is well designed, upgrade paths are good documented

- jQuery is *known* to already many many people, there are a ton of 
documentation out there - from books to DVD's!


- jQuery is actively developed by quite many people, just see how many 
are taking care for just (!) a JavaScript library: 
http://jquery.org/team/ and then compare the manpower to wicket itself 
that has much more to be taken care of


- jQuery *is* browser safe! I cant stop counting the times when I 
upgraded a browser and suddenly wicket Ajax stopped working, currently 
Opera 11.51 just killed one of my modal windows - at version 10.50 it 
worked... staying up to date now would only mean to make sure jQuery is 
up-to-date


- jQuery gives you hooks to interact with and provides some sort of 
layering, but please don't go the spring way (nobody needs *another* own 
breed java-script layer that then won't be really worked on and/ or 
cared for up-to-dateness)


and final

-jQuery will save the wicket dev's much work in the future!


my 2c



Am 19.09.11 17:29, schrieb Martin Grigorov:

Hi,

In the recent ticket changes by Igor I mentioned few comments that
Ajax will be re-written for Wicket.next (1.6, 3.0, 6.0 - whatever we
call it).

I want to share my experience with trying to re-vive Matej's work at [1], [2].
The changes there are a bit drastic (maybe because the task hasn't
been finished and the API breaks not cleaned) and knowing how Ajax
heavy are the applications I've worked on I think it will be quite a
work to migrate the apps from 1.5 to Wicket.next.
I also tried to introduce wicket-ajax.jar with the new impl and keep
the old one for transition but that wasn't easy too.

So I want to propose a two step approach:
1) introduce some JavaScript library for Wicket.next and improve
wicket-xyz.js files by using it
2) improve/reimplement Wicket Ajax for Wicket.next+1


martin-g

1. 
http://svn.apache.org/viewvc/wicket/sandbox/knopp/experimental/wicket/src/main/java/org/apache/_wicket/ajax/
2. https://github.com/martin-g/wicket/tree/ajax2

Re: Ajax in Wicket.next

[Korbinian Bachl - privat]

tetsu, ever tried to:

- get an AjaxRequestTarget in a component that was not designed by ajax 
in mind?


- tried to ajaxify a table-row in a dataTable component?

- tried ajax with repeaters?

- tried to interact with a modal window from inside in case you have a 
pure non-ajax page within it?


of even

- got tired with the verbose .setOut... .setMark... true?

- wondered why my ajaxified component got more lines of code then the 
rest of the page?





Am 19.09.11 19:20, schrieb tetsuo:

What is so broken about the current ajax in Wicket, that requires such
rewrite?



On Mon, Sep 19, 2011 at 1:11 PM, Igor Vaynbergigor.vaynb...@gmail.comwrote:


staged approach is fine, however its step 2 only that will cause
migration headaches, so this is just delaying the inevitable...

-igor


On Mon, Sep 19, 2011 at 8:29 AM, Martin Grigorovmgrigo...@apache.org
wrote:

Hi,

In the recent ticket changes by Igor I mentioned few comments that
Ajax will be re-written for Wicket.next (1.6, 3.0, 6.0 - whatever we
call it).

I want to share my experience with trying to re-vive Matej's work at [1],

[2].

The changes there are a bit drastic (maybe because the task hasn't
been finished and the API breaks not cleaned) and knowing how Ajax
heavy are the applications I've worked on I think it will be quite a
work to migrate the apps from 1.5 to Wicket.next.
I also tried to introduce wicket-ajax.jar with the new impl and keep
the old one for transition but that wasn't easy too.

So I want to propose a two step approach:
1) introduce some JavaScript library for Wicket.next and improve
wicket-xyz.js files by using it
2) improve/reimplement Wicket Ajax for Wicket.next+1


martin-g

1.

http://svn.apache.org/viewvc/wicket/sandbox/knopp/experimental/wicket/src/main/java/org/apache/_wicket/ajax/

2. https://github.com/martin-g/wicket/tree/ajax2

Re: Ajax in Wicket.next

[Korbinian Bachl - privat]

Hi Martin,

Am 20.09.11 09:59, schrieb Martin Grigorov:
...

Well, I think there is consent that we can say current wicket ajax is quite
broken and a big pain in everyday usage.

Really? Is that broken ?
Neither mailing lists questions nor tickets prove that statement.


The current ajax means loads of code in java for even trivial things.
Triple-checking that a component knows its ajax and so on. So even *if* it
will break api in future, I don't see a way around this!

Do we want all those AjaxRequestTargets, .setOutput**(boolean) and more
of this even here in some years? Don't think so.

What do you suggest ?
The only option that I see as automatic is to set it for each and
every component, no matter whether it will be ever updated with Ajax
or not.



Ok, well, wicket consists of components. So basically it is making a
page full of a tree with components. Wicket now could scan the component
if it has any Ajax on it - then auto add what it needs like the
setOuput... - so we got rid of this.

Then the AjaxRequestTarget. Maybe its me but I find passing around this
thing all over more a headache then a help. Basically, what we do with
ajax is that we do it twice. Add it to page via .add and to
target.addComponent - so why? Because wicket differs between those
scopes, even they are same in the end (only question is: send the whole
page or just a part to the browser?).
So we really need to ask ourself why we need 2 things? If a page is
changed after beeing send to browser, don't we know automatically it is
Ajaxified when we get an ajax request? Can't the default request not
behave accordingly, so we can get rid of the whole AjaxRequestTarget? I
mean the whole wicket-ajax needs to be thought about.

Imagine that we could unite Link and AjaxLink and AjaxFallbackLink to
just a general Link with a simple onClick() method and if you want ajax
you just did link.actAsAjax(true);

 Wepapps are getting more and more dynamic and we need to look if we
can't make it more a breeze to work with. Currently I love wicket and
praise it when I work with traditional pages, but as soon as have more
than one Ajax component on a page I start asking myself if I shouldn't
dump it.



The other question is now what to do (from a higher perspective):

1st: do it on own
2nd: use somebody else's work

I would go for 2 and most specific go for a complete jQuery based wicket.

This is clear.


oh is it already? :)


Reasons are:

...


Not sure whether you invested some of your time to see what is needed
by wicket-ajax.js and what JQuery (or other major JS libs) offers but
my investigation showed that none of them solves the problem with
replaceOuterHtml() out of the box. So we will have to translate our
code in JQuery parlance but still will have to keep the hacks.


Well I tend to go from top to bottom, not vice versa. That hacks are
needed (would more call it an adapter) is clear, but if you have 2 solid
ends (wicket at one, jQuery at other) is quite more easy to plug them
together then to dump one end because there maybe some hack (tm) at it.
As I outlined above, I would like to ask if the current
AjaxRequestTarget way is the way to go - that of course affects the rest
like wicket-ajax.js;

best

...

Re: Ajax in Wicket.next

[Korbinian Bachl - privat]

Heya,

Am 20.09.11 11:37, schrieb Martin Grigorov:
...



Ok, well, wicket consists of components. So basically it is making a page
full of a tree with components. Wicket now could scan the component if it
has any Ajax on it - then auto add what it needs like the setOuput... - so
we got rid of this.

Consider this example:

Label label = new Label(...);
add(label);

AjaxLink link = new AjaxLink(id) {

public void onClick(ART target) {
  label.setDefaultModelObject(something new);
  target.add(label);
}
}

Now tell me how visiting 'label' or 'link' components you can
automatically extract that 'label' should have
.setOutputMarkupId(true) and set it ?

Visiting the components is fast but do you really want to traverse the
whole page (it can be a big component tree!) and waste CPU just
because you hate to add .setOutputMarkupId(true) where needed or
rolling your own AjaxLabel component which does this in its
constructor.


Wrong approach IMHO. The question is: Do we need outprinted Id's to find 
an element in DOM?
Answer is: No, we don't as long as we know the path (!). Funnywise this 
path is the same path wicket builds and traverses during its rendering 
phase.




Then the AjaxRequestTarget. Maybe its me but I find passing around this
thing all over more a headache then a help. Basically, what we do with ajax
is that we do it twice. Add it to page via .add and to target.addComponent -
so why? Because wicket differs between those scopes, even they are same in
the end (only question is: send the whole page or just a part to the
browser?).
So we really need to ask ourself why we need 2 things? If a page is changed
after beeing send to browser, don't we know automatically it is Ajaxified
when we get an ajax request? Can't the default request not behave
accordingly, so we can get rid of the whole AjaxRequestTarget? I mean the
whole wicket-ajax needs to be thought about.

Moving all this logic in Component#add(Component...) sounds scary...
How do you imagine target.appendJavaScript() to be implemented with
your approach? Just curious.


You missed me. I dont want to make Component another thousand lines 
long, but instead rise the question why we follow the current approach 
like the lemmings and not think about different ways to solve the 
partial ajax updates. And also remember that current Ajax won't work on 
certain elements - or easy spoken: as soon as we don't have our magic 
ID's all goes down the flow.
Now if we say we only have a html manipulator thats based upon the DOM 
tree instead we could get rid of half of the work by just telling the JS 
lib:


element with path div[2]span[1]table[0] gets a new tr[14] with 
code ...


or

element with path div[2]span[1]table[0] gets deleted/ swapped 
tr[9] with code


Imagine now that this would mean wicket can manipulate any element not 
matter if the component behind is Ajaxified or not! Only thing to react 
on would be the Request itself - if its Ajax or nonAjax, then construct 
the pages and differ them internally (already mostly done yet as we have 
a pagemap holding our old pages) and send the right answer to the 
request, be it partial Ajax or Full page.


Or do you see a big problem in that idea?

Re: Ajax in Wicket.next

[Korbinian Bachl - privat]

Am 20.09.11 12:30, schrieb Martin Grigorov:

On Tue, Sep 20, 2011 at 1:11 PM, Korbinian Bachl - privat
korbinian.ba...@whiskyworld.de  wrote:

...


Wrong approach IMHO. The question is: Do we need outprinted Id's to find an
element in DOM?
Answer is: No, we don't as long as we know the path (!). Funnywise this path
is the same path wicket builds and traverses during its rendering phase.

This relies on a great assumption: the user application MUST do any
DOM manipulations thru Wicket, even simple effects or client side
validation for faster feedback. Because if you add a simplespan
just to show something that shouldn't update the server side state
then you cant rely anymore that Wicket will be able to find your
components from there on.

Another problem is that querySelector() is fastest when looking up by
id. Everything else becomes slower depending on the size of the DOM
tree.


These are valid points. Question is if there is only the real path or 
not. Possible ways would be to use DOM from an somewhere present ID, 
limiting the OutputMarkupID to as few places as possible and still 
allowing traversal from that point and this manipulation of DOM parts 
that are not even existing (think of repeaters).


This would mean in default we have a null ID that is the page itself, 
while when the dev wants to finger around using third party JS he could 
specify an ID that is relative to the wicket part he wants to wicket to 
manipulate while the rest outside wont make differences.


e.g.:

divAdivBdivC

he now wants to transform divB using another JS framework

he only needs to specify wicket's JS id on element divC if he wants 
wicket to manipulate this as divA is still reachable from page level


This way we also can introduce new content at places where it hasn't 
been and finally solve the repeater and ajax issues;


Regarding the speed: I'm not sure that its so dramatic in the end and 
see it as solvable in the end when we hit sth. (remember: premature 
optimization is evil);


my2c :)

Re: Ajax in Wicket.next

[Korbinian Bachl - privat]

Am 20.09.11 13:11, schrieb Pointbreak:

I'm completely agreeing with Martin on this one. The things you are
suggesting imho have the following consequences:
- Wicket implementation becomes way more complicated, because Wicket has
to translate between component hierarchy and browser DOM-tree, which is
non-trivial, and requires a lot of extra server side processing.


just a rough idea and not a single implementation yet but we know how 
hard it is to compute?



- User implementation becomes substantially more complicated because one
way or another, the user has to give hints to Wicket how eventual
client-side javascripts not managed by wicket are manipulating the
DOM-tree (which by the way is easy to break between browsers, as
DOM-trees for the same HTML may differ substantially between browsers).


thats a problem either way - ever tried to integrate third party JS with 
wicket?



- Bugs in the user implementation are substantially harder to track than
a forgotten setOutputMarkupId(true) in the current API.


sure?


- This will break existing API functionality and code in a big way.


thats the reason were talking about wicket.next and not wicket.now - and 
api breaks will at some point come else wicket can't go forward




And all that for not having a few extra setOutputMarkupId(true) calls?

If setOutputmarkupId bothers you that much, it's easy to write a visitor
that just calls it for all your components...


now honestly - thanks for not ready anything in the long posts before;

the reason why I'd favor such a thing is that it makes wicket able to 
ajaxify *any* component. Current ajax won't work on all current core 
components - thats it. There is a reason why Martin wanted to completely 
rewrite wicket ajax a time back and it wasn't that he had too much 
leisure time

Re: Roadmap for Wicket 6

[Korbinian Bachl - privat]

My wish list:

1. Java 6

2. JEE6 where possible like e.g. CDI;

3. Modularization using OSGI

4. AJAX overhaul: currently Ajax is a pain in case it gets more 
complicated as one

- needs to add components to target AND page hierarchy;
- needs to do .setOutputId(true) all over
- can't touch invisible containers in e.g.: DataTable

5. look at side-efforts done by matej, igor and co to bring the nice 
things to wicket and enhance/ or replace the affected counterparts of 
wicket (e.g.: DataTable vs. InMethod Grid; bindgen-wicket etc.)


6. Not 100% sure: let the HTML templates feed via a single place so one 
can switch to e.g. a JCR implementation - however, I dont know how this 
could work in conjunction with added jars etc. to path. Idea is to allow 
the templates to live outside the java part (e.g.: CMS);


7. @RequireHTTPS logic overhaul (currently: either must use SSL or 
mustn't use SSL, no may use SSL);




Am 30.08.11 00:12, schrieb Martijn Dashorst:

In order to start discussing what will constitute Wicket Next and
where we want to take our beloved framework, I'll start off with my
wish list:

1. Java 6 as a minimum requirement for *all* of wicket
2. Servlet API 3.0 as a minimum requirement
3. JavaEE 6 support for at least CDI
4. Proper OSGi support
5. Ajax refactoring to use JQuery and provide proper JQuery integration in core
6. Shorter release cycle

I +1000 #1 in my wish list, since then I'll be able to build releases again.

Regarding #6 I aim to release Wicket 6 final in December.

Martijn

Re: JRebel and wicket

[Korbinian Bachl - privat]

Hi,

I don't use jRebel but the differentiation of the add and addOrReplace 
method is something that I still don't understand what it's good for.


Actually if you do in java:

String foo;

foo = new String(world);

no one ever would think about throwing an error because one does

foo = new String(no World); later on

This add(new Label(foo,message)); should behave IMHO the same as 
overwriting objects (and here we just put a new object to the add 
method) is just natural in java as everyone of us does it every day.


IMHO: make addOrReplace deprecated in next 1.4 release and give add the 
same behaviour as current addOrReplace; in 1.5 addOrReplace can be 
stripped completely;


my 2 cents - now flame on me :)



Am 18.11.10 14:25, schrieb Martijn Dashorst:

Relaxing the add() method has been proposed before (by Eelco). It is
not something new, and if it helps people using jrebel to improve
their productivity, that would be a great side effect.

The workaround is indeed to go back to a different page and do the
appropriate clicks again.

Martijn

Re: [vote] release Wicket 1.4.13

[Korbinian Bachl - privat]

+1 release this time :)

Am 27.10.10 09:08, schrieb Jeremy Thomerson:

This vote is to release wicket 1.4.13. This is a bugfix release on the 1.4.x
(stable) branch.

Branch: http://svn.apache.org/repos/asf/wicket/branches/wicket-1.4.13/
Artifacts: http://people.apache.org/~jrthomerson/wicket-1.4.13/dist
Maven repo: http://people.apache.org/~jrthomerson/wicket-1.4.13/m2-repo
Changelog:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310561styleName=Htmlversion=12315330

This vote ends Saturday 2:00am GMT-5

Please test the release and offer your vote:
[ ] Yes, release
[ ] No, don't release it (and please tell us why)

Release Notes - Wicket - Version 1.4.13

** Sub-task
 * [WICKET-3069] - java.rmi not allowed on GAE
 * [WICKET-3112] - Fix of issue 2886 breaks all individual
implementations of any AbstractTree

** Bug
 * [WICKET-2888] - Nullpointer when inserting [i.e. moving] a node in a
TreeTable (AbstactTree, treeNodesInserted)
 * [WICKET-2912] - IE 8 gets 404 error after
continueToOriginalDestination() when app is at root context
 * [WICKET-3052] - HybridUrlCodingStrategy probably uses wrong url
encoding
 * [WICKET-3057] - NPE when deleting a TreeNode with visible children
 * [WICKET-3061] - Whole page returns 404 when resource cannot be found
 * [WICKET-3072] - Deleting only child of collapsed tree node doesn't
update the node
 * [WICKET-3074] - CreditCardValidator throws NumberFormatException on
non-numeric characters.
 * [WICKET-3075] - AJAX file upload fails in IE8 due to
Wicket.Ajax.handleMultipart() sniffing wicket:body tags as an HTML body
element when running Wicket in development mode
 * [WICKET-3076] - UrlUtils.isRelative returns false if URL parameter
contains an absolute URL
 * [WICKET-3083] - Broken AbstarctCalendar dependency
 * [WICKET-3084] - CharSetUtil.getEncoding fails with an
IndexOutOfBoundsException
 * [WICKET-3087] - Form inside ModalWindow causes 'Submit Button not
visible' exception in parent page's form
 * [WICKET-3095] - Adding AjaxFormSubmitBehavior to Form leads to Error:
too much recursion JS Error
 * [WICKET-3098] - AjaxEventBehavior#onEvent is invoked on disabled
behavior
 * [WICKET-3102] - WicketTester does not handle
startPage(ITestPageSource) that contains a redirect/setResponsePage
correctly
 * [WICKET-3106] - Security: Possible Redirection to foreign Page by
using BrowserInfoPage's PageParameter
 * [WICKET-3108] - Problems with page maps stored in session
 * [WICKET-3116] - class cast exception
 * [WICKET-3119] - Localizer cache does not include style in cache key
when no component is given
 * [WICKET-3120] - AbstractHttpSessionStore.bind throws null pointer
exception
 * [WICKET-3127] - Adding node to a collapsed tree node should not cause
it to expand

** Improvement
 * [WICKET-1779] - Palette component - make image URLs part of CSS
 * [WICKET-1936] - Client-Side Image Map
 * [WICKET-2776] - Enhancing RadioChoice input items with individual
title and css class attributes
 * [WICKET-2937] - AbstractPropertyModel getObjectClass don't consider
nested IObjectClassAwareModel targets
 * [WICKET-3055] - Application fails to start when disk access is denied
 * [WICKET-3056] - Upgrade pom reference for joda-time from 1.6 to 1.6.2
 * [WICKET-3071] - Upgrade maven plugins and non-essential dependencies
to newest version
 * [WICKET-3089] - onBeforeRender in NextButton should not be final
 * [WICKET-3090] - Make SecondLevelCacheSessionStore and its
SecondLevelCachePageMap reusable
 * [WICKET-3128] - FormComponentLabel should open open-close tags like
Label does

** New Feature
 * [WICKET-3082] - Introduce IComponentOnInitializeListener for
cross-cutting concerns

Re: 1.4.13 release?

[Korbinian Bachl - privat]

Regarding a release the following issue is a complete showstopper that 
has to be cleared first:


https://issues.apache.org/jira/browse/WICKET-3112

Best

Korbinian

PS: this is same as Brian Toppings mentioned issue but now existing in 
wicket JIRA



Am 16.10.10 08:32, schrieb Jeremy Thomerson:

Anybody interested in a 1.4.13 release in the coming week?  Anything that
you'd like to get in before it's built?  I may have some time next week to
do it.

Re: ComponentTag#append()

[Korbinian Bachl - privat]

Hi,

from a logical point its required IMHO

so +1 from me

Best

Am 28.07.10 15:37, schrieb Martin Grigorov:

Hi,

Since recently we have ComponentTag#append(). It will be included in 1.4.10.
Do we need #prepend() as well ?
I can see users starting asking for this.

wicket examples on WicketStuff

[Korbinian Bachl - privat]

Hello,

the first three examples here 
http://www.wicketstuff.org/wicket14/repeater/ seem to be broken. At 
least when accessing it I get an Internal Error.


Could someone with please have a look at this?

Best,

Korbinian

Re: wicket 1.5 build is failing because of 1.6 deps...

[Korbinian Bachl - privat]

+1 to move to 1.6;

IMHO wicket 1.5 should be state of art in all terms and in case you 
stuck to JDK 1.5 you still can use wicekt 1.4;


IMHO it makes no sense to aim at a plattform thats already EOL like 1.5 
is; (and 1.7 will be out by the time wicket 1.5 is release IMHO)


my 2cents,


Korbinian

James Carman schrieb:

-1 to moving to 1.6.  My client, a global consumer products company,
is not on 1.6 yet and it took me YEARS to get 1.5.  So, I don't see it
happening anytime soon unfortunately.


On Tue, Dec 15, 2009 at 7:13 AM, Steve Swinsburg
steve.swinsb...@gmail.com wrote:

Huh? As has been said, Snow Leopard (OS X 10.6) has Java 1.6 by default. 
Leopard (OS X 10.5) even has it installed, just not linked by default.

+1 to moving to Java 1.6. Java 1.5 is past EOL.

cheers,
Steve



On 15/12/2009, at 10:47 PM, Johan Compagner wrote:


mac's should be totally ignored in this area (and all other area's if you
ask me)
apple and java is the biggest pile of crap i ever worked with


On Tue, Dec 15, 2009 at 12:45, Matej Knopp matej.kn...@gmail.com wrote:


They do, on snow leopard :)

Anyway, I don't feel too strongly about it, certainly won't block 1.6
if others think it's a good idea.

-Matej

On Tue, Dec 15, 2009 at 12:43 PM, Martijn Dashorst
martijn.dasho...@gmail.com wrote:

At our company we've been deploying to 1.6 for over 2 years now. I
know... since I'm on a (32bit) Mac and all my co-workers were able to
compile against 1.6 leaving me behind... Now that even developers on
Macs have Java 6, I seriously think that 1.5 is a dead platform.

Martijn

On Tue, Dec 15, 2009 at 12:38 PM, Matej Knopp matej.kn...@gmail.com

wrote:

I really don't think our core should depend on 1.6. Those few methods
can easyly be put to util classes. Typesafe models can be moved to
separate sub project. I know it makes the build more complicated
again, but 1.6 isn't that common, especially not in production.

-Matej

On Tue, Dec 15, 2009 at 12:36 PM, Carl-Eric Menzel
cm.wic...@users.bitforce.com wrote:

On Tue, 15 Dec 2009 11:44:23 +0100
Martijn Dashorst martijn.dasho...@gmail.com wrote:


I was going to propose a vote in that direction... as JDK 1.5 has been
shelved...


It'll be years until Java 1.6 is as common as 1.5 is now. There are

many

organizations who have only just completed the move to 1.5. I think
going to a strict requirement for Java 1.6 would be a really bad idea,
especially since it does not offer as many significant new benefits as
1.5 did.

Offering 1.6-specific features in a separate jar would be a simple and
pretty good solution, I think. Stuff like the typesafe model would thus
be available for those who need it, without leaving anybody needlessly
stranded.

Carl-Eric




--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.4 increases type safety for web applications
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.4

Re: wicket 1.5 build is failing because of 1.6 deps...

[Korbinian Bachl - privat]

1.5 will be a major one, not minor - so where's the point?

Best,

Korbinian

Carl-Eric Menzel schrieb:

Because, from their (admittedly conservative) point of view, you
don't move essential systems to a platform before you really know it.
Or before your tool vendor finally manages to update their product to
be compatible with 1.5. These are organizations that have to be
extremely careful. Why do you think Sun is still offering paid support
for 1.5? 


It doesn't really matter why they are sticking with 1.5, however. What
really matters is this: There are organizations for whom stability in
the core is more important than having the new features. At the same
time, however, they want to be able to update less essential things
like a GUI framework for as long as possible. If you tell them now they
won't be able to use Wicket after the next minor(!) release and won't
get any support for the old version, they'll go ahead and use Struts.
Okay, that last one is maybe a bit exaggerated, but you get what I mean.

Carl-Eric

WICKET-1597 clearing

[Korbinian Bachl - privat]

Hi,

IMHO WICKET-1597 should be applied soon, however there seems 1 last 
question from Juergen Donnerstag needed to be clearified (and maybe 
implemented):


Applied the change and modified the test cases. Since I wasn't sure if 
/a/?param is the same as /a?param, I didn't commit it but attached the 
patch.


IMHO /a/?param is NOT the same as /a?param

Reason: different paths!

while the queries are exactly the same, the paths arent;

Example:
/a - goes to path-root / and requests file a;
/a/ - goes not to path-root but instead to folder called a and 
requests document null that gets converted to the default-request 
document for that folder - often some index.htm or sth. like that; in 
case there is no default target however, it may be that the webserver/ 
container getting the requests decides to truncate the last / and 
reroutes the request to /a - however, this is dependend on specific 
container-configuration and mustn't be seen as valid default;


see also RFC 3986 example under http://en.wikipedia.org/wiki/URI_scheme 
where exactly is defined that the parts /a and /a/ each belong to 
the so called hierarchical part while the ? sperates it from the query 
part ( [ ? query ]);


Best,

Korbinian

Re: WICKET-1597 clearing

[Korbinian Bachl - privat]

in that case I would suggest some kind of 
setSlashedUrlHandlingPATH(boolean ..) with the default-behaviour that 
wicket handls /a/? and /a? equal;


Korbinian

Juergen Donnerstag schrieb:

I completly agree. And as you mentioned different frameworks might
implement different behaviors. I don't recall exactly but I think I
was under the impression that Wicket didn't make a difference. /a?..
seemed to return the same result as /a/?.. Whether is by intention or
by accident is what I wasn't sure about.

-Juergen

On Thu, Jun 11, 2009 at 11:19 AM, Korbinian Bachl -
privatkorbinian.ba...@whiskyworld.de wrote:

Hi,

IMHO WICKET-1597 should be applied soon, however there seems 1 last question
from Juergen Donnerstag needed to be clearified (and maybe implemented):

Applied the change and modified the test cases. Since I wasn't sure if
/a/?param is the same as /a?param, I didn't commit it but attached the
patch.

IMHO /a/?param is NOT the same as /a?param

Reason: different paths!

while the queries are exactly the same, the paths arent;

Example:
/a - goes to path-root / and requests file a;
/a/ - goes not to path-root but instead to folder called a and requests
document null that gets converted to the default-request document for that
folder - often some index.htm or sth. like that; in case there is no default
target however, it may be that the webserver/ container getting the requests
decides to truncate the last / and reroutes the request to /a - however,
this is dependend on specific container-configuration and mustn't be seen as
valid default;

see also RFC 3986 example under http://en.wikipedia.org/wiki/URI_scheme
where exactly is defined that the parts /a and /a/ each belong to the so
called hierarchical part while the ? sperates it from the query part ( [ ?
query ]);

Best,

Korbinian

Re: i want to crate new help system to my existing application

[Korbinian Bachl - privat]

Martijn,

that won't happen - you forgot to add your bank account details! *SCNR*

Martijn Dashorst schrieb:

Hi,

I really want to help you implement what you want. My daily rate is
€2000 excluding tax. I would like to receive the first three days in
advance.

While waiting for the wire transfer of the first payment, please
consider reading http://www.catb.org/~esr/faqs/smart-questions.html

Anxiously waiting for the money transfer,

Martijn Dashorst

On Fri, Aug 29, 2008 at 4:09 PM, swapnil.wadagave
[EMAIL PROTECTED] wrote:

hi,
i want to make  help system to my existing application.Idea is like there
will be link/button on every page.On clicking on it user can get html/doc
file where help details for paritcular file will be provided.


its very urgent.
please mail me if you have sample program with clear explainantion
Thanks in advance
swapnil
--
View this message in context: 
http://www.nabble.com/i-want-to-crate-new-help-system-to-my-existing-application-tp19220692p19220692.html
Sent from the Wicket - Dev mailing list archive at Nabble.com.

SpringBean DataProvider / LoadableDetachableModels

[Korbinian Bachl - privat]

Hi,

is there a reason that SpringBean is not working automatically within 
IDataProvider  LoadableDetachableModel (you'll need to call 
InjectorHolder.getInjector().inject(this); explicitely)? If no I would 
create a jira request for it.


Best,

Korbinian

Re: Enterprise Application

[Korbinian Bachl - privat]

There is also a german based travel agency that has deployed 20-30
sites based on one Wicket code base iirc.

Der.de, Dertour.de or meiers-weltreisen.de are mentioned there, too


i think the use tapestry in main parts, so they are not a good example.

mm:)



don't think *sigh*... look at the html output.. for example at 
meiers-weltreisen you even can see the wicket:panel tags there...


also, I dont know what BS question it is to ask for a enterprise 
application - what is this for you? complexity? concurrent users? 
security? ... an EA is nothing special, just a kind of buzzword - and 
the last time on discussions like this: TECHNOLOGY DOESN'T MATTER AS 
MUCH AS THE DEVELOPER THAT IS GOING TO IMPLEMENT AND USE IT!



regards

Re: security article on TSS (partly covering wicket)

[Korbinian Bachl - privat]

Hi,


its *not* my opinion - I just read the article and thought you might 
want to know about it. I mean, beside that, it seems as wicket is very 
secure in comparision to the other frameworks mentioned there - 
Honestly, I dont know why this harsh reactions (other mails) came.


Best,

Korbinian

Martijn Dashorst schrieb:

How is HiddenField insecure in your opinion?

Martijn

On Wed, Jul 30, 2008 at 10:59 PM, Korbinian Bachl - privat
[EMAIL PROTECTED] wrote:

HI,

under
http://www.theserverside.com/tt/articles/article.tss?l=AreJavaWebApplicationsSecure
is an article covering java WebApps  security; On part 2 it also looks at
webframeworks for java including wicket 1.3.x - it mentions

Wicket has only one component (HiddenField) vulnerable to integrity
attacks.

maybe this gap could be closed? Also the rest seems aso quite interesting.

Best,

Korbinian

Re: security article on TSS (partly covering wicket)

[Korbinian Bachl - privat]

Hi Eelco,

 towards you, but if they were, I guess that's the danger of being the
 messenger ;-)

yeah the messenger... damn job :P

I mean, I also dont think the rection on theserverside was a good 
choice. Honestly, even the writers didnt know wicket well enough to 
things like crypted URLs they still picked it as nearly the most secure 
one... *that* was quite impressive to me! (sounds to me: well, I dont 
know about its special security features but even the basics seems more 
secure than the rest)


Best,

Korbinian




Eelco Hillenius schrieb:

its *not* my opinion - I just read the article and thought you might want to
know about it. I mean, beside that, it seems as wicket is very secure in
comparision to the other frameworks mentioned there - Honestly, I dont know
why this harsh reactions (other mails) came.


Thanks for sharing. I didn't get the impression that people were harsh
towards you, but if they were, I guess that's the danger of being the
messenger ;-)

Eelco

security article on TSS (partly covering wicket)

[Korbinian Bachl - privat]

HI,

under 
http://www.theserverside.com/tt/articles/article.tss?l=AreJavaWebApplicationsSecure 
is an article covering java WebApps  security; On part 2 it also looks 
at webframeworks for java including wicket 1.3.x - it mentions


Wicket has only one component (HiddenField) vulnerable to integrity 
attacks.


maybe this gap could be closed? Also the rest seems aso quite interesting.

Best,

Korbinian

Re: Swarm Wicket 1.4 m2

[Korbinian Bachl - privat]

Hi Maurice,

thx for the info. Im using the use old wicket authentication thingy 
workaround then :)


Would be cool if wicket 1.4m3 up or so would be compatible to swarm... 
however, do you think it would be possible for you to do a wicket 1.4 
branch of swarm/ wasp then? Im quite busy but maybe someone can grab a 
bit of time to dig a bit in, as I somehow like the idea - after I read 
the doc and your presentation several times - of SWARM for wicket apps 
(especially as its something wicket really needs).


Is there a reason why swarm/ wasp is not going to core for 1.4 ?

Best,

Korbinian


Maurice Marrink schrieb:

Sorry, atm wasp/swarm is not yet compatible with wicket 1.4.
I am waiting for at least a beta of wasp/swarm 1.3.1 before i start
working on version 1.4.
I realize 1.3.1 is long overdue and try to get it out as soon as possible.
In the meantime sorry for the inconvenience.
I am afraid your only option at this time is to check out the entire
wicket security project from svn and patch it to compile against
wicket 1.4
Again sorry for the inconvenience.

Maurice

On Sun, Jul 6, 2008 at 8:19 PM, Korbinian Bachl - privat
[EMAIL PROTECTED] wrote:

Hello,

I just spend some time to change my app (on wicket 1.4) to use the SWARM
implementation of WASP.

However, it seems that WASP 1.3.0 as well as the current 1.3-Snapshot
(1.3.1) wont work with 1.4; The error is nearly allways the same:


1.3.1:

java.lang.NoSuchMethodError:
org.apache.wicket.MetaDataKey.init(Ljava/lang/Class;)V

 
org.apache.wicket.security.log.AuthorizationErrorKey.init(AuthorizationErrorKey.java:41)

 
org.apache.wicket.security.strategies.WaspAuthorizationStrategy.clinit(WaspAuthorizationStrategy.java:57)

 
org.apache.wicket.security.swarm.strategies.SwarmStrategyFactory.newStrategy(SwarmStrategyFactory.java:80)
   org.apache.wicket.security.WaspSession.init(WaspSession.java:48)

 
org.apache.wicket.security.WaspWebApplication.newSession(WaspWebApplication.java:71)
   org.apache.wicket.Session.findOrCreate(Session.java:231)
   org.apache.wicket.Session.findOrCreate(Session.java:214)
   org.apache.wicket.Session.get(Session.java:253)
   org.apache.wicket.RequestCycle.getSession(RequestCycle.java:436)

 
org.apache.wicket.request.AbstractRequestCycleProcessor.resolveHomePageTarget(AbstractRequestCycleProcessor.java:315)

 
org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:159)
   org.apache.wicket.RequestCycle.step(RequestCycle.java:1246)
   org.apache.wicket.RequestCycle.steps(RequestCycle.java:1366)
   org.apache.wicket.RequestCycle.request(RequestCycle.java:499)

 org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:387)

 org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:199)



and 1.3.0:


java.lang.NoSuchMethodError:
org.apache.wicket.MetaDataKey.init(Ljava/lang/Class;)V
   org.apache.wicket.security.checks.WaspKey.init(WaspKey.java:41)

 
org.apache.wicket.security.components.SecureComponentHelper.getSecurityCheck(SecureComponentHelper.java:55)

 
org.apache.wicket.security.strategies.WaspAuthorizationStrategy.getSecurityCheck(WaspAuthorizationStrategy.java:185)

 
org.apache.wicket.security.strategies.WaspAuthorizationStrategy.isActionAuthorized(WaspAuthorizationStrategy.java:159)
   org.apache.wicket.Component.isActionAuthorized(Component.java:1983)
   org.apache.wicket.Page.renderPage(Page.java:855)

 
org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.respond(BookmarkablePageRequestTarget.java:241)

 
org.apache.wicket.request.AbstractRequestCycleProcessor.respond(AbstractRequestCycleProcessor.java:104)

 org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1194)
   org.apache.wicket.RequestCycle.step(RequestCycle.java:1265)
   org.apache.wicket.RequestCycle.steps(RequestCycle.java:1366)
   org.apache.wicket.RequestCycle.request(RequestCycle.java:499)

 org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:387)

 org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:199)



Is there any workaround Maurice?

Best,

Korbinian

Swarm Wicket 1.4 m2

[Korbinian Bachl - privat]

Hello,

I just spend some time to change my app (on wicket 1.4) to use the SWARM 
implementation of WASP.


However, it seems that WASP 1.3.0 as well as the current 1.3-Snapshot 
(1.3.1) wont work with 1.4; The error is nearly allways the same:



1.3.1:

java.lang.NoSuchMethodError: 
org.apache.wicket.MetaDataKey.init(Ljava/lang/Class;)V


org.apache.wicket.security.log.AuthorizationErrorKey.init(AuthorizationErrorKey.java:41)

org.apache.wicket.security.strategies.WaspAuthorizationStrategy.clinit(WaspAuthorizationStrategy.java:57)

org.apache.wicket.security.swarm.strategies.SwarmStrategyFactory.newStrategy(SwarmStrategyFactory.java:80)
org.apache.wicket.security.WaspSession.init(WaspSession.java:48)

org.apache.wicket.security.WaspWebApplication.newSession(WaspWebApplication.java:71)
org.apache.wicket.Session.findOrCreate(Session.java:231)
org.apache.wicket.Session.findOrCreate(Session.java:214)
org.apache.wicket.Session.get(Session.java:253)
org.apache.wicket.RequestCycle.getSession(RequestCycle.java:436)

org.apache.wicket.request.AbstractRequestCycleProcessor.resolveHomePageTarget(AbstractRequestCycleProcessor.java:315)

org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:159)
org.apache.wicket.RequestCycle.step(RequestCycle.java:1246)
org.apache.wicket.RequestCycle.steps(RequestCycle.java:1366)
org.apache.wicket.RequestCycle.request(RequestCycle.java:499)

org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:387)

org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:199)



and 1.3.0:


java.lang.NoSuchMethodError: 
org.apache.wicket.MetaDataKey.init(Ljava/lang/Class;)V

org.apache.wicket.security.checks.WaspKey.init(WaspKey.java:41)

org.apache.wicket.security.components.SecureComponentHelper.getSecurityCheck(SecureComponentHelper.java:55)

org.apache.wicket.security.strategies.WaspAuthorizationStrategy.getSecurityCheck(WaspAuthorizationStrategy.java:185)

org.apache.wicket.security.strategies.WaspAuthorizationStrategy.isActionAuthorized(WaspAuthorizationStrategy.java:159)
org.apache.wicket.Component.isActionAuthorized(Component.java:1983)
org.apache.wicket.Page.renderPage(Page.java:855)

org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.respond(BookmarkablePageRequestTarget.java:241)

org.apache.wicket.request.AbstractRequestCycleProcessor.respond(AbstractRequestCycleProcessor.java:104)

org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1194)
org.apache.wicket.RequestCycle.step(RequestCycle.java:1265)
org.apache.wicket.RequestCycle.steps(RequestCycle.java:1366)
org.apache.wicket.RequestCycle.request(RequestCycle.java:499)

org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:387)

org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:199)



Is there any workaround Maurice?

Best,

Korbinian

Swarm + Wicket 1.4m2

[Korbinian Bachl - privat]

Hello,

I just spend some time to change my app (on wicket 1.4) to use the SWARM 
implementation of WASP.


However, it seems that WASP 1.3.0 as well as the current 1.3-Snapshot 
(1.3.1) wont work with 1.4; The error is nearly allways the same:



1.3.1:

java.lang.NoSuchMethodError: 
org.apache.wicket.MetaDataKey.init(Ljava/lang/Class;)V


org.apache.wicket.security.log.AuthorizationErrorKey.init(AuthorizationErrorKey.java:41)

org.apache.wicket.security.strategies.WaspAuthorizationStrategy.clinit(WaspAuthorizationStrategy.java:57)

org.apache.wicket.security.swarm.strategies.SwarmStrategyFactory.newStrategy(SwarmStrategyFactory.java:80)
org.apache.wicket.security.WaspSession.init(WaspSession.java:48)

org.apache.wicket.security.WaspWebApplication.newSession(WaspWebApplication.java:71)
org.apache.wicket.Session.findOrCreate(Session.java:231)
org.apache.wicket.Session.findOrCreate(Session.java:214)
org.apache.wicket.Session.get(Session.java:253)
org.apache.wicket.RequestCycle.getSession(RequestCycle.java:436)

org.apache.wicket.request.AbstractRequestCycleProcessor.resolveHomePageTarget(AbstractRequestCycleProcessor.java:315)

org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:159)
org.apache.wicket.RequestCycle.step(RequestCycle.java:1246)
org.apache.wicket.RequestCycle.steps(RequestCycle.java:1366)
org.apache.wicket.RequestCycle.request(RequestCycle.java:499)

org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:387)

org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:199)



and 1.3.0:


java.lang.NoSuchMethodError: 
org.apache.wicket.MetaDataKey.init(Ljava/lang/Class;)V

org.apache.wicket.security.checks.WaspKey.init(WaspKey.java:41)

org.apache.wicket.security.components.SecureComponentHelper.getSecurityCheck(SecureComponentHelper.java:55)

org.apache.wicket.security.strategies.WaspAuthorizationStrategy.getSecurityCheck(WaspAuthorizationStrategy.java:185)

org.apache.wicket.security.strategies.WaspAuthorizationStrategy.isActionAuthorized(WaspAuthorizationStrategy.java:159)
org.apache.wicket.Component.isActionAuthorized(Component.java:1983)
org.apache.wicket.Page.renderPage(Page.java:855)

org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.respond(BookmarkablePageRequestTarget.java:241)

org.apache.wicket.request.AbstractRequestCycleProcessor.respond(AbstractRequestCycleProcessor.java:104)

org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1194)
org.apache.wicket.RequestCycle.step(RequestCycle.java:1265)
org.apache.wicket.RequestCycle.steps(RequestCycle.java:1366)
org.apache.wicket.RequestCycle.request(RequestCycle.java:499)

org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:387)

org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:199)



Is there any workaround Maurice?

Best,

Korbinian

Re: About the coupling between design and code

[Korbinian Bachl - privat]

Hello Radev,

 I've also developed some applications with Lotus, and there the 
abstraction
 between the design and the code is bound only by the name of the 
elements.

 There is no need to know anything about nesting of the elements. Such
 decoupling between the design and code could make the process of 
development

 more parallel and rapid.


that sounds interesting to me. Can you post some examples how it goes 
within Lotus?


Best,

Korbinian

Re: Id on Components

[Korbinian Bachl - privat]

Thanks for clear answer; In case i I add a feature request: would it 
even be possible to change the Id at a later time?


I catch me regularly to add Components like Links, Panels etc. to a 
ListComponent and have them rendered later on to different Markups in 
different ListViews - and that means I need to hold them in sync 
regarding their id;


And another feature request idea: would it be OK to add a synonym for 
wicket:id= e.g.: w:id= or even only :id= ? Would be some less 
typing :)


Best,

Korbinian



Matej Knopp schrieb:

 short question: Why isn't it possible to have a setId(String id) on the 
components?

short anwer:

- Is it really necessary that they know their id at  creation-time?

yes

-Matej

 Regards,

 Korbinian

Re: Id on Components

[Korbinian Bachl - privat]

great News!

Thx,

Korbinian

Johan Compagner schrieb:

Configuring the prefix wicket  is something on my todo for 1.5

On 4/12/08, Korbinian Bachl - privat [EMAIL PROTECTED] wrote:

Thanks for clear answer; In case i I add a feature request: would it
even be possible to change the Id at a later time?

I catch me regularly to add Components like Links, Panels etc. to a
ListComponent and have them rendered later on to different Markups in
different ListViews - and that means I need to hold them in sync
regarding their id;

And another feature request idea: would it be OK to add a synonym for
wicket:id= e.g.: w:id= or even only :id= ? Would be some less
typing :)

Best,

Korbinian



Matej Knopp schrieb:

 short question: Why isn't it possible to have a setId(String id) on the

components?

short anwer:

- Is it really necessary that they know their id at  creation-time?

yes

-Matej

 Regards,

 Korbinian

Re: Id on Components

[Korbinian Bachl - privat]

Hi Martijn,

ok, if it so wrong then how to better solve this situation:

Goal: Generic Suckerfish drop Down with Multiple levels, usable for 
Bookmarkable,Page + AjaxLinks etc.;


My Solution: 1 Panel holding outer Markup, inheriting a TreePanel;
Links are injected using a ListLinkListItem;
while LinkListItem has:
public LinkListItem(String label, AbstractLink link, ListLinkListItem 
sublist)


I thought of about a dozen tings, but I couldnt find a way to supply a 
LinkListItem where not to send a Link through, as links either want a 
class (Bookmarkable + Page) or a onClick (usual Link) and the Ajax 
target onClick(target);


How would you then solve this not sending the components?

Best,

Korbinian


Martijn Dashorst schrieb:

you should not re use a component instance in your component
hierarchy. That is *so* wrong. e.g. creating a panel outside a
listview's onpopulate and adding it to the listitem?

Martijn

On 4/12/08, Korbinian Bachl - privat [EMAIL PROTECTED] wrote:

Thanks for clear answer; In case i I add a feature request: would it even be
possible to change the Id at a later time?

 I catch me regularly to add Components like Links, Panels etc. to a
ListComponent and have them rendered later on to different Markups in
different ListViews - and that means I need to hold them in sync regarding
their id;

 And another feature request idea: would it be OK to add a synonym for
wicket:id= e.g.: w:id= or even only :id= ? Would be some less typing
:)

 Best,

 Korbinian



 Matej Knopp schrieb:



 short question: Why isn't it possible to have a setId(String id) on the

components?

short anwer:


- Is it really necessary that they know their id at  creation-time?


yes

-Matej


 Regards,

 Korbinian

Re: Id on Components

[Korbinian Bachl - privat]

Hi Matej,

sorry for this noobish question, but could you please give me an example 
of your factories idea?


Best,

Korbinian

Matej Knopp schrieb:

On Sat, Apr 12, 2008 at 10:24 AM, Korbinian Bachl - privat
[EMAIL PROTECTED] wrote:

Thanks for clear answer; In case i I add a feature request: would it even be
possible to change the Id at a later time?

No.

-Matej

longer answer: There are many ways to get wicket to do what you want.
Changing the component id is the worst of them. It's dangerous and
unnecessary. Instead of storing wicket components you can just store
factories.


 I catch me regularly to add Components like Links, Panels etc. to a
ListComponent and have them rendered later on to different Markups in
different ListViews - and that means I need to hold them in sync regarding
their id;

 And another feature request idea: would it be OK to add a synonym for
wicket:id= e.g.: w:id= or even only :id= ? Would be some less typing
:)

 Best,

 Korbinian



 Matej Knopp schrieb:




 short question: Why isn't it possible to have a setId(String id) on the

components?

short anwer:


- Is it really necessary that they know their id at  creation-time?


yes

-Matej


 Regards,

 Korbinian

Id on Components

[Korbinian Bachl - privat]

Hi,

short question: Why isn't it possible to have a setId(String id) on the 
components? - Is it really necessary that they know their id at 
creation-time?


Regards,

Korbinian

ModalWindow + Submit

[Korbinian Bachl - privat]

Hello,

I've noticed that a Form inside a ModalWindow can't be submitted using 
the onSubmit function (and dislikes a standard submit button) but 
instead requires an AjaxButton to call the action - why is this so? It 
makes my life currently somehow hard as I need 2 nearly identical forms 
- one with AjaxButton (in case I want to use it in  ModalWindow), one 
without AjaxButton for non JS pages.


Also I noticed a strage behaviour:

when using ModalWindow with a Page we have the pageConstructor() that 
creates a whole new page (all models are fresh) when opening it, while 
in case you use it with a Panel/ Component the component is created just 
once and Models arent cleaned up in case you close the window and reopen 
it (e.g.: a form you put in and submit and close window and reopen it 
using initial link displays the submited values) - opposite behaviour 
compared to ModalWindow with Page where on each creation all is cleaned.


Best,

Korbinian

Re: ModalWindow + Submit

[Korbinian Bachl - privat]

Hi Nino,


Why not use the panel directly?

I use panels for my modal window and it works fine:)

I meant this:
|myformPanel
|
|-myformPanelWithAjaxSubmitANDModalAware
|-myformPanelWithNormalButton


so you have a Panel holding the Form and extend this then to hold the 
right submitter then? I mean this would go to 3 Java + 3 HTML files for 
1 form, seems a bit much on the long run for me.




And this for displaying:
   AjaxLink popupLink = new AjaxLink(manageWeightPop) {
   @Override
   public void onClick(AjaxRequestTarget target) {
   target
   
.appendJavascript(Wicket.Window.unloadConfirmation = false;);

   modalWindow.setTitle(Weight Log.);
   modalWindow.setMinimalHeight(700);
   modalWindow.setContent(new ManageWeightPanel(modalWindow
   .getContentId(), modalWindow,
   new BaseEntityDetachableModel(getPerson(;
   modalWindow.show(target);
   }
   };


youre creating a modalWindow here directly using JS? Or where do you 
create it?


Im currently creating a final ModalWindow and attaching it to a fixed 
div while calling it:

 final ModalWindow mw = new ModalWindow(mw);
EigenschaftenFormPanel ep = new 
EigenschaftenFormPanel(mw.getContentId(), new Eigenschaften());

ep.setWindow(mw);
mw.setContent(ep);
mw.setInitialHeight(140);
mw.setResizable(false);

add(new AjaxLink(showmw)
{
public void onClick(AjaxRequestTarget target)
{
mw.show(target);
}
});

Is this the right usage then?

Best,

Korbinian




regards Nino

Maurice Marrink wrote:

I think it would be even better to wrap the panel nino is talking
about in a new page for your modal window.

Maurice

On Tue, Apr 8, 2008 at 2:59 PM, Nino Saturnino Martinez Vazquez Wael
[EMAIL PROTECTED] wrote:
 

 Korbinian Bachl - privat wrote:

   

Hello,

I've noticed that a Form inside a ModalWindow can't be submitted 
using the
  

onSubmit function (and dislikes a standard submit button) but instead
requires an AjaxButton to call the action - why is this so? It makes 
my life

currently somehow hard as I need 2 nearly identical forms - one with
AjaxButton (in case I want to use it in  ModalWindow), one without
AjaxButton for non JS pages.
   
  
 Because of the server round trip I think.. Why not have one panel, 
which

contains your form and then two childs, which adds the submit part eg a
submit link etc...



   

Also I noticed a strage behaviour:

when using ModalWindow with a Page we have the pageConstructor() that
  
creates a whole new page (all models are fresh) when opening it, 
while in
case you use it with a Panel/ Component the component is created just 
once

and Models arent cleaned up in case you close the window and reopen it
(e.g.: a form you put in and submit and close window and reopen it using
initial link displays the submited values) - opposite behaviour 
compared to

ModalWindow with Page where on each creation all is cleaned.
   

Best,

Korbinian








  

 --
 -Wicket for love

 Nino Martinez Wael
 Java Specialist @ Jayway DK
 http://www.jayway.dk
 +45 2936 7684