Re: Apache Committers

[Michael Mosmann]

.. ah.. this was easy:)

Am 09.12.22 um 23:51 schrieb Tobias Soloschenko:

Hey again,

I joined the infra team slack channel and got the answer. You need to:

1. Add 2fa to your GitHub account
2. Log in to https://gitbox.apache.org/boxer/ with your ASF id and follow the 
instructions

That’s all.

kind regards

Tobias

Apache Committers

[Michael Mosmann]

Hi,

I got this message today:

> You’ve been removed from the "Apache Committers" team on the "The
> Apache Software Foundation" organization.
>
> Cheers & Octocats,
> GitHub Support

I guess this is not a spam message... and as my last commit is long ago 
this is the right step to do:)


so have fun and nice pre christmas day:) (still reading wicket related 
mailing lists)



Michael Mosmann:)

Re: The day Wicket became Apache Wicket 10 years ago!

[Michael Mosmann]

Wooohooo:)


Am 19. Juni 2017 9:19:03 nachm. schrieb Martijn Dashorst 
:



Today marks the date 10 years ago that the Wicket project graduated from
the Incubator to a fully fledged Apache project.

The time flies when you're having fun!

I would like to thank all our community members for their continued support
and usage of Apache Wicket and pour one out for you!

Here's a big Thank You for everyone reading this message, asking and
answering questions, using Wicket in their projects and a special :beer:
for all contributors to Wicket, past and present! Here's to another 10
years!

Martijn Dashorst

Re: [VOTE] Proposal to remove IDetachable from IModel hierarchy

[Michael Mosmann]

[X] No, keep IModel detachable.

.. i did once a refactoring to build an IReadonlyModel,and failed. I failed 
because of the limited feature set of the java language. So you will end up 
with some kind of compromise,which is not near a perfect solution.


Maybe there is a much better way to handle this leaky request/response 
abstraction... But IMHO removing IDetachable will not be a step in this 
direction.


Michael:)

Mit AquaMail Android
http://www.aqua-mail.com gesendet


Am 4. April 2017 5:25:05 vorm. schrieb Pedro Santos :


Hi

Emond,


TL;DR Vote at the bottom


What does it mean? That your email can be skipped to the voting part or
that I was prolix in my last email?


I think we are not going to agree on this proposal.


No problem. Having different opinions being discussed is just a sign of a
healthy project.

Carl,

Indeed, and it's really nice to get you option on this. I also see this as
a tradeoff situation.

Martijn,


models only live during
actual request processing


They live longer. They even implement IClusterable (IDetachable's
superinterface) to do so. IClusterable being IDetachable's superinterface
is a living paradox for me.

[x] Yes, remove IDetachable from IModel


Pedro Santos

On Mon, Apr 3, 2017 at 10:49 AM, Martijn Dashorst <
martijn.dasho...@gmail.com> wrote:


While I appreciate the effort in questioning our fundamentals and
trying to improve even the oldest parts of our API, I don't think that
the detach method is semantically wrong for models. Semantics are
defined by what we say the semantics are. In a request/response
oriented environment a detach is an essential part of the lifecycle of
a request in general, and for models in particular.

Were Wicket a Swing framework, I would consider modifying the API, but
as Wicket lives in an environment where the models only live during
actual request processing, and are literally detached otherwise,
IModel implementations should have detach behavior, and therefore the
framework must guarantee that it can call the detach logic at
appropriate times. Therefore IModels *are* IDetachable.

So I don't think we should remove IDetachable from IModel as it is an
essential, integral and semantically correct part of models.

[X] No, keep IModel detachable.

Martijn


On Mon, Apr 3, 2017 at 9:38 AM, Emond Papegaaij
 wrote:
> Something went wrong sending this mail. I did write some more, but
somehow my
> mail client lost it. So here's the vote again:
>
> I think we are not going to agree on this proposal. I think it is not an
> improvement and I do not agree with you that IModel should not be
> detachable by default. So lets vote on this.
>
> [ ] Yes, remove IDetachable from IModel
> [ ] No, keep IModel detachable
>
> My vote:
> -1 keep IModel detachable
>
> Best regards,
> Emond
>
>



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

Re: Christmas / new year [NON-BIZ]

[Michael Mosmann]

Merry Christmas:)

Mit AquaMail Android
http://www.aqua-mail.com gesendet


Am 24. Dezember 2016 2:46:34 nachm. schrieb Martin Grigorov 
:



Merry Christmas !

On Dec 24, 2016 1:33 PM, "Tobias Soloschenko" <
tobiassolosche...@googlemail.com> wrote:

Hi all,

I wish you a merry christmas and happy new year. :-)

kind regards

Tobias

Re: Wicket & Java8

[Michael Mosmann]

moving code from java7 to java8 gives a lot of surprising compilation errors..  
and IMHO the compiler should report an error if the developer might expect 
different behavior ... As far as i understand the answers in this bug report, 
the compiler is "happy" with a first match .. But should IMHO throw an error...

Am 17. April 2016 18:43:50 MESZ, schrieb Sebastien :
>Hi Martin & devs,
>
>So here we are (sorry for the delay, I haven't been notified) :
>http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8151584
>
>Not sure I'm agreeing on the reason that it's "not a bug", but I don't
>want
>to be sarcastic...
>Actually, the guy kindly provides a complete answer I have to analyse
>(and
>probably use).
>
>Best regards,
>Sebastien.
>
>On Sun, Feb 28, 2016 at 8:00 PM, Sebastien  wrote:
>
>> I've submitted the issue to the oracle community
>> The ticket is under review, I will post the link to the bug once
>approved.
>>
>>

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

Re: Lambda branch

[Michael Mosmann]

oh.. sorry.. got it..
You hat to use BiConsumer for set functions..

mm:)

Am 02.12.2015 um 08:53 schrieb Michael Mosmann:
> Hi,
> 
> 
> 
> Some first thoughts on this..
> 
> If we want to use lambdas for some kind of property model, the straight
> forward way of doing this looks like:
> 
> SomeBean instance=new SomeBean();
> IModel model=Models.of(instance::getName,instance.setName);
> 
> But this will not work, if you have
> 
> IModel instanceModel=...;
> 
> So then we could use:
> IModel model=Models.of(instanceModel, x-> x.getName() ,(x,v) ->
> x.setName(v));
> 
> It is sad, that there is no way to get some kind of instance method
> reference in java8.
> 
> What i would like to write is something like this:
> 
> IModel model=Models.of(instanceModel, SomeBean::getName
> ,SomeBean::setName); // does not compile
> 
> IMHO the correct way to solve this looks a little strange, but is from
> my point of view more consistent...
> 
> IModel model=Models.of(instanceModel, x -> x::getName, x ->
> x::setName)
> 
> the Method looks like this:
> 
> public <T,V> of(IModel model, Function<T, Supplier> getter,
> Function<T, Consumer> setter);
> 
> (* where Function, Supplier and Consumer must extends Serializable)
> 
> am i wrong? did i miss something? because i am far from happy with this..
> 
> mm:)
> 
> 
> Am 01.12.2015 um 12:45 schrieb andrea del bene:
>>
>>
>> Ok, I'd like to play too :) ...
>>> AFAIK we're still playing with lambdas. I still have a message I need
>>> to send to dev@ regarding lambdas...
>>>
>>> Martijn
>>>
>>>
>>> On Mon, Nov 30, 2015 at 3:57 PM, Michael Mosmann <mich...@mosmann.de>
>>> wrote:
>>>> Hi,
>>>>
>>>> AFAIK not.. I thought it is something like a playground. Am i wrong?
>>>>
>>>> Michael
>>>>
>>>> Am 30. November 2015 15:47:42 MEZ, schrieb andrea del bene
>>>> <an.delb...@gmail.com>:
>>>>> Hi,
>>>>>
>>>>> are we tracking changes to lambda branch with issues on JIRA?
>>>>>
>>>>> Andrea.
>>>> -- 
>>>> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail
>>>> gesendet.
>>>
>>>
>>
> 

Re: Lambda branch

[Michael Mosmann]

Hi,

.. got it. Was on a wrong track:)

We must use BiConsumer for setter-like methods..

mm:)

Am 02.12.2015 um 09:39 schrieb Sven Meier:
> Hi,
> 
>> It is sad, that there is no way to get some kind of instance method
>> reference in java8.
> 
> instance::getName *is* an instance method reference.
> 
>> IModel model=Models.of(instanceModel, SomeBean::getName
>> ,SomeBean::setName); // does not compile
> 
> org.wicketstuff.lambda.model.LambdaModel works fine, so what does not
> compile in your example?
> 
> Did I miss something? :P
> 
> Sven
> 
> 
> On 02.12.2015 08:53, Michael Mosmann wrote:
>> Hi,
>>
>>
>>
>> Some first thoughts on this..
>>
>> If we want to use lambdas for some kind of property model, the straight
>> forward way of doing this looks like:
>>
>> SomeBean instance=new SomeBean();
>> IModel model=Models.of(instance::getName,instance.setName);
>>
>> But this will not work, if you have
>>
>> IModel instanceModel=...;
>>
>> So then we could use:
>> IModel model=Models.of(instanceModel, x-> x.getName() ,(x,v) ->
>> x.setName(v));
>>
>> It is sad, that there is no way to get some kind of instance method
>> reference in java8.
>>
>> What i would like to write is something like this:
>>
>> IModel model=Models.of(instanceModel, SomeBean::getName
>> ,SomeBean::setName); // does not compile
>>
>> IMHO the correct way to solve this looks a little strange, but is from
>> my point of view more consistent...
>>
>> IModel model=Models.of(instanceModel, x -> x::getName, x ->
>> x::setName)
>>
>> the Method looks like this:
>>
>> public <T,V> of(IModel model, Function<T, Supplier> getter,
>> Function<T, Consumer> setter);
>>
>> (* where Function, Supplier and Consumer must extends Serializable)
>>
>> am i wrong? did i miss something? because i am far from happy with this..
>>
>> mm:)
>>
>>
>> Am 01.12.2015 um 12:45 schrieb andrea del bene:
>>>
>>>
>>> Ok, I'd like to play too :) ...
>>>> AFAIK we're still playing with lambdas. I still have a message I need
>>>> to send to dev@ regarding lambdas...
>>>>
>>>> Martijn
>>>>
>>>>
>>>> On Mon, Nov 30, 2015 at 3:57 PM, Michael Mosmann <mich...@mosmann.de>
>>>> wrote:
>>>>> Hi,
>>>>>
>>>>> AFAIK not.. I thought it is something like a playground. Am i wrong?
>>>>>
>>>>> Michael
>>>>>
>>>>> Am 30. November 2015 15:47:42 MEZ, schrieb andrea del bene
>>>>> <an.delb...@gmail.com>:
>>>>>> Hi,
>>>>>>
>>>>>> are we tracking changes to lambda branch with issues on JIRA?
>>>>>>
>>>>>> Andrea.
>>>>> -- 
>>>>> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail
>>>>> gesendet.
>>>>
>>>>
>>>
>>

Re: Lambda branch

[Michael Mosmann]

Hi,



Some first thoughts on this..

If we want to use lambdas for some kind of property model, the straight
forward way of doing this looks like:

SomeBean instance=new SomeBean();
IModel model=Models.of(instance::getName,instance.setName);

But this will not work, if you have

IModel instanceModel=...;

So then we could use:
IModel model=Models.of(instanceModel, x-> x.getName() ,(x,v) ->
x.setName(v));

It is sad, that there is no way to get some kind of instance method
reference in java8.

What i would like to write is something like this:

IModel model=Models.of(instanceModel, SomeBean::getName
,SomeBean::setName); // does not compile

IMHO the correct way to solve this looks a little strange, but is from
my point of view more consistent...

IModel model=Models.of(instanceModel, x -> x::getName, x ->
x::setName)

the Method looks like this:

public <T,V> of(IModel model, Function<T, Supplier> getter,
Function<T, Consumer> setter);

(* where Function, Supplier and Consumer must extends Serializable)

am i wrong? did i miss something? because i am far from happy with this..

mm:)


Am 01.12.2015 um 12:45 schrieb andrea del bene:
> 
> 
> Ok, I'd like to play too :) ...
>> AFAIK we're still playing with lambdas. I still have a message I need
>> to send to dev@ regarding lambdas...
>>
>> Martijn
>>
>>
>> On Mon, Nov 30, 2015 at 3:57 PM, Michael Mosmann <mich...@mosmann.de>
>> wrote:
>>> Hi,
>>>
>>> AFAIK not.. I thought it is something like a playground. Am i wrong?
>>>
>>> Michael
>>>
>>> Am 30. November 2015 15:47:42 MEZ, schrieb andrea del bene
>>> <an.delb...@gmail.com>:
>>>> Hi,
>>>>
>>>> are we tracking changes to lambda branch with issues on JIRA?
>>>>
>>>> Andrea.
>>> -- 
>>> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail
>>> gesendet.
>>
>>
> 

Re: Lambda branch

[Michael Mosmann]

Hi,

AFAIK not.. I thought it is something like a playground. Am i wrong?

Michael

Am 30. November 2015 15:47:42 MEZ, schrieb andrea del bene 
:
>Hi,
>
>are we tracking changes to lambda branch with issues on JIRA?
>
>Andrea.

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

Re: [wicket8] Lambdas everywhere (just models for now)

[Michael Mosmann]

Hi,

.. did some further testing .. and got this conclusion. AFAIK you can
not have something like

   & Serializable,S,D> foo(X func)

and expect the compiler doing the magic on this code

  foo(x -> x+1)

.. you must use a cast, so you have to write

 foo((Function<Integer,Integer> & Serializable) x -> x+1)

which gives no benefit over using something like our own Interface
extending Function, Supplier etc.

maybe i am wrong...

michael:)

Am 10.10.2015 um 12:01 schrieb Michael Mosmann:
> Hi,
> 
> ... if we using SerializableFunction instead of Function & Serializable,
> it will work. Works well with Wicket 7.0.0 on java8 (tested).
> 
> Michael
> 
> Am 07.10.2015 um 10:26 schrieb Jonas:
>> We experimented with lambda based IModels when Java 8 was released. Bottom
>> line was that serializable Lambdas are quite a problem. Both javac and ecj
>> had (and probably still have) lots of bugs related to serializable lambdas.
>> Another problematic area was obfuscation. There wasn't any easy way to let
>> proguard handle lambda based IModels without actually excluding all those
>> classes from obfuscation. This was what made us finally abandon the idea of
>> lambda based IModels, at least for now.
>>
>> cheers,
>> Jonas
>>
>>
>> On Tue, Oct 6, 2015 at 11:55 PM, Michael Mosmann <mich...@mosmann.de> wrote:
>>
>>> Maybe this is useful:
>>> https://github.com/flapdoodle-oss/de.flapdoodle.wicket/blob/master/models/src/test/java/de/flapdoodle/wicket/model/TestModelTransformations.java
>>> .. The model code should work with java8 and lambdas...
>>>
>>> Mm:)
>>>
>>> Am 6. Oktober 2015 23:37:34 MESZ, schrieb Michael Mosmann <
>>> mich...@mosmann.de>:
>>>> I am not sure about the generic stuff... If you write only lamdas there
>>>> will be no issue..but if you reuse some code, there could be some need
>>>> of 'super' in it..
>>>>
>>>> But that's nothing i can build in my mind.. I need something like
>>>> eclipse to make it right. So maybe next week.. :)
>>>>
>>>> Mm:)
>>>>
>>>>
>>>> Am 6. Oktober 2015 22:48:32 MESZ, schrieb Martin Grigorov
>>>> <mgrigo...@apache.org>:
>>>>> /me likes !!!
>>>>>
>>>>> Once it is buildable with javac:
>>>>>
>>>>> *) Since it doesn't need changes in any of the current Wicket classes
>>>> I
>>>>> think it could be added to WicketStuff 7.x and battle tested until
>>>>> Wicket
>>>>> 8.0.0 is out.
>>>>>
>>>>> *) What is the purpose of WriteOnlyModel?
>>>>> My concern is that Wicket will fail every time such model is used in a
>>>>> component when this component is being rendered.
>>>>>
>>>>> *) I think you have to name some of the methods #map and #flatMap, and
>>>>> add
>>>>> "Monad" somewhere in the javadoc. Just to make it more fancy :-)
>>>>>
>>>>> Martin Grigorov
>>>>> Wicket Training and Consulting
>>>>> https://twitter.com/mtgrigorov
>>>>>
>>>>> On Tue, Oct 6, 2015 at 11:15 AM, Martijn Dashorst <
>>>>> martijn.dasho...@gmail.com> wrote:
>>>>>
>>>>>> I've created a Lambdas class that compiles just fine in ECJ but
>>>> fails
>>>>>> using javac.
>>>>>>
>>>>>> https://gist.github.com/dashorst/da876be2f01770e862a5
>>>>>>
>>>>>> The benefit of this way is that we don't perpetuate SerializableFoo
>>>>>> (Foo==[Function, Consumer, Predicate, Supplier, ...]) but instead
>>>>>> require that the passed in stuff is in fact serializable.
>>>>>>
>>>>>> This way companies that have their own SerializableFunction et al,
>>>>> kan
>>>>>> pass those references into our Lambda models.
>>>>>>
>>>>>> Unfortunately this is currently way beyond the capabilities of
>>>> javac.
>>>>>>
>>>>>> Check out the code above (the signature is quite hard to read, but
>>>> in
>>>>>> use it is awesome, just use Eclipse 4.5.1)
>>>>>>
>>>>>> Martijn
>>>>>>
>>>>>> --
>>>>>> Become a Wicket expert, learn from the best:
>>>>> http://wicketinaction.com
>>>>>>
>>>>
>>>> --
>>>> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail
>>>> gesendet.
>>>
>>> --
>>> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail
>>> gesendet.
>>>
>>
> 

Re: [wicket8] Use default method for IModel#detach()?

[Michael Mosmann]

.. @IReadOnlyModel: i hope, it will be easier to change then the last time i 
tried it. Watch out for component default model stuff...

:)

Am 6. Oktober 2015 22:54:37 MESZ, schrieb Martin Grigorov 
:
>On Tue, Oct 6, 2015 at 10:43 PM, Andrew Geery 
>wrote:
>
>> If IModel were a @FunctionalInterface, then you wouldn't need
>something
>> like a SupplierModel; you could just use a lambda directly:
>>
>> new Label("label", () -> "The current time is " + LocalDate.now());
>>
>
>This looks good indeed.
>It seems we will add IReadOnlyModel soon!
>
>
>>
>> And since IModel is Serializable, the lambda will be too, without
>having to
>> have an artificial interface that is both Serializable & a Supplier.
>>
>> Thanks
>> Andrew
>>
>> On Tue, Oct 6, 2015 at 4:21 PM, Martin Grigorov
>
>> wrote:
>>
>> > Same for IRequestHandler#detach()
>> >
>> > Martin Grigorov
>> > Wicket Training and Consulting
>> > https://twitter.com/mtgrigorov
>> >
>> > On Mon, Oct 5, 2015 at 10:42 PM, Martijn Dashorst <
>> > martijn.dasho...@gmail.com> wrote:
>> >
>> > > Should we use an empty default implementation for IModel#detach?
>> > >
>> > >
>> > > public class IModel extends IDetachable
>> > > {
>> > > ...
>> > >
>> > > @Override
>> > > default void detach()
>> > > {
>> > > }
>> > > }
>> > >
>> > > This won't break existing applications, but might make it a bit
>easier
>> > > on the eyes to implement IModel directly.
>> > >
>> > > I'm not in favor of applying the default method to IDetachable,
>> > > because that would defeat the interface's purpose IMO.
>> > >
>> > > WDYT?
>> > >
>> > > Martijn
>> > >
>> >
>>

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

Re: [wicket8] Lambdas everywhere (just models for now)

[Michael Mosmann]

Maybe this is useful: 
https://github.com/flapdoodle-oss/de.flapdoodle.wicket/blob/master/models/src/test/java/de/flapdoodle/wicket/model/TestModelTransformations.java
 .. The model code should work with java8 and lambdas... 

Mm:)

Am 6. Oktober 2015 23:37:34 MESZ, schrieb Michael Mosmann <mich...@mosmann.de>:
>I am not sure about the generic stuff... If you write only lamdas there
>will be no issue..but if you reuse some code, there could be some need
>of 'super' in it..
>
>But that's nothing i can build in my mind.. I need something like
>eclipse to make it right. So maybe next week.. :)
>
>Mm:)
>
>
>Am 6. Oktober 2015 22:48:32 MESZ, schrieb Martin Grigorov
><mgrigo...@apache.org>:
>>/me likes !!!
>>
>>Once it is buildable with javac:
>>
>>*) Since it doesn't need changes in any of the current Wicket classes
>I
>>think it could be added to WicketStuff 7.x and battle tested until
>>Wicket
>>8.0.0 is out.
>>
>>*) What is the purpose of WriteOnlyModel?
>>My concern is that Wicket will fail every time such model is used in a
>>component when this component is being rendered.
>>
>>*) I think you have to name some of the methods #map and #flatMap, and
>>add
>>"Monad" somewhere in the javadoc. Just to make it more fancy :-)
>>
>>Martin Grigorov
>>Wicket Training and Consulting
>>https://twitter.com/mtgrigorov
>>
>>On Tue, Oct 6, 2015 at 11:15 AM, Martijn Dashorst <
>>martijn.dasho...@gmail.com> wrote:
>>
>>> I've created a Lambdas class that compiles just fine in ECJ but
>fails
>>> using javac.
>>>
>>> https://gist.github.com/dashorst/da876be2f01770e862a5
>>>
>>> The benefit of this way is that we don't perpetuate SerializableFoo
>>> (Foo==[Function, Consumer, Predicate, Supplier, ...]) but instead
>>> require that the passed in stuff is in fact serializable.
>>>
>>> This way companies that have their own SerializableFunction et al,
>>kan
>>> pass those references into our Lambda models.
>>>
>>> Unfortunately this is currently way beyond the capabilities of
>javac.
>>>
>>> Check out the code above (the signature is quite hard to read, but
>in
>>> use it is awesome, just use Eclipse 4.5.1)
>>>
>>> Martijn
>>>
>>> --
>>> Become a Wicket expert, learn from the best:
>>http://wicketinaction.com
>>>
>
>-- 
>Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail
>gesendet.

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

Re: [wicket8] Lambdas everywhere (just models for now)

[Michael Mosmann]

I am not sure about the generic stuff... If you write only lamdas there will be 
no issue..but if you reuse some code, there could be some need of 'super' in 
it..

But that's nothing i can build in my mind.. I need something like eclipse to 
make it right. So maybe next week.. :)

Mm:)


Am 6. Oktober 2015 22:48:32 MESZ, schrieb Martin Grigorov 
:
>/me likes !!!
>
>Once it is buildable with javac:
>
>*) Since it doesn't need changes in any of the current Wicket classes I
>think it could be added to WicketStuff 7.x and battle tested until
>Wicket
>8.0.0 is out.
>
>*) What is the purpose of WriteOnlyModel?
>My concern is that Wicket will fail every time such model is used in a
>component when this component is being rendered.
>
>*) I think you have to name some of the methods #map and #flatMap, and
>add
>"Monad" somewhere in the javadoc. Just to make it more fancy :-)
>
>Martin Grigorov
>Wicket Training and Consulting
>https://twitter.com/mtgrigorov
>
>On Tue, Oct 6, 2015 at 11:15 AM, Martijn Dashorst <
>martijn.dasho...@gmail.com> wrote:
>
>> I've created a Lambdas class that compiles just fine in ECJ but fails
>> using javac.
>>
>> https://gist.github.com/dashorst/da876be2f01770e862a5
>>
>> The benefit of this way is that we don't perpetuate SerializableFoo
>> (Foo==[Function, Consumer, Predicate, Supplier, ...]) but instead
>> require that the passed in stuff is in fact serializable.
>>
>> This way companies that have their own SerializableFunction et al,
>kan
>> pass those references into our Lambda models.
>>
>> Unfortunately this is currently way beyond the capabilities of javac.
>>
>> Check out the code above (the signature is quite hard to read, but in
>> use it is awesome, just use Eclipse 4.5.1)
>>
>> Martijn
>>
>> --
>> Become a Wicket expert, learn from the best:
>http://wicketinaction.com
>>

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

Re: Nice shout out by Uncle Bob Martin

[Michael Mosmann]

As uncle bobs selling point is his way to insult others as idiot, you
should be aware of his own .. ehm .. very special ideas
(http://fitnesse.org/FitNesse.UserGuide.TwoMinuteExample).

It is easy to talk about the wrong things others did.. but its is hard,
do do things right.

Long story short: I don't like him. He has some good points, but also
often IMHO he has not.

He will never be a zen-TDD-master. He is more of a TDD-dictator of our
time:)

Michael


Am 08.09.2015 um 15:28 schrieb Andrea Del Bene:
> Glad to disgust him :-)
> 
> On Tue, Sep 8, 2015 at 2:55 PM, Francois Meillet > wrote:
> 
>> Uncle Bob
>> http://www.objectmentor.com/omTeam/martin_r.html
>> https://en.wikipedia.org/wiki/Robert_Cecil_Martin
>>
>>
>> François
>>
>>
>>
>>
>>
>>
>>
>>
>> Le 8 sept. 2015 à 14:52, Sebastien  a écrit :
>>
>>> I like the presentation! :)
>>> (just, the last slide is not the slide he's talking on...)
>>>
>>> Tobias, good question!
>>>
>>>
>>>
>>> On Tue, Sep 8, 2015 at 2:42 PM, Tobias Soloschenko <
>>> tobiassolosche...@googlemail.com> wrote:
>>>
 Who is uncle bob? ;-)

 kind regards

 Tobias

> Am 08.09.2015 um 14:23 schrieb Martijn Dashorst <
 martijn.dasho...@gmail.com>:
>
> https://youtu.be/0oGpWmS0aYQ?t=1117
>
> Of course we're listed as part of the horrible frameworks of yore...
> Feels great to not be left out!
>
> Martijn
>
> --
> Become a Wicket expert, learn from the best: http://wicketinaction.com

>>
>>
> 

Re: [VOTE] Release wicket-eclipse-settings 1

[Michael Mosmann]

+1 release it

Am 13.03.2015 um 09:15 schrieb Martijn Dashorst:
 This is a vote to release the wicket-eclipse-settings version 1.

 Wicket Eclipse Settings is a project to specify Eclipse settings for a
 uniform development environment between all Eclipse using Wicket Team
 members. Most notably the formatting rules.

 [ ] Yes, release it!
 [ ] No, don't release it!

 The staging repository:

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

 This is the initial release which has copied the original formatter
 file from our repository and put it in a jar.

 Martijn

web framework benchmarks

[Michael Mosmann]

an other framework speed benchmarks ..

http://www.techempower.com/benchmarks/#section=data-r9hw=peaktest=json

wicket is not so bad..
but such kind of benchmarks are not as useful as it might sound..

Michael:)

Re: web framework benchmarks

[Michael Mosmann]

Ah..
.. if I had more time..

every time I am very impressed about the lot of stuff you are doing..

mm:)

Am 20.08.2014 um 16:17 schrieb Martin Grigorov:
 it is open source, you can help to make it better -
 https://github.com/TechEmpower/FrameworkBenchmarks
 for the next round I've removed the usage of Hibernate for DB operations
 and use plain JDBC. On my machine this made an improvement with 40%

 there is a lot of work going on on improving the validation process for the
 Pull Requests. Hopefully soon they will be able to run the tests more often
 and add more use cases

 Martin Grigorov
 Wicket Training and Consulting
 https://twitter.com/mtgrigorov


 On Wed, Aug 20, 2014 at 5:00 PM, Michael Mosmann mich...@mosmann.de wrote:

 an other framework speed benchmarks ..

 http://www.techempower.com/benchmarks/#section=data-r9hw=peaktest=json

 wicket is not so bad..
 but such kind of benchmarks are not as useful as it might sound..

 Michael:)

Re: refactoring IDataProvider interface

[Michael Mosmann]

I had some .. hmm.. comparable issues.. I solved this with something 
like this:


public interface SizedIterableT extends IterableT {

long size();
}

so you can ask the iterable about the size..

mm:)

Am 07.05.2014 00:05, schrieb tetsuo:

Yeah, you're right. By reflex, I was thinking Hibernate Session (with open
session in view), not JDBC Connection, since I don't work directly with it
very often. And even if it was Hibernate, and the session was still open,
the connection would also be closed anyway.

What methods would the Page interface (with another name, since we already
have a Page class) have? iterator() and size()?



“The truth is rarely pure and never simple.” ― Oscar Wilde


On Tue, May 6, 2014 at 5:41 PM, Leszek Gawron lgaw...@apache.org wrote:


I replied from wrong email, please excuse me if this reaches the list
twice.

On Tue, May 6, 2014 at 8:06 PM, tetsuo ronald.tet...@gmail.com wrote:

Since it's the same request, isn't (or couldn't be) the db connection the
same in size() and iterator() calls? If you created the temporary table

in

one, isn't it still available to the other (so you could avoid recreating
it)?

Well, the connection is being managed by spring transactional resource
management classes. A transaction is demarcated with
@Transactional(readOnly=true) on a particular method. All
transactional resources are bound to thread during transaction
execution and released when transaction finishes. One transactional
resource is of course a connection. I have extended this framework to
register temporary table names which are being automatically deleted
on transaction finish.

Each time you invoke a transactional method you perform following steps:
- acquire a connection from the pool
- bind connection to thread making all subsequent queries use same
connection
- start transaction
- do some work
- finish transaction (of course for read only there is nothing to be done)
- release transactional resources
- unbind connection from thread
- release connection to the pool.

using spring framework without spring managed transactions means you
end up using different connection for EVERY sql query.

My IDataProviders usually wrap spring bean with
@Transactional(readOnly=true) methods.

Unfortunatelly two method calls: size() and iterator() mean two
different transaction and two different connections. I am unable to
wrap any single point of entry with @Transactional - that probably
would have to be some generic Wicket method call. I cannot bind a
connection to current request thread preemptively because that would
mean a huge resource hog - I would have to obtain a connection from
pool for every request being made.

Temporary tables have connection scope so not deleting the table on
connection release means polluting the database server with lots of
temporary tables as long as connection stays in pool (which could be
indefinite).
The temporary tables would be probably stale all the time - any
ongoing transaction may probably alter what the temporary table should
contain.

Anyway any approach still feels like a hack and not resolving the
problem at source.



A single point of entry in IDataProvider:
- allows the user to manage resources more efficiently.
- gives user the option to resign from providing size() information -
do you really go from 1st to 15th page that often or do you usually
click next results?
- gives user the option to provide has more results information
without providing actual dataset size.

Having a single point of entry IDataSource means also you can do:

new IDataProviderSingleEntryT( oldDataProvider ) {
   public PageT getPage( long first, long count ) {
   return new PageImplT(
  oldDataProvider.interator( first, count ), oldDataProvider.size()
);
   }
}

This trivial decorator means IDataProviderSingleEntry and
IDataProvider may even coexist in wicket-core and wicket-extensions.
Some variation of this approach is actually used by inmethod-grid.
Maybe we could unify the way all pageables access resources.


--
Leszek Gawron

Re: Inefficient org.apache.wicket.pageStore.DefaultPageStore.SerializedPagesCache

[Michael Mosmann]

a.. got it..

https://github.com/apache/wicket/compare/master...5527-inefficient-DefaultDataStore

Am 11.03.14 13:55, schrieb Martin Grigorov:

Any comments on
https://github.com/apache/wicket/compare/5527-inefficient-DefaultDataStoreare
very welcome!

It should be relatively easy to roll custom impls based on
Guava/Hazelcast/... if needed/preferred.

Martin Grigorov
Wicket Training and Consulting


On Mon, Mar 10, 2014 at 9:55 AM, Martin Grigorov mgrigo...@apache.orgwrote:


I can see the benefits of adding dependency to Guava, but I can also see
many dependency conflicts caused by this.
Guava is not that strict in backward compatibility and this will lead to
problems like: an application depends on version X because of feature X1
and Wicket requires version Y that is incompatible.


On Fri, Mar 7, 2014 at 7:18 PM, Andrea Del Bene an.delb...@gmail.comwrote:


Having a flexible eviction policy would be nice, but if we decide to for
this way I would strongly recommend to NOT start implementing our own
cache solution. Instead, we should consider to adopt one of the existing
solutions (like Guava cache).

An additional consideration: what about getPage(String sessionId, int

pageId), should this also update the modification time (or maybe better:
„lastAccessTime“) of the returned page? Pages that are more frequently
requested maybe should be removed later from the cache …!?



Your suggestion would be much simpler to implement but the total size

of

this cache will be dynamic and will depend on the number of the active
sessions. But since this cache uses SoftReference for the values (the
pages) I think this won't be a problem.

We could have a (configurable) global limit for all cached pages in all

sessions, if that limit is reached, the least recently accessed/modified
page could be removed …


Cheers,
-Tom

Re: Inefficient org.apache.wicket.pageStore.DefaultPageStore.SerializedPagesCache

[Michael Mosmann]

Hi,

.. is the link correct?

mm:)

Am 11.03.14 13:55, schrieb Martin Grigorov:

Any comments on
https://github.com/apache/wicket/compare/5527-inefficient-DefaultDataStoreare
very welcome!

It should be relatively easy to roll custom impls based on
Guava/Hazelcast/... if needed/preferred.

Martin Grigorov
Wicket Training and Consulting


On Mon, Mar 10, 2014 at 9:55 AM, Martin Grigorov mgrigo...@apache.orgwrote:


I can see the benefits of adding dependency to Guava, but I can also see
many dependency conflicts caused by this.
Guava is not that strict in backward compatibility and this will lead to
problems like: an application depends on version X because of feature X1
and Wicket requires version Y that is incompatible.


On Fri, Mar 7, 2014 at 7:18 PM, Andrea Del Bene an.delb...@gmail.comwrote:


Having a flexible eviction policy would be nice, but if we decide to for
this way I would strongly recommend to NOT start implementing our own
cache solution. Instead, we should consider to adopt one of the existing
solutions (like Guava cache).

An additional consideration: what about getPage(String sessionId, int

pageId), should this also update the modification time (or maybe better:
„lastAccessTime“) of the returned page? Pages that are more frequently
requested maybe should be removed later from the cache …!?



Your suggestion would be much simpler to implement but the total size

of

this cache will be dynamic and will depend on the number of the active
sessions. But since this cache uses SoftReference for the values (the
pages) I think this won't be a problem.

We could have a (configurable) global limit for all cached pages in all

sessions, if that limit is reached, the least recently accessed/modified
page could be removed …


Cheers,
-Tom

Re: Inefficient org.apache.wicket.pageStore.DefaultPageStore.SerializedPagesCache

[Michael Mosmann]

Am 11.03.14 13:55, schrieb Martin Grigorov:

Any comments on
https://github.com/apache/wicket/compare/5527-inefficient-DefaultDataStoreare
very welcome!
Hmm.. SerializedPagesCache .. if one has many pages costs will go up.. 
but i am not sure, how big the cache will be in real life applications..

It should be relatively easy to roll custom impls based on
Guava/Hazelcast/... if needed/preferred.

yes.. it hast enought extension points in your version..

..
ok for me.. looks good:)

mm:)

Martin Grigorov
Wicket Training and Consulting


On Mon, Mar 10, 2014 at 9:55 AM, Martin Grigorov mgrigo...@apache.orgwrote:


I can see the benefits of adding dependency to Guava, but I can also see
many dependency conflicts caused by this.
Guava is not that strict in backward compatibility and this will lead to
problems like: an application depends on version X because of feature X1
and Wicket requires version Y that is incompatible.


On Fri, Mar 7, 2014 at 7:18 PM, Andrea Del Bene an.delb...@gmail.comwrote:


Having a flexible eviction policy would be nice, but if we decide to for
this way I would strongly recommend to NOT start implementing our own
cache solution. Instead, we should consider to adopt one of the existing
solutions (like Guava cache).

An additional consideration: what about getPage(String sessionId, int

pageId), should this also update the modification time (or maybe better:
„lastAccessTime“) of the returned page? Pages that are more frequently
requested maybe should be removed later from the cache …!?



Your suggestion would be much simpler to implement but the total size

of

this cache will be dynamic and will depend on the number of the active
sessions. But since this cache uses SoftReference for the values (the
pages) I think this won't be a problem.

We could have a (configurable) global limit for all cached pages in all

sessions, if that limit is reached, the least recently accessed/modified
page could be removed …


Cheers,
-Tom

Re: Inefficient org.apache.wicket.pageStore.DefaultPageStore.SerializedPagesCache

[Michael Mosmann]

ah.. ok. then this should work fine in most cases..
mm:)

Am 12.03.14 10:13, schrieb Martin Grigorov:

Thanks for the review, Michael!

SerializedPagesCache is the cache that is used in 6.14.0 with the problems
explained in the first mail in this thread.
Its initial max size is 40
(org.apache.wicket.settings.def.StoreSettings#DEFAULT_CACHE_SIZE).
That it it holds the last 40 used pages in the whole application (i.e. in
all http sessions).

The improvement is that it doesn't use an array (thru ArrayList) as a
backing store, so it is not fully reconstructed on every #remove operation,
and that now it is a concurrent data structure (ConcurrentLinkedDeque, Java
7 !) instead of a synchronized field.

The new impl - PerSessionPageStore again uses concurrent data structures
for its cache impl but it holds the last N pages per session, so even if
you set N to 1 your will have 10K cached pages if your have 10K active http
sessions.

The other difference is that PerSessionPageStore works with live page
instances while DefaultPageStore works with SerializedPage class, i.e. with
the byte[] view of a page. It does this to be prepared for http session
replication initiated by the web container, so there is no need of a second
serialization of the same page. (The first serialization is to store the
page in DiskDataStore).

Martin Grigorov
Wicket Training and Consulting


On Wed, Mar 12, 2014 at 10:56 AM, Michael Mosmann mich...@mosmann.dewrote:


Am 11.03.14 13:55, schrieb Martin Grigorov:


Any comments on
https://github.com/apache/wicket/compare/5527-inefficient-
DefaultDataStoreare
very welcome!


Hmm.. SerializedPagesCache .. if one has many pages costs will go up.. but
i am not sure, how big the cache will be in real life applications..

  It should be relatively easy to roll custom impls based on

Guava/Hazelcast/... if needed/preferred.


yes.. it hast enought extension points in your version..

..
ok for me.. looks good:)

mm:)

  Martin Grigorov

Wicket Training and Consulting


On Mon, Mar 10, 2014 at 9:55 AM, Martin Grigorov mgrigo...@apache.org

wrote:

  I can see the benefits of adding dependency to Guava, but I can also see

many dependency conflicts caused by this.
Guava is not that strict in backward compatibility and this will lead to
problems like: an application depends on version X because of feature X1
and Wicket requires version Y that is incompatible.


On Fri, Mar 7, 2014 at 7:18 PM, Andrea Del Bene an.delb...@gmail.com

wrote:

  Having a flexible eviction policy would be nice, but if we decide to for

this way I would strongly recommend to NOT start implementing our own
cache solution. Instead, we should consider to adopt one of the existing
solutions (like Guava cache).


An additional consideration: what about getPage(String sessionId, int


pageId), should this also update the modification time (or maybe better:
„lastAccessTime“) of the returned page? Pages that are more frequently
requested maybe should be removed later from the cache …!?


  Your suggestion would be much simpler to implement but the total size
of
this cache will be dynamic and will depend on the number of the active

sessions. But since this cache uses SoftReference for the values (the
pages) I think this won't be a problem.


We could have a (configurable) global limit for all cached pages in all


sessions, if that limit is reached, the least recently accessed/modified
page could be removed …


Cheers,
 -Tom

Re: Instant page loads js

[Michael Mosmann]

Am 08.02.14 19:47, schrieb Martijn Dashorst:

http://instantclick.io/

Might be interesting?

It differ slightly from this

https://developers.google.com/chrome/whitepapers/prerender

But I can imagine some unwanted side effects, because many users are 
watching with the mouse so your browser can preload many pages 
without using them at all.


Though what would happen with a delete link?
SDD - surprise driven development .. successful deleted your account 
.. WHAT? :) :)


mm:)

Re: Wicket 7 development status

[Michael Mosmann]

Am 29.01.14 09:31, schrieb Martin Grigorov:

Hi,

On Wed, Jan 29, 2014 at 9:15 AM, Michael Mosmann mich...@mosmann.de wrote:


Hi,

As one might know I did some refactoring in this direction. What we can
expect is some trouble with defaultModel in Component. There are different
kind of ways to solve this, but it will come with cost.
- remove default model from component
- make component generic
- make some bigger changes to it


Yes, I also imagine bigger API changes to accomplish this.

yes.. think we can not avoid this..

Both the old discussion [1] and Martijn suggest to change Label to use read
only model.
I see several problems with this:

- I won't be able to push new object into the Label's model.
Usually one needs readonly model, like ResourceModel, but there are cases
when you need to do: label.setModelObject(new)
I see some trouble in changing components model values from outside .. 
I saw a lot of code where someone did this with more complex 
components/models without the component itself knowing this.


But I understand the value of this shortcut.


- o.a.w.Component as the base class for all components doesn't know what
type of model the specialization will need, so it's signature will have to
use a base model class. What is the base for IReadableModel and
IWriteableModel ?!
I think there is only ReadOnlyModel and Model .. because a Model you 
only can write into us very unusual.. If we model it this way: IModel - 
IWriteableModel + IReadonlyModel then ComponentT,M extends 
IReadonlyModelT is valid, because other Components Extend it to f.I. 
FormT extends ComponentT,IModelT


This is how I think about it, which is only valid in my head until some 
code proves that I did not miss something.


- currently IModel is also IDetachable
I am not sure that lambda's in Java 8 will work here unless we remove
IDetachable from the base imodel interface and add it to each
implementation.
Yes.. and Models without Detach are useless. I see no obvious solution 
with a good benefit/cost ratio.


Next steps:
- finish my serialization visualization tool (1-2 weeks (hope so))
- install java8 on my laptop (1 day .. (hope so.. no idea))
- explore some refactorings and rumtime behavior with the current wicket 
branch and java8


Michael

Re: Wicket-5353: Wrap feedback messages in a model instead of using Serializable objects

[Michael Mosmann]

+1

Am 17.09.13 17:18, schrieb Michael Haitz:

Hi,

why do you need a special API using IModel instead of Serializable? 
wicket-bootstrap uses also models but with existing API, isn't this enough?

check NotificationPanel, NotificationAlert and NotificationMessage:
https://github.com/l0rdn1kk0n/wicket-bootstrap/tree/master/bootstrap-core/src/main/java/de/agilecoders/wicket/core/markup/html/bootstrap/common


cheers,
Michael

Am 17.09.2013 um 16:49 schrieb Rafael W. 
rafael@web.demailto:rafael@web.de:

Hello everybody,

I would like to put https://issues.apache.org/jira/browse/WICKET-5353 to 
dicussion. Attached, you can find an example of a Wicket application that would 
benefit from that change. (Simly run wicket-async-task-demo with jetty:run in 
Maven.)

Generally, I want feedback messages to be represented by models rather than by 
Serializables in order to allow more multithreading in Wicket. The example 
contains a simple progress bar component where tasks are run in background 
threads in order to keep the Wicket application responsive. (I mostly use 
Wicket in Desktop-style applications where the attached component is 
tremendously useful for me.)

The problem with the Serializable solution for feedback messages is that the 
messages have to be assembled at the time the error occurs, not at the time the 
message is to be displayed. In my believe, this is a misconception that can 
easily be corrected. I described the topic further in the Jira issue above.

Thank you for your feedback.
Regards, Rafael Winterhalter

wicket-async-task.zip

Re: RFC-0001: Deprecating PageParameters for Wicket 7 (was Re: [4/4] git commit: WICKET-4997)

[Michael Mosmann]

Am 23.08.13 00:16, schrieb Martijn Dashorst:

On Thu, Aug 22, 2013 at 11:42 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote:

On Thu, Aug 22, 2013 at 2:04 PM, Martijn Dashorst
martijn.dasho...@gmail.com wrote:
still need
pageparameters to carry those params forward in bookmarkablelink, etc.

Not necessarily: the API is still under construction. It is the
intention to remove the need for PageParameters altogether in the API.
I also prefer removing instead of wrapping it around the now code.. But: 
sometimes you need a functionality where you simply pass unknown page 
parameters some of your bookmarkablelinks. So there is no need to access 
this functionality with the PageParameters-api, but there is a need to 
have such kind of functionality.


IMHO these page parameter stuff is something like page-external state 
conversion. And is think the JAX-RS way is only one part of the game. 
(Btw i don't like magic:) So i would prefer not to use 
annotation-based-injection-something.)


We should reuse the conversion infrastructure we have to convert one 
parameter into one value/attribute of the what-ever-mapped page state. 
But in the end there should be one object/type for an state of an page.


Michael:)

Re: [4/4] git commit: WICKET-4997: render bookmarkable urls for bookmarkable pages (not stateless)

[Michael Mosmann]

Am 22.08.13 11:25, schrieb Bernard:

Hi,
On Thu, 22 Aug 2013 11:21:41 +0300, you wrote:


On Thu, Aug 22, 2013 at 11:08 AM, Emond Papegaaij 
emond.papega...@topicus.nl wrote:

snip

The mismatch is in the fact that the PageParameters object is stored with
the page while it resembles the parameters the page was created with. If
a page changes (for example, by updating its model object), the
PageParameters no longer match with the state of the page. That's why I'd
rather not store them in the page at all but recreate them when needed.


I don't see why Page's parameters should be related 1:1 to page's model.
The parameters are just the data that has been provided for the page
construction. Nothing more.
Later they could be used for url generation or not.
The page may use some of the parameters to create its model or not.


snip

I can see Martijn's point, and if one defines this as a convention, as
it already is, then no more confusion.

But I think it is a good concept to generate PageParameters from the
state of the page.
... which can be complicated if you want to preserve any state of your 
page in an external representation through page parameters. I had build 
something like that and it was a pain (did this for SEO)...

  It would be good practice.

.. i am not sure about that.

  I already use public
static methods MyPage#createParameters(MyEntity something) which
encapsulates this so my page instance would just call the static
method with the parameters from the state of the page.

So how could this be enforced? The framework could insist on
overriding such a method if it detects a PageParameters constructor.

.. sometimes you do not want to present internal state.

Unfortunately that constructor is abused at the moment. See
WICKET-5069.

It would not be performant so caching would be needed.

Perhaps update the instance var pageparameters with the result of a
getPageParameters() call on modelChanged()?
I think we mixing different kind of things here.. If you can externalize 
the state of a page into a page parameter string representation, then 
your page does not have any state. Every link on such a page should be 
therefor a BookmarkablePageLink with an different set of page parameters 
which describe the transition to a different client side state. You must 
then redirect every form submit or non-bookmarkable links to a page with 
page parameters describing the new state. This way there will be no 
PageExpired exception.


This way you use wicket as a component based page renderer.. which is 
ok, but not a strength of wicket.


We can make it easier to provide classes and functions if this is what 
you want. But i fear that there is not the one solution, because there 
are often very surprising requirements.


Michael:)

Re: [VOTE] Accept the Wicket Free Guide as a part of Apache Wicket

[Michael Mosmann]

[X] Yes, accept the Wicket Free Guide to incorporate into our project
[ ] No, don't accept the Wicket Free Guide

:)

Am 18.08.2013 16:48, schrieb Martijn Dashorst:

Andrea del Bene has granted us the ability to include the Wicket Free Guide
into our project and to conclude the IP-clearance we need to actually vote
to have the guide accepted. The donated file is available as an attachment
at [1]. The grant actually lists the google code repository for reference,
so perhaps that one is more up to date.

So here's the vote (runs for 72 hours):

[ ] Yes, accept the Wicket Free Guide to incorporate into our project
[ ] No, don't accept the Wicket Free Guide

Martijn

PS. It is the intention to build a HTML version of the document using some
easy to maintain format, but the specifics of the conversion is not part of
this vote.

[1]: https://issues.apache.org/jira/browse/WICKET-5321

Re: code coverage for wicket

[Michael Mosmann]

Am 12.08.13 10:41, schrieb Martin Grigorov:

Ok.

I will also try to measure the different build times to get a picture if 
we slow down to much with this change.


Michael:)


Hi,

I don't mind having this until it doesn't run on my machine on every local
build.
So please add it in a Maven profile and we can set this profile in BuildBot
configs for master branch.
At the moment BuildBot generates the Javadocs -
http://ci.apache.org/projects/wicket/
We can extend the BuildBot config to copy the Jacoco reports to a folder
next to javadocs.


On Sat, Aug 10, 2013 at 6:38 PM, Michael Mosmann mich...@mosmann.de wrote:


Hi,

i would like to add jacoco code coverage ( http://www.eclemma.org/jacoco/) to 
the wicket project.

Michael

an other wicket guide

[Michael Mosmann]

saw this on google+:

http://wicketguide.comsysto.com/

Re: an other wicket guide

[Michael Mosmann]

ah.., was not sure..

Am 12.08.13 14:03, schrieb Martijn Dashorst:

It's the same guide, but published by the company where Andrea works...

Martijn

On Mon, Aug 12, 2013 at 1:32 PM, Michael Mosmann mich...@mosmann.de wrote:

saw this on google+:

http://wicketguide.comsysto.com/

code coverage for wicket

[Michael Mosmann]

Hi,

i would like to add jacoco code coverage ( 
http://www.eclemma.org/jacoco/ ) to the wicket project.


Michael

Re: Wicket hot reloading - Proof of concept

[Michael Mosmann]

Am 01.08.13 09:55, schrieb Martin Grigorov:

Michael,


On Thu, Aug 1, 2013 at 9:48 AM, Michael Mosmann mich...@mosmann.de wrote:


Only to be sure.. You know the run-jetty-run eclipse plugin?


All I know about this project is that Eelco started it.
I think this project is very usefull. But until its finished there are 
some solutions to take away the pain a little bit:)

But looking at their page I see they also recommend DCEVM [1].
I use it since a while and I find it helpful.

1.
http://blogs.jetbrains.com/idea/2013/07/get-true-hot-swap-in-java-with-dcevm-and-intellij-idea/

cool :)
will try this..

Re: Wicket hot reloading - Proof of concept

[Michael Mosmann]

Only to be sure.. You know the run-jetty-run eclipse plugin?

Am 31.07.13 17:29, schrieb Cedric Gatay:

Hi all,

today I did a small Proof Of Concept of autocompile and hot reload
fonctionnality for Wicket. The implementation is inspired by Xavier Hanin's
work on restx (restx.io) (he inspired himself from PlayFramework!).

You can find the implementation on the following github repo :
https://github.com/code-troopers/wicket-hot-reload

There is a lot of things to do, but with my basic example it works. The
major thing we need to sort out is the actual need to destroy / recreate
the whole application object whenever we want to load new classes.

Any comments are welcome,

Regards,
__
Cedric Gatay (@Cedric_Gatay http://twitter.com/Cedric_Gatay)
http://code-troopers.com | http://www.bloggure.info | http://cedric.gatay.fr

Re: git commit: WICKET-5071 use url as clientUrl

[Michael Mosmann]

in human history the past is allways changing...

human history is not cryptographically hashed :(

On Fri, Jul 12, 2013 at 6:36 AM, Martin Grigorov mgrigo...@apache.org wrote:

On Fri, Jul 12, 2013 at 4:33 PM, Jeremy Thomerson jer...@wickettraining.com

wrote:
On Fri, Jul 12, 2013 at 7:34 AM, Sven Meier s...@meiers.net wrote:


Sorry, that was the wrong issue number in the clipboard.

Changing the last commit message after push? Linus says don't to it:

http://stackoverflow.com/**questions/457379/how-do-i-**
edit-an-incorrect-commit-**message-in-git-ive-pushed/**457396#457396

http://stackoverflow.com/questions/457379/how-do-i-edit-an-incorrect-commit-message-in-git-ive-pushed/457396#457396

Besides, history rewriting is disallowed at ASF (for good reason).


For SVN it is not disallowed.
But I guess you mean just Git history, not human history :-)

Re: Michael Mosmann is a committer and PMC member!

[Michael Mosmann]

Thank you for your warm welcome:) I am very proud to be a part of it:) ...
... do we have t-shirts? :)

Am 01.07.2013 11:51, schrieb Martijn Dashorst:

Please welcome Michael Mosmann as our newest addition to the Wicket team!

Michael has been a long time contributor to Wicket, and even wrote a
book on the subject. His day to day work keeps him busy with Wicket so
we are very happy that Michael wanted to join our band of merry men!

Martijn

Re: JavaScript functional tests

[Michael Mosmann]

Am 18.06.2013 15:20, schrieb Martin Grigorov:

At the moment I run the tests from time to time manually by loading the
respective url in the browsers.

I can add Maven integration that will run the tests in PhantomJS during
each 'mvn test' execution. The requirement here is that there is installed
Node.js on the machine.
I have a project to download and start node.js automagical.. 
https://github.com/flapdoodle-oss/de.flapdoodle.embed.nodejs .. maybe we 
can put both things together..



  It is needed to run PhantomJS.
The related Maven config can be seen at
https://github.com/martin-g/blogs/blob/master/functional-qunit/pom.xml#L65-L103

Having it automated means that we will need this setup on the CI servers
too.


On Tue, Jun 18, 2013 at 4:06 PM, Jeremy Thomerson jer...@wickettraining.com

wrote:
Will we need to add this as a manual test step in our build / release
cycle?  Or will there be some way of automating it built into our release
script(s)?


On Mon, Jun 17, 2013 at 1:19 PM, Martin Grigorov mgrigo...@apache.org

wrote:
I use QUnit as testing library.
Node.js is required only to automate the run of the tests (in headless
mode) in PhantomJS (WebKit).

At the moment I run the tests by just loading
http://localhost:8080/js-test/all.html in any browser.
Try it! You will like it!

I'll merge the branch soon.


On Mon, Jun 17, 2013 at 8:13 PM, Cedric Gatay gata...@gmail.com wrote:


Testing JS is a good thing to me, is there any other javascript testing
framework without such prerequisite (Node.js) ? At SRMvision, we use
Jasmine which does not require any other setup.

Anyway, I think it should be part of the Maven build process if we want
them to be useful.

Regards,

__
Cedric Gatay (@Cedric_Gatay http://twitter.com/Cedric_Gatay)
http://code-troopers.com | http://www.bloggure.info |
http://cedric.gatay.fr


On Mon, Jun 17, 2013 at 4:20 PM, Martijn Dashorst 
martijn.dasho...@gmail.com wrote:


No problem... the more tests the merrier

Martijn

On Mon, Jun 17, 2013 at 3:05 PM, Martin Grigorov 

mgrigo...@apache.org

wrote:

Hi,

I just pushed branch wicket-examples-gym-tests.
It contains some tests based on the idea described at


http://wicketinaction.com/2012/11/javascript-based-functional-testing/

To run the tests one has to start the examples and load
http://localhost:8080/js-test/all.html

Is there anyone against these tests ?
I'd like to add some coverage to Wicket Examples and to practice my

JS

coding skills.

At the moment both the old JS tests (wicket-core/src/test/js) and

these

ones should be executed manually. I can integrate them in Maven but

them

all developers and CI machines should have Node.js
Do we want the tests in the build or should I leave them as now ?



--
Become a Wicket expert, learn from the best:

http://wicketinaction.com


--
Jeremy Thomerson
http://wickettraining.com
*Ask me about our plans for on-line training lessons.*

Re: [VOTE] Branch for Wicket 7.0

[Michael Mosmann]

[x] Yes, start work on Wicket 7 with the proposed roadmap

I can help too ..

Re: WicketTester cookie handling

[Michael Mosmann]

Am 24.04.2013 13:59, schrieb Martin Grigorov:

Hi,

On Tue, Apr 23, 2013 at 10:58 AM, Michael Mosmann mich...@mosmann.dewrote:


Hi,

as someone may has noticed there is a bug in the WicketTester cookie
handling ( 
https://issues.apache.org/**jira/browse/WICKET-5147https://issues.apache.org/jira/browse/WICKET-5147).
I wrote some tests to make things clear, but in a talk with Martin we got a
little bit suspicious about the way WicketTester should handle this.

Two scenarios are possible (or more?):

1. remember cookies from server, forget cookies from client:
- you can set any cookies you like in tester.getRequest()
- any cookies from request are send to the page
- you can set any cookies you like in the response
- after the response is done, every cookie set by the server is remembered
for further requests
- if you add new cookies to tester.getRequest() they can overwrite any
remembered response cookies
- the cookies set in an old request are not copied into new requests

2. remember cookies from server and from client:
- you can set any cookies you like in tester.getRequest()
- any cookies from request are send to the page
- you can set any cookies you like in the response
- after the response is done, every cookie set by the server and from the
last request is set to the new request
- you will see all cookies in tester.getRequest() and can change these
before the next request is started

What do you think?


I think the second is the correct one.
An application can use JavaScript to create a cookie. This cookie will be
sent to the server until it expires or the server sends back a cookie with
the same name and max-age=0 to delete it.
So I think any cookie added to a request with
tester.getRequest().addCookie(cookie) should be send with any following
request until either the cookie is removed (age=0) or the tester is
destroyed (browser close).
bwt: there is no code for this cookie is expired stuff.. will write a 
test for this.. :)




--
Michael Mosmann

WicketTester cookie handling

[Michael Mosmann]

Hi,

as someone may has noticed there is a bug in the WicketTester cookie 
handling ( https://issues.apache.org/jira/browse/WICKET-5147). I wrote 
some tests to make things clear, but in a talk with Martin we got a 
little bit suspicious about the way WicketTester should handle this.


Two scenarios are possible (or more?):

1. remember cookies from server, forget cookies from client:
- you can set any cookies you like in tester.getRequest()
- any cookies from request are send to the page
- you can set any cookies you like in the response
- after the response is done, every cookie set by the server is 
remembered for further requests
- if you add new cookies to tester.getRequest() they can overwrite any 
remembered response cookies

- the cookies set in an old request are not copied into new requests

2. remember cookies from server and from client:
- you can set any cookies you like in tester.getRequest()
- any cookies from request are send to the page
- you can set any cookies you like in the response
- after the response is done, every cookie set by the server and from 
the last request is set to the new request
- you will see all cookies in tester.getRequest() and can change these 
before the next request is started


What do you think?

--
Michael Mosmann

Re: Registering converters for PageParameters

[Michael Mosmann]

Am 21.01.2013 08:14, schrieb Martijn Dashorst:

+1


We have a really nice type safe API but the thing that strikes me as
odd is that AFIAK we don't have converters from PageParameters to
objects and back. Now it probably is not easy to get it right, but
what would be not too crazy is to be able to register a
PersonPageParametersConverter such that a PersonPage taking a Person
as a constructor parameter would be considered bookmarkable.

Perhaps this would be good to have as an annotation?

Martijn

Re: Registering converters for PageParameters

[Michael Mosmann]

Am 21.01.2013 09:55, schrieb Martin Grigorov:

What would such converter actually do? I guess the encoder for an employee
it will generate PageParameters with id-empId (assuming you want a nice
looking url which will encode 'employee' as Url segment, e.g.
/company/employee/34).
Later the decoder will do what ? Will make a request to the DB to load all
the details for the Employee ? I think it should provide a model -
MyPage(IModelEmployee), e.g. LDMEmployee, and make the request to the
DB as late as possible. But we already have this constructor in (Web)Page
API (org.apache.wicket.Page#Page(IModel))


I think more of a PageParameter-Bean converter .. no DB access.

I did this before, but more this way:

public MyPage(PageParameters p) {
MyBean state=MyBean.from(p);

// some code
MyBean newState=state.withId(nextEntryId);

   add(new BookmarkableStateLink(link,MyPage.class,newState));
}

remove javax.servlet from wicket-core

[Michael Mosmann]

Hi,

it may sound like a crazy idea, but sometimes a good idea started as a 
crazy one: I want to remove javax.servlet from wicket-core. Why? Here 
are some thoughts:

- run a wicket application on a netty/vert.x/what-ever stack
- make test easier (BaseWicketTester is not as clear as it should be)
- maybe it's easier to implement atmosphere or something like this 
without this javax.servlet rabbit hole

- your ideas

The last days i did some code changes ( 
https://github.com/michaelmosmann/wicket/tree/Refactor-ServletAbstraction) 
... with limited success. Removing javax.servlet from core is possible 
as far as we ignore something like spring. But that's not an option...


What i want to know: Is there any chance, that this can succeed? This 
will change wicket in many places, and i understand, that nobody will 
accept this as an wicket 6.x.y improvment. Maybe this is the wrong 
direction, maybe the right thing to early, not the best thing we could 
do now...


Maybe i am the crazy one with obviously to much time for crazy ideas...

Michael

Re: wicket pull request: change IModel to readonly by default

[Michael Mosmann]

Am 17.12.2012 18:56, schrieb Sven Meier:
Hi Sven,

what's the actual benefit? Do you have a before/after comparison?

Now you can see the difference if a component could change a model value.

public CompWouldChangeValue(String id, IWriteableModelString model) { 
... }


vs.

public CompDoesNotChangeValue(String id, IModelString model) { ... }

.. a FormComponent should take a IWriteableModel as parameter.

There is no need to throw RuntimeExceptions in AbstractReadonlyModel. 
For many LDM there is not good setObject() implementation.. now you dont 
need one.


I hope, it will explain it a little bit more.



Best regards
Sven

On 12/16/2012 08:30 PM, michaelmosmann wrote:

GitHub user michaelmosmann opened a pull request:

 https://github.com/apache/wicket/pull/27

 change IModel to readonly by default

 I have removed setObject() from IModel and moved it to 
IWriteableModel. This time i tried to make as less impact as 
possible. All test are green (you hat to disable the clirr plugin 
because of api changes to 6.0.0).

  Why?
  You can not say if a model is read only by its type. You 
can not force a component not to change your model value (based on 
the type of the model).
  I would like to change this. This is a first step to show, 
that it is possible.


You can merge this pull request into a Git repository by running:

 $ git pull https://github.com/michaelmosmann/wicket 
Refactor-WriteableModel


Alternatively you can review and apply these changes as the patch at:

 https://github.com/apache/wicket/pull/27.patch


commit 5521138c412036551bdf96fcbfbe2286a7e1fd9b
Author: Michael Mosmann mich...@mosmann.de
Date:   2012-09-26T20:17:26Z

 ignore idea project files

commit 9a2f8c8665c48abe29611cc5d5f0cc72e53c961c
Author: Michael Mosmann mich...@mosmann.de
Date:   2012-09-30T22:58:04Z

 Merge remote-tracking branch 'upstream/master' into trunk

commit 698bfb771128fd157a4e5a47af5e61ff40a06d68
Author: Michael Mosmann mich...@mosmann.de
Date:   2012-10-01T17:17:46Z

 Merge remote-tracking branch 'upstream/master' into trunk

commit b4645c4608517877aba49bac8d3aec695d8922fc
Author: Michael Mosmann mich...@mosmann.de
Date:   2012-10-01T18:40:27Z

 git ignore

commit 9323d9593931f82ac9dbe6908b49aeeda359bd31
Author: Michael Mosmann mich...@mosmann.de
Date:   2012-10-02T14:34:40Z

 introduce writeable model

commit 5408fab49e20105c15cb9a989cf3de0845edf448
Author: Michael Mosmann mich...@mosmann.de
Date:   2012-10-09T19:32:09Z

 added annotation

commit 2965b1b698f1c08eb07a15a60336a6e7ecce4135
Author: Michael Mosmann mich...@mosmann.de
Date:   2012-10-09T19:34:17Z

 Merge remote-tracking branch 'upstream/master' into trunk

commit d088d97094885faa579279d2b847d6137ebfa55e
Author: Michael Mosmann mich...@mosmann.de
Date:   2012-10-09T19:35:15Z

 Merge branch 'trunk' into Refactor-WriteableModel

commit 2a60388d3513c2f44c507347b6da16d31f618860
Author: Michael Mosmann mich...@mosmann.de
Date:   2012-10-10T18:48:04Z

 Merge remote-tracking branch 'upstream/master' into trunk

commit 5ffb19d8bf8522d19506240da8b38ff69a4707eb
Author: Michael Mosmann mich...@mosmann.de
Date:   2012-12-06T21:06:17Z

 Merge remote-tracking branch 'upstream/master' into trunk

commit 9900066c219b67b536e98fcb606e07c31076482f
Author: Michael Mosmann mich...@mosmann.de
Date:   2012-12-06T21:08:38Z

 Merge branch 'trunk' into Refactor-WriteableModel

commit 5e2c00f1f3c1988ed250793ca55768c8fcf1bbac
Author: Michael Mosmann mich...@mosmann.de
Date:   2012-12-16T18:05:24Z

 Merge remote-tracking branch 'upstream/master' into trunk

commit 575d73af0c57611e17cd5e68fff61a3a5cd3c50d
Author: Michael Mosmann mich...@mosmann.de
Date:   2012-12-16T18:07:53Z

 Merge remote-tracking branch 'origin/trunk' into 
Refactor-WriteableModel


commit 74dccf0c42af29dfbc49d31c1d7330a43ebba6c6
Author: Michael Mosmann mich...@mosmann.de
Date:   2012-12-16T18:30:46Z

 prepare component model replacement

commit 49dc93c8b81c913a37dfe92fedbe0cf81e720413
Author: Michael Mosmann mich...@mosmann.de
Date:   2012-12-16T19:01:01Z

 compiles

commit 23f85a8dd42a5b9838774195f88e3b3f74785a40
Author: Michael Mosmann mich...@mosmann.de
Date:   2012-12-16T19:19:11Z

 clean up

commit 8b93bc61bf83b1dc681c6d71f1ea8b8d43c7c1ab
Author: Michael Mosmann mich...@mosmann.de
Date:   2012-12-16T19:19:19Z

 clean up

IAjaxRegionMarkupIdProvider

[Michael Mosmann]

Hi,

.. maybe someone has a better idea. What's the problem.

One can add a behavior to a component which implements 
IAjaxRegionMarkupIdProvider. This way it's very easy to include some 
content rendered by this behavior even in an ajax-response (see 
http://www.wicket-praxis.de/blog/2011/05/18/wicket-ajax-iajaxregionmarkupidprovider/ 
(german only)). But if the component is invisible, the behavior is not 
called except the IAjaxRegionMarkupIdProvider call.


So whatever the behavior does in beforeRender()/afterRender() (wicket 
1.5.x), it will not be asked again, except for the markup id.


Ok.. some examples:

body
  wicket:container wicket:id=panel/wicket:container
/body

could be rendered to (if visible):

body
div id=panel1_mybehavior
wicket:container id=panel1 wicket:id=panel/wicket:container
/div
/body

but will be rendered to (if invisible (setOutputMarkupPlaceholderTag(true)):

body
 wicket:container id=panel1 wicket:id=panel 
style=display:none/wicket:container

/body

which is in production should simply this:

body

/body

but is (Bug in renderPlaceholderTag?)

body
 wicket:container id=panel1 style=display:none/wicket:container
/body

Ok. Here is what i would like to achive:
- you can update a component via ajax no matter which tag the component 
is bound

- it should work with invisible components
- i would like to avoid any additional WebMarkupContainer

Any idea?
It is a bug (wicket 1.5.9 - i can do a quickstart)?

thank you:)
Michael

Re: More flexible object checking during serialization

[Michael Mosmann]

Hi,

Some examples from a real life project beside serializable and LDM
handling:
- check if a component has a parent .. if not, the component is not part
of the component tree which could be a bad sign
- check for type which should never be serialized (holding stuff in
fields and not in models)

Other Ideas comes in mind:
- check for Model implementation with a overwritten getObject()-method
- check for Model with large stuff in it

Michael:)

Am Mittwoch, den 10.10.2012, 16:17 +0300 schrieb Martin Grigorov:
 Good idea!
 Let's see how this could be improved.
 
 I didn't say it explicitly in my previous mail but my commit was in a
 separate branch. It is not yet planned for the next release. It should
 be approved first from you.
 
 On Wed, Oct 10, 2012 at 4:11 PM, Emond Papegaaij
 emond.papega...@topicus.nl wrote:
  I did not yet replace our checker with the new one. One of the changes we 
  made
  to the checker was that we removed a few lines to improve performance. The 
  old
  SerializableChecker uses string concatenation all over the place, and a few 
  of
  those places introduce a serious performance overhead (I'm talking about
  minutes, not milliseconds). The most important ones are 'String arrayPos = 
  [
  + i + ];' and 'String arrayPos = [ + i + ];'. A large set (with
  thousands or records) generates 10th's of thousands string concatenations,
  which takes a long time. It would be nice if we could fix that as well.
 
  Best regards,
  Emond
 
  On Wednesday 10 October 2012 16:00:23 Martin Grigorov wrote:
  Hi,
 
  With
  https://git-wip-us.apache.org/repos/asf/wicket/repo?p=wicket.git;a=commitdi
  ff;h=6014d8bb92595bf486d69f7a5c1c798bcdc252f1 I extracted the logic for
  reading object members with
  ObjectStreamClass into a separate class ObjectChecker. This new class
  uses implementations of IObjectChecker to do the actual checks. For
  now there are two impls:
  - check that the class is Serializable (as before)
  - check that instances of LoadableDetachableModel are detached before
  serialization. This own proved to be quite useful !
 
  It is quite easy to add your own custom checkers. For example like the
  ones explained at
  http://wicketinaction.com/2011/11/detect-attached-models-and-entities/
  for JPA entities.
 
  I tried to keep SerializableChecker binary compatible so it has some
  baggage which may be removed for Wicket 7.0.
  If any of the checkers fail then the pretty print message is used to
  show where is the problem and its type.
 
  The usage is:
  JavaSerializer serializer = new JavaSerializer(app.getKey()) {
 @Override
 protected ObjectOutputStream newObjectOutputStream(OutputStream
  out) throws IOException {
 return new ObjectCheckerObjectOutputStream(out, new
  ObjectSerializationChecker(), new NotDetachedModelChecker(), new
  MyOwnChecker());
 }
  }
  app.getFrameworkSettings().setSerializer(serializer);
 
  Please have a look and give your opinion. Any suggestions are welcome!
 
 
 

wicketstuff git commit access

[Michael Mosmann]

Hi,

I would like to have wicketstuff commit access on github. My github name
is michaelmosmann (https://github.com/michaelmosmann). I am interested
in this kryo stuff. 

thanks.

IWriteableModel

[Michael Mosmann]

Hi,

.. yesterday I did some refactoring which introduced a IReadOnlyModel 
interface. I stopped this so far because of these many default casts to 
IModel. I will try it again with the other way around (IWriteableModel). 
So far I could see how things become more clear if the right interface 
is used. So here comes some questions:


- Is somebody interested in this change (beside me)?
- Is there a chance that we missing something so wicket could break?
- Is there a better name (sure there is)?

Thanks
Michael

Re: IWriteableModel

[Michael Mosmann]

I have no specific problem, more a general...

I think most time a model access uses only getObject(). Throwing exceptions on 
setObject in AbstractReadOnlyModel could be avoided with the right interface is 
there. An in between of my last refactoring i could see that (to this point) 
nothing violated the intention. The right interface would prove this...

I would like to see in method signatures or c-tor params that a component does 
not change a model value.

I hope i could explain my intention good enough:)

Mm:)



Igor Vaynberg igor.vaynb...@gmail.com schrieb:

what problem are you trying to solve?

-igor

On Sun, Sep 30, 2012 at 11:25 PM, Michael Mosmann mich...@mosmann.de
wrote:
 Hi,

 .. yesterday I did some refactoring which introduced a IReadOnlyModel
 interface. I stopped this so far because of these many default casts
to
 IModel. I will try it again with the other way around
(IWriteableModel). So
 far I could see how things become more clear if the right interface
is used.
 So here comes some questions:

 - Is somebody interested in this change (beside me)?
 - Is there a chance that we missing something so wicket could break?
 - Is there a better name (sure there is)?

 Thanks
 Michael


--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

Component setDefaultModel

[Michael Mosmann]

Hi,

is there any usefull application of Component.setDefaultModel(...)? IMHO 
this Method is the cause for much trouble without any benefit. But maybe 
i did not understand when someone should replace a component model...


thanks
Michael

Re: Component setDefaultModel

[Michael Mosmann]

Am 27.09.2012 09:01, schrieb Martin Grigorov:
Hi,

I think, there is a little difference in using setDefaultModel and 
setDefaultModelObject .. the first one sets a new model instance, the 
second only change the value in the existing model. Some pseudo-code:


class APanel extends Panel {
APanel(String id,IModelSome model) {
super(id,model);

add(new Label(name,new PropertyModel(getDefaultModel(),name));
}
}

If you replace the value in model, everything is fine and works as 
expected. If you call setDefaultModel you might think, that everything 
is fine, but its not. A child component does not use 
getParent().getDefaultModel() to get these changes. I saw a lot of code 
like this, which leads to trouble, if you change the model and not the 
value.


If there is no benefit in using setDefaultModel over 
setDefaultModelObject i would like to remove this method. This could 
prevent many you might not got the full picture how to use wicket the 
right way errors.


Michael


Hi,

Most of the time it is recommended to use a dynamic model, so there is
no reason to replace the component's model.
Component#setDefaultModel() gives you semi-dynamic nature - you can
replace the model completely with a new one. Same with
#setDefaultModelObject().

What is the problem you face with it ?

On Thu, Sep 27, 2012 at 9:57 AM, Michael Mosmann mich...@mosmann.de wrote:

Hi,

is there any usefull application of Component.setDefaultModel(...)? IMHO
this Method is the cause for much trouble without any benefit. But maybe i
did not understand when someone should replace a component model...

thanks
Michael

Re: Component setDefaultModel

[Michael Mosmann]

Am 27.09.2012 09:51, schrieb Martin Grigorov:

Hi,

a dont care about the type issue here.. Maybe i can explain it again in 
an other way:


APanel uses model instance A and the label uses a property model 
instance P which uses a reference to model instance A.


After calling APanel.setDefaultModel(B) APanel uses model instance B,but 
label uses model instance P which uses model instance A as before. So 
the label does not see any changes, because no one tells the model 
instance P, that it should use B instead of A. I think, there are rare 
cases for such a usage.


thanks
Michael


Hi,

In this particular code I think the problem is PropertyModel, since
it brings the type unsafety.

Another solution is to make ComponentT, this way we can remove
#setDefaultModel() and have #setModel(IModelT) only and such
problems will go away.
But as discussed in early Wicket 1.4 days this will lead to more
typing. With Java 7 diamonds it is half the typing though.

For now you can use GenericPanel, GenericPage and all FormComponent.

On Thu, Sep 27, 2012 at 10:41 AM, Michael Mosmann mich...@mosmann.de wrote:

Am 27.09.2012 09:01, schrieb Martin Grigorov:
Hi,

I think, there is a little difference in using setDefaultModel and
setDefaultModelObject .. the first one sets a new model instance, the second
only change the value in the existing model. Some pseudo-code:

class APanel extends Panel {
 APanel(String id,IModelSome model) {
 super(id,model);

 add(new Label(name,new PropertyModel(getDefaultModel(),name));
 }
}

If you replace the value in model, everything is fine and works as expected.
If you call setDefaultModel you might think, that everything is fine, but
its not. A child component does not use getParent().getDefaultModel() to get
these changes. I saw a lot of code like this, which leads to trouble, if you
change the model and not the value.

If there is no benefit in using setDefaultModel over setDefaultModelObject i
would like to remove this method. This could prevent many you might not got
the full picture how to use wicket the right way errors.

Michael



Hi,

Most of the time it is recommended to use a dynamic model, so there is
no reason to replace the component's model.
Component#setDefaultModel() gives you semi-dynamic nature - you can
replace the model completely with a new one. Same with
#setDefaultModelObject().

What is the problem you face with it ?

On Thu, Sep 27, 2012 at 9:57 AM, Michael Mosmann mich...@mosmann.de
wrote:

Hi,

is there any usefull application of Component.setDefaultModel(...)? IMHO
this Method is the cause for much trouble without any benefit. But maybe
i
did not understand when someone should replace a component model...

thanks
Michael

Re: Component setDefaultModel

[Michael Mosmann]

Am 27.09.2012 14:19, schrieb Sven Meier:
 IMHO changing a component's model isn't the wicket way so I'd 
suggest changing the visibility of Component#setDefaultModel() to 
protected.


mark as deprecated and remove it later.. ?


Even a simpler example might fail (no PropertyModel involved):

class APanel extends Panel {
 APanel(String id, IModelSome model) {
 super(id,model);

 add(new BPanel(b, model);
 }
}

A client using APanel might later change the model, leaving BPanel 
working on the old model:

aPanel.setDefaultModel(otherModel);

You could argue that APanel should be made failsafe when passing the 
model:


add(new BPanel(b, new PropertyModel(this, defaultModel)));

But it would be much easier if APanel could assume that its model 
isn't changed unattendedly.


IMHO changing a component's model isn't the wicket way so I'd 
suggest changing the visibility of Component#setDefaultModel() to 
protected.


Sven



On 09/27/2012 10:47 AM, Martin Grigorov wrote:

I see. This is an advanced way to create a static model :-)
But again I find PropertyModel as the real problem here.

I'll let others give their opinions too.

On Thu, Sep 27, 2012 at 11:39 AM, Michael Mosmann 
mich...@mosmann.de wrote:

Am 27.09.2012 09:51, schrieb Martin Grigorov:

Hi,

a dont care about the type issue here.. Maybe i can explain it again 
in an

other way:

APanel uses model instance A and the label uses a property model 
instance P

which uses a reference to model instance A.

After calling APanel.setDefaultModel(B) APanel uses model instance 
B,but
label uses model instance P which uses model instance A as before. 
So the
label does not see any changes, because no one tells the model 
instance P,
that it should use B instead of A. I think, there are rare cases for 
such a

usage.

thanks
Michael



Hi,

In this particular code I think the problem is PropertyModel, since
it brings the type unsafety.

Another solution is to make ComponentT, this way we can remove
#setDefaultModel() and have #setModel(IModelT) only and such
problems will go away.
But as discussed in early Wicket 1.4 days this will lead to more
typing. With Java 7 diamonds it is half the typing though.

For now you can use GenericPanel, GenericPage and all FormComponent.

On Thu, Sep 27, 2012 at 10:41 AM, Michael Mosmann mich...@mosmann.de
wrote:

Am 27.09.2012 09:01, schrieb Martin Grigorov:
Hi,

I think, there is a little difference in using setDefaultModel and
setDefaultModelObject .. the first one sets a new model instance, the
second
only change the value in the existing model. Some pseudo-code:

class APanel extends Panel {
  APanel(String id,IModelSome model) {
  super(id,model);

  add(new Label(name,new
PropertyModel(getDefaultModel(),name));
  }
}

If you replace the value in model, everything is fine and works as
expected.
If you call setDefaultModel you might think, that everything is 
fine, but
its not. A child component does not use 
getParent().getDefaultModel() to

get
these changes. I saw a lot of code like this, which leads to 
trouble, if

you
change the model and not the value.

If there is no benefit in using setDefaultModel over
setDefaultModelObject i
would like to remove this method. This could prevent many you 
might not

got
the full picture how to use wicket the right way errors.

Michael



Hi,

Most of the time it is recommended to use a dynamic model, so 
there is

no reason to replace the component's model.
Component#setDefaultModel() gives you semi-dynamic nature - you can
replace the model completely with a new one. Same with
#setDefaultModelObject().

What is the problem you face with it ?

On Thu, Sep 27, 2012 at 9:57 AM, Michael Mosmann 
mich...@mosmann.de

wrote:

Hi,

is there any usefull application of Component.setDefaultModel(...)?
IMHO
this Method is the cause for much trouble without any benefit. But
maybe
i
did not understand when someone should replace a component model...

thanks
Michael

Re: Component setDefaultModel

[Michael Mosmann]

Am 27.09.2012 17:32, schrieb Igor Vaynberg:

Hi,

.. i would leave setModel as it is, only make this change for 
Component.setDefaultModel().


Michael

-1 on changing setDefaultModel().

1) if B panel's model is truly dependent on A's then that dependency
should be expressed:

add(new BPanel(b, new PropertyModel(this, defaultModel));

or do not use the default model slot of B to store the model. that way
setDefaultModel() calls on B will be a noop and you can choose not to
provide a setter.

2) you are only solving this for a subset of usecases where the
container (A) is not generic. are we also going to make setModel(T)
protected? that would require the model assignment be done through the
constructor only and would eliminate any possibility of writing
builder-style code. consider a simple example:

new DropDownChoice(foo).setModel(bar).setChoices(baz)...

this kind of code should be possible whether written directly by the
developer in the page or produced by some builder.

-igor


On Thu, Sep 27, 2012 at 5:19 AM, Sven Meier s...@meiers.net wrote:

Even a simpler example might fail (no PropertyModel involved):


class APanel extends Panel {
  APanel(String id, IModelSome model) {
  super(id,model);

  add(new BPanel(b, model);
  }
}

A client using APanel might later change the model, leaving BPanel working
on the old model:
 aPanel.setDefaultModel(otherModel);

You could argue that APanel should be made failsafe when passing the model:

 add(new BPanel(b, new PropertyModel(this, defaultModel)));

But it would be much easier if APanel could assume that its model isn't
changed unattendedly.

IMHO changing a component's model isn't the wicket way so I'd suggest
changing the visibility of Component#setDefaultModel() to protected.

Sven




On 09/27/2012 10:47 AM, Martin Grigorov wrote:

I see. This is an advanced way to create a static model :-)
But again I find PropertyModel as the real problem here.

I'll let others give their opinions too.

On Thu, Sep 27, 2012 at 11:39 AM, Michael Mosmann mich...@mosmann.de
wrote:

Am 27.09.2012 09:51, schrieb Martin Grigorov:

Hi,

a dont care about the type issue here.. Maybe i can explain it again in
an
other way:

APanel uses model instance A and the label uses a property model instance
P
which uses a reference to model instance A.

After calling APanel.setDefaultModel(B) APanel uses model instance B,but
label uses model instance P which uses model instance A as before. So the
label does not see any changes, because no one tells the model instance
P,
that it should use B instead of A. I think, there are rare cases for such
a
usage.

thanks
Michael



Hi,

In this particular code I think the problem is PropertyModel, since
it brings the type unsafety.

Another solution is to make ComponentT, this way we can remove
#setDefaultModel() and have #setModel(IModelT) only and such
problems will go away.
But as discussed in early Wicket 1.4 days this will lead to more
typing. With Java 7 diamonds it is half the typing though.

For now you can use GenericPanel, GenericPage and all FormComponent.

On Thu, Sep 27, 2012 at 10:41 AM, Michael Mosmann mich...@mosmann.de
wrote:

Am 27.09.2012 09:01, schrieb Martin Grigorov:
Hi,

I think, there is a little difference in using setDefaultModel and
setDefaultModelObject .. the first one sets a new model instance, the
second
only change the value in the existing model. Some pseudo-code:

class APanel extends Panel {
   APanel(String id,IModelSome model) {
   super(id,model);

   add(new Label(name,new
PropertyModel(getDefaultModel(),name));
   }
}

If you replace the value in model, everything is fine and works as
expected.
If you call setDefaultModel you might think, that everything is fine,
but
its not. A child component does not use getParent().getDefaultModel()
to
get
these changes. I saw a lot of code like this, which leads to trouble,
if
you
change the model and not the value.

If there is no benefit in using setDefaultModel over
setDefaultModelObject i
would like to remove this method. This could prevent many you might
not
got
the full picture how to use wicket the right way errors.

Michael



Hi,

Most of the time it is recommended to use a dynamic model, so there is
no reason to replace the component's model.
Component#setDefaultModel() gives you semi-dynamic nature - you can
replace the model completely with a new one. Same with
#setDefaultModelObject().

What is the problem you face with it ?

On Thu, Sep 27, 2012 at 9:57 AM, Michael Mosmann mich...@mosmann.de
wrote:

Hi,

is there any usefull application of Component.setDefaultModel(...)?
IMHO
this Method is the cause for much trouble without any benefit. But
maybe
i
did not understand when someone should replace a component model...

thanks
Michael

Re: Component setDefaultModel

[Michael Mosmann]

Am 27.09.2012 17:51, schrieb Igor Vaynberg:

good point..
-1 from me.. thought it was a good idea, but wasn’t

Michael


so what happens if panel A extends GenericPanel which has setModel?
you havent fixed anything.

-igor

On Thu, Sep 27, 2012 at 8:50 AM, Michael Mosmann mich...@mosmann.de wrote:

Am 27.09.2012 17:32, schrieb Igor Vaynberg:

Hi,

.. i would leave setModel as it is, only make this change for
Component.setDefaultModel().

Michael


-1 on changing setDefaultModel().

1) if B panel's model is truly dependent on A's then that dependency
should be expressed:

add(new BPanel(b, new PropertyModel(this, defaultModel));

or do not use the default model slot of B to store the model. that way
setDefaultModel() calls on B will be a noop and you can choose not to
provide a setter.

2) you are only solving this for a subset of usecases where the
container (A) is not generic. are we also going to make setModel(T)
protected? that would require the model assignment be done through the
constructor only and would eliminate any possibility of writing
builder-style code. consider a simple example:

new DropDownChoice(foo).setModel(bar).setChoices(baz)...

this kind of code should be possible whether written directly by the
developer in the page or produced by some builder.

-igor


On Thu, Sep 27, 2012 at 5:19 AM, Sven Meier s...@meiers.net wrote:

Even a simpler example might fail (no PropertyModel involved):


class APanel extends Panel {
   APanel(String id, IModelSome model) {
   super(id,model);

   add(new BPanel(b, model);
   }
}

A client using APanel might later change the model, leaving BPanel
working
on the old model:
  aPanel.setDefaultModel(otherModel);

You could argue that APanel should be made failsafe when passing the
model:

  add(new BPanel(b, new PropertyModel(this, defaultModel)));

But it would be much easier if APanel could assume that its model isn't
changed unattendedly.

IMHO changing a component's model isn't the wicket way so I'd suggest
changing the visibility of Component#setDefaultModel() to protected.

Sven




On 09/27/2012 10:47 AM, Martin Grigorov wrote:

I see. This is an advanced way to create a static model :-)
But again I find PropertyModel as the real problem here.

I'll let others give their opinions too.

On Thu, Sep 27, 2012 at 11:39 AM, Michael Mosmann mich...@mosmann.de
wrote:

Am 27.09.2012 09:51, schrieb Martin Grigorov:

Hi,

a dont care about the type issue here.. Maybe i can explain it again in
an
other way:

APanel uses model instance A and the label uses a property model
instance
P
which uses a reference to model instance A.

After calling APanel.setDefaultModel(B) APanel uses model instance
B,but
label uses model instance P which uses model instance A as before. So
the
label does not see any changes, because no one tells the model instance
P,
that it should use B instead of A. I think, there are rare cases for
such
a
usage.

thanks
Michael



Hi,

In this particular code I think the problem is PropertyModel, since
it brings the type unsafety.

Another solution is to make ComponentT, this way we can remove
#setDefaultModel() and have #setModel(IModelT) only and such
problems will go away.
But as discussed in early Wicket 1.4 days this will lead to more
typing. With Java 7 diamonds it is half the typing though.

For now you can use GenericPanel, GenericPage and all FormComponent.

On Thu, Sep 27, 2012 at 10:41 AM, Michael Mosmann mich...@mosmann.de
wrote:

Am 27.09.2012 09:01, schrieb Martin Grigorov:
Hi,

I think, there is a little difference in using setDefaultModel and
setDefaultModelObject .. the first one sets a new model instance, the
second
only change the value in the existing model. Some pseudo-code:

class APanel extends Panel {
APanel(String id,IModelSome model) {
super(id,model);

add(new Label(name,new
PropertyModel(getDefaultModel(),name));
}
}

If you replace the value in model, everything is fine and works as
expected.
If you call setDefaultModel you might think, that everything is fine,
but
its not. A child component does not use getParent().getDefaultModel()
to
get
these changes. I saw a lot of code like this, which leads to trouble,
if
you
change the model and not the value.

If there is no benefit in using setDefaultModel over
setDefaultModelObject i
would like to remove this method. This could prevent many you might
not
got
the full picture how to use wicket the right way errors.

Michael



Hi,

Most of the time it is recommended to use a dynamic model, so there
is
no reason to replace the component's model.
Component#setDefaultModel() gives you semi-dynamic nature - you can
replace the model completely with a new one. Same with
#setDefaultModelObject().

What is the problem you face with it ?

On Thu, Sep 27, 2012 at 9:57 AM, Michael Mosmann
mich...@mosmann.de
wrote:

Hi,

is there any usefull application of Component.setDefaultModel(...)?
IMHO
this Method

Re: wicket 1.5.7 FilterToolbar

[Michael Mosmann]

Ok:)
I allready have an solution for this and now i can change it, so that i will 
still work with wicket6 too..

Thank you:)
--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.



Martin Grigorov mgrigo...@apache.org schrieb:

Hi Michael,

This is improved in Wicket 6.x to:
public T, S FilterToolbar(final DataTableT, S table, final
FilterFormT form,
final IFilterStateLocatorT stateLocator)

T is the type of the model object
S is the type of the sorting parameter

Wicket 1.5.x cannot be changed because it is an API break.

On Thu, Jul 12, 2012 at 8:05 PM, Michael Mosmann mich...@mosmann.de wrote:
 Hi,

 I am not sure, if the constructur of FilterToolbar should be changed
 from

 public T FilterToolbar(final DataTableT table, final FilterFormT
 form, final IFilterStateLocatorT stateLocator)

 to

 public T,F FilterToolbar(final DataTableT table, final FilterFormF
 form, final IFilterStateLocatorF stateLocator)

 ..
 As far as i could see, the type of form and statelocator are ignored
 anyway.

 Michael Mosmann






--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com

wicket 1.5.7 FilterToolbar

[Michael Mosmann]

Hi,

I am not sure, if the constructur of FilterToolbar should be changed
from

public T FilterToolbar(final DataTableT table, final FilterFormT
form,   final IFilterStateLocatorT stateLocator)

to

public T,F FilterToolbar(final DataTableT table, final FilterFormF
form,   final IFilterStateLocatorF stateLocator)

..
As far as i could see, the type of form and statelocator are ignored
anyway.

Michael Mosmann

Re: WICKET-2846 - Store Application in InheritableThreadLocal instead of ThreadLocal

[Michael Mosmann]

Am Mittwoch, den 19.05.2010, 16:48 -0300 schrieb Adriano dos Santos
Fernandes:
 On 19/05/2010 16:36, James Carman wrote:
  What itch are we trying to scratch, here, anyway?  When do folks need
  access to the Application object outside of a request thread?  What is
  the usecase?
 
 I have a piece of code that runs in a timer, and renders a page to a 
 string to be sent via email. So I do need the app object to make a 
 session. I do catch it from a static field.

I use the BaseWicketTester-Class for this kind of stuff.. 

http://www.wicket-praxis.de/blog/2009/12/01/sending-html-email-from-wicket-app/


mm:)

Mouse Position Event Behavior

[Michael Mosmann]

Hi,

I am not sure how to implement something like an mouse position
behavior. I know, that i can use some form and ajaxsubmit behavior. But
that not the way i like it:)

any suggestions are welcome 

michael mosmann:)

Re: Mouse Position Event Behavior

[Michael Mosmann]

Am Donnerstag, den 04.03.2010, 11:19 +0100 schrieb Ernesto Reinaldo
Barreiro:
 http://londonwicket.googlecode.com/files/LondonWicket-Paint.pdf ?
 
 Ernesto

thanks:)

mm:)

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

[Michael Mosmann]

Let's call it wicket 1.5, use java 1.6 and make it happen..
Then, after we finished this, we can try to backport wicket 1.5 to java
1.5 ... if anybody want's it.

mm:)

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

[Michael Mosmann]

Am Dienstag, den 15.12.2009, 13:39 +0100 schrieb Carl-Eric Menzel:
 Carl-Eric Menzel
 Das neue deutschsprachige Wicketbuch:
  Wicket: Komponentenbasierte Webanwendungen in Java
  http://www.wicketbuch.de/

Hi,

.. bei Amazon ist es immer noch nicht lieferbar. Bei dpunkt gibt es
keine Entsprechende Info.. da ich lieber bei Amazon bestellen würde hier
meine Frage: Ist es über dpunkt lieferbar? Wann ist es über Amazon
lieferbar?

Danke:)

Michael Mosmann

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

[Michael Mosmann]

+1 for moving to Java6: if you have to use Java5, you can use wicket
1.4.x. .. (maybe someone will give paid support for wicket 1.4.x :) )

Michael

Re: Session Invalidation Options

[Michael Mosmann]

Am Sonntag, den 29.11.2009, 20:15 +0100 schrieb Erik van Oosten:
 Michael,
 
 What kind of container are you referring to? 

public class MyUserSession implements Serializable
{
  /* hold user relevant stuff */
}

public class MyWicketSession extends WebSession
{
  MyUserSession _container=new MyUserSession();

  public void invalidateUserSessionAndNotWicketSession()
  {
_container=new MyUserSession();
  }
}

 And which session, the 
 servlet session or the Wicket session?

The Wicket session.

Hope this code will make something clear.

mm:)

Re: Session Invalidation Options

[Michael Mosmann]

Hi,

 I've got a business requirement that session invalidation must not be a 
 disruptive event (no expired session warning or anything similar).

Is session invalidation an requirement? Put a container into your
session and throw it away if you want to invalidate the user session.

mm:)

Wicket Stuff commit access

[Michael Mosmann]

Hi,

i would like commit access for wicket stuff for a college. His sf id is
'blade23' ..

thank you

Michael

Wicket Stuff commit access

[Michael Mosmann]

Hi,

I would like commit access for wicket stuff. I plan to work on a new
subproject.

My sourceforge id is 'mosmann'.

thanks..
mm:)

Re: FormComponent Input Change

[Michael Mosmann]

Am Freitag, den 30.10.2009, 08:54 -0200 schrieb Pedro Santos:
 In the case of a user write an code
 were only characters are correct, the setObject method of component model
 fix the characters case before call super.setObject

i did'nt want to set the model value.. only the input.

Michael

Re: Wicket Component Overview

[Michael Mosmann]

Hi,

 I used Umbrello UML on linux to draw the diagram, by hand.

I tried this first, but i failed. It was to much work.. and it was more
fun to solve this by some coding.

 And the resource finding algorithm could benefit from a pluggable Strategy
 pattern, for example to group localized resources by directory instead of
 appending the locale to their name (/css/en/style.css instead of
 /css/style_en.css).

that's interesting.. 

 BTW, how can I draw the attention of  the core team to this thread ? I'd
 love to have their opinion on all this.

I am sure, the read your posts too.. :)

mm:)

Wicket Component Overview

[Michael Mosmann]

Hi,

i did some wicket component diagram stuff (model, listener etc.)

http://www.wicket-praxis.de/blog/2009/10/16/wicket-component-overview/

glad to see some reply on this..

mm:)

Re: Wicket Component Overview

[Michael Mosmann]

Hi,

 I did the same with the Models a few weeks ago - see the attached
 image.

hmm.. no image attached.. 

 BTW, don't you think their hierarchy is a bit weird ?

what's the weird part?

mm:)

Re: OT: Is IModel an empty interface?

[Michael Mosmann]

 And regarding the excellent wiki page: that's one thing I don't like  
 about wicket. Documentation is
 not were in belongs, in the code or at least checked in with the code.  
 I always have to figure
 it out by myself if some wiki page is up-to-date or not.
 I really never had such a hard time understanding a framework! (but to  
 repeat myself, I'm not used
 to think in components when it comes to web design, so that's probably  
 just me)


 Take for example Spring or Hibernate: the latest reference always  
 comes with the distribution and
 the code is documented very well. (and maybe better aligns to my  
 thinking)

IMHO the wicket code is documented very well.. but you have to get the
basic concept. In this point wicket does not differ from spring or
hibernate. Sure, the wiki documentation could be better, but the best
way to learn wicket is from examples (quickstart is your friend) and
books.

But one thing is important: as a web developer you have to leave
anything behind. Don't try to do things like you did it before with any
other framework.

Don't care about how wicket manages request/response  ... you only have
to know which methods are called during requests. Use models (if you
don't know why, don't care .. it takes some time to get this).

mm:)

If you don't know, which book: http://www.manning.com/dashorst/

wicket default theme

[Michael Mosmann]

Hi,

do we have something like a default theme for wicket apps? Every grails
app comes with a nice theme right from the start, ... i think we need
something similar.

-
package org.apache.wicket.extension.theme;

public class WicketDefaultTheme
{
  public static void apply(Page page)
  {
page.add(... HeaderContributor with some css ...) 
  }
}
-

mm:)

German Wicket Book

[Michael Mosmann]

Hi,

.. is there any chance to get my (german) book

http://www.hanser.de/978-3-446-41909-4

into the list?

http://wicket.apache.org/books.html

thanks.

Michael

Re: 1.4.1 release?

[Michael Mosmann]

Am Donnerstag, den 20.08.2009, 14:12 +0200 schrieb Jörn Zaefferer:
 It looks like all issues for 1.4.1 are fixed:
 https://issues.apache.org/jira/browse/WICKET/fixforversion/12314113
 
 When can we expect the 1.4.1 release? There's a certain bugfix I'd
 like to include in my application...

IMHO 1.4.1 is released.

mm:)

Re: Radio and Radio Group problems

[Michael Mosmann]

Hi,

.. i am not sure. The model of RadioGroup should contain, wich item is
selected. The model of Radio should reflect the associated value. So if
model of RadioGroup contains fr and Property selected of item nr. 3
is fr this Radio is selected.

maybe this will help.. 

mm:)

 I have a problem when using the Radio component.
 Using a list of languages, where each item is a NameWrapper object with 
 a property selected. The property selected is associated to the 
 radio component.
 However, when presenting to the user the corresponding list of radios, 
 the language Polish is true, and not English (it should be the selected 
 option).
 
  listLanguages.add(new NameWrapper(English, en, , true));
  listLanguages.add(new NameWrapper(German, de, , false));
  listLanguages.add(new NameWrapper(French, fr, , false));
  listLanguages.add(new NameWrapper(Italian, it, , false));
  listLanguages.add(new NameWrapper(Polish, pl, , false));
 
  final RadioGroup groupQuery = new RadioGroup(groupLanguagesQuery, new 
 Model());
  listLanguagesQuery = new ListView(listLanguagesQuery,listLanguages) {
 protected void populateItem(ListItem item) {
  String lang = 
 ((NameWrapper)item.getModelObject()).getName();
 item.add(new Label(nameLanguageQuery, new 
 StringResourceModel(lang, this, null,)));
 item.add(new Radio(checkLanguageQuery, new 
 PropertyModel(item.getModel(), selected),groupQuery));
 }
 };
 groupQuery.add(listLanguagesQuery);
 
 Any ideas? I really need to solve this issue.
 
 Thank you so much.

Re: Radio and Radio Group problems

[Michael Mosmann]

Am Mittwoch, den 15.07.2009, 16:02 +0200 schrieb Trojahn, Cassia:
 I had tried this option and it does not work.

can you send me some more code (zip?) ..

please use 
http://wicket.apache.org/quickstart.html

mm:)

RedirectRequestTarget SC_MOVED_PERMANENTLY

[Michael Mosmann]

Hi,

can we extends RedirectRequestTarget somehow, so that setting response
status code to SC_MOVED_PERMANENTLY is done in an easy way?

michael

Re: RedirectRequestTarget SC_MOVED_PERMANENTLY

[Michael Mosmann]

Am Sonntag, den 28.06.2009, 13:53 +0200 schrieb Martijn Dashorst:
 A patch is welcome :)

as jira-ticket or as email with some files?

mm:)

Re: RedirectRequestTarget SC_MOVED_PERMANENTLY

[Michael Mosmann]

Am Sonntag, den 28.06.2009, 07:43 -0500 schrieb Jeremy Thomerson:
 JIRA - always.

will do..
as quickstart-app?

mm:)

Re: [patch (sort of)] Remove empty java package directories

[Michael Mosmann]

Hi,

i am happy to tell you that i finished my wicket book project (german:
http://www.wicket-praxis.de/blog/2009/05/27/wicket-praxis-als-buch/ )

thank you for your support (not knowing, that i am writing a book) and
for this great framework. maybe i could help to attract more people to
wicket.

thanks a lot
michael mosmann

Re: refactor Item to interface

[Michael Mosmann]

Am Freitag, den 22.05.2009, 09:11 +0300 schrieb Joe Fawzy:
 Hi allthanks for ur attention
  my code is like

 and as i said if there is another way, i still think it's better to program
 to an interface

i am not sure, if i understand your problem.. but i did something like
this in an (IMHO) similar case..

interface FactoryResult
{
  public Component getComponent();
}

interface Factory
{
  public FactoryResult getSomething(String id, SomeData data);
}

... so then you can do

populateItem(ListItem item)
{
  result=factory.getSomething(id,item.getModelObject());
  item.add(result.getComponent());
}

.. maybe this will help.

michael mosmann

Re: refactor Item to interface

[Michael Mosmann]

Hi joe,

 much like i think ur code
 is,u r working around the problem  ,

yes.. sure...

  i think that this is not the natural
 way of doing things , u have a double indirection , an interface thet return
 another interface which contain the component ,WHY???

because in java you can not have multi-inheritance .. if you have a
factory for creating some stuff with your own baseclass the only way to
get the resulting component is an interface.. i know, it is a special
use case ..

 my real problem is not making something work, no , i have a working code
 but i am talking about different thing here , it is about HOW thing
 naturally work in an OO fashion , without any unnecessary nesting
 nesting involve making the reusable MasterDetailPanel and its component
 authers agree on string is which is error prone

ok, i missed this point.. sure, my way is only a work around, .. 
maybe scala is a better base for clean OO fashioned jvm development.. 

.. not so helpful as i hoped.. :)

michael

Re: refactor Item to interface

[Michael Mosmann]

Am Freitag, den 22.05.2009, 12:33 +0300 schrieb Joe Fawzy:
 Hi dear Michaelsorry if my response was'nt as nice as my feeling toward ur
 nice cooperation ,sorry again

no problem:)

 really Scala is the way i thought , its traits feature is really helpfull in
 combining features and behaviors into component

yeah..

 scala ide support is still early, 

i know.. that's a pity

mm:)

link to css with parameter

[Michael Mosmann]

Hi,

.. can someone give me an advice, how to do something like this:

head
  link rel=stylesheet type=text/css
href=bla/blub/style.css?typ=3
/head

thanks
mm:)

Re: link to css with parameter

[Michael Mosmann]

Thank you.. but found solution.. 

- build dynamic HttpHeaderContributor and write urlFor(resourceRef,
valueMap)
- own ResourceReference overrides newResource()
- in this Resource call getParameters()

that's it

mm:)

Re: VOTE: Rename Apache Wicket to Apache WicketFX

[Michael Mosmann]

Am Mittwoch, den 01.04.2009, 15:34 +0300 schrieb Nikos Pougounias:
 Hi Martijn,
 I would like to ask, how will it be easier to obtain JSR status by changing
 the name?

The FX makes the difference. Sun is also spending some money if you use
FX as part of any java framework. I got some rumors, that even spring
will came out with SpringFX or Springframework CoreFX.. but lost the
link.

mm:)

Re: wicket-library.com

[Michael Mosmann]

Am Dienstag, den 31.03.2009, 13:02 -0500 schrieb Jeremy Thomerson:
 Who runs wicket-library.com and how often are the wicket-examples updated to
 the most recent version?

i think, it's just spam.. it open add pages on every klick..

mm:)

Re: wicket blogs

[Michael Mosmann]

 Done - site should update shortly, I believe...
 /Gwyn

thanks
:)

mm:)

RedirectPage

[Michael Mosmann]

Hi,

Does anyone had successfully used RedirectPage with a Page instance?
Everything i got is some Page Expired messages.

thanks
Michael Mosmann

p.s.: wicket 1.4 rc2

Re: wicket blogs

[Michael Mosmann]

Am Mittwoch, den 25.03.2009, 09:28 -0700 schrieb Igor Vaynberg:
 its a wiki, you can do it yourself afaik

i did mean this page:

http://wicket.apache.org/blogs.html

:)

 On Wed, Mar 25, 2009 at 8:54 AM, Michael Mosmann mich...@mosmann.de wrote:
  Hi,
 
  can someone add my blog to the wicket blogs page?
 
  http://www.wicket-praxis.de/blog/
 
  thank you:)
 
  michael mosmann

Double Submit Bug in Palette?

[Michael Mosmann]

Hi,

i wonder, if i do something wrong. But first the Code:


import java.util.ArrayList;
import java.util.Arrays;
import java.util.Collection;
import java.util.List;

import org.apache.wicket.extensions.markup.html.form.palette.Palette;
import org.apache.wicket.markup.html.WebPage;
import org.apache.wicket.markup.html.form.Button;
import org.apache.wicket.markup.html.form.ChoiceRenderer;
import org.apache.wicket.markup.html.form.Form;
import org.apache.wicket.model.IModel;
import org.apache.wicket.model.Model;

public class TestPalettePage extends WebPage
{
  enum TestEnum  {  E1,E2,E3,E4 };
  
  IModelListTestEnum _model=(IModelListTestEnum)(new Model(new
ArrayList(Arrays.asList(TestEnum.values();

  IModelCollectionTestEnum
_choices=(IModelCollectionTestEnum)(new Model(new
ArrayList(Arrays.asList(TestEnum.values();

  
  public TestPalettePage()
  {
Form form=new Form(form)
{
  @Override
  protected void onSubmit()
  {
System.out.println(Selected: +_model.getObject());
  }
};

ChoiceRendererTestEnum choiceRenderer=new
ChoiceRendererTestEnum(name,ordinal);
PaletteTestEnum palette=new
PaletteTestEnum(palette,_model,_choices,choiceRenderer,3,true);

form.add(palette);
form.add(new Button(submit));

add(form);
  }
}


In this example onSubmit is called twice. The second time the output is
  Selected: []
which is wrong.

Bug?
We are using 1.4-rc2, but the same error exist in 1.4-rc1 and 1.3.5.

Thanks.
mm:)

Re: Double Submit Bug in Palette?

[Michael Mosmann]

Am Dienstag, den 03.03.2009, 08:18 -0800 schrieb Igor Vaynberg:
 quickstart

what does this mean?

  and jira.

done.

mm:)

Buxfix for Palette

[Michael Mosmann]

How can i send some bugfixes for
org.apache.wicket.extensions.markup.html.form.palette.Palette?

---
protected void onBeforeRender()
{
if (!hasBeenRendered())
{
initFactories();
}
super.onBeforeRender();
}
---

onBeforeRender is wrong. Fails if form is not visible.
!hasBeenRendered is always true, so initFactories called more than
once.

mm:)

p.s.: using wicket 1.3.5.

Re: wicket:extend variation template search order

[Michael Mosmann]

Am Freitag, den 09.01.2009, 16:39 +0100 schrieb Martijn Dashorst:
 On Fri, Jan 9, 2009 at 1:06 PM, Michael Mosmann mich...@mosmann.de wrote:
  We are using Wicket 1.3.3.
 
 Maybe this is your problem?

maybe..
will test this soon.. (with 1.3.5 and 1.4)

mm:)

p.s.: got around this with a better solution :)

Enterprise Application

[Michael Mosmann]

Hi,

Can anyone tell me an example of an enterprise application developed
with wicket? In an discussion some people said, that they think, that
wicket is not suited for enterprise scaled applications. what you see,
is what you believe could solve this problem.

thanks

Michael Mosmann

Re: Enterprise Application

[Michael Mosmann]

Am Montag, den 18.08.2008, 12:55 +0200 schrieb Witold Czaplewski:
 Hi Michael,
 
 here [1] you find a list with sites using wicket.

i know.

  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:)

Re: Enterprise Application

[Michael Mosmann]

Hi,

 Fabulously40.com survives digg.com effects.

Thanks for this information.:)

 finan.nl doesn't have a public application, but their Wicket web based
 solution will be used inside major banks *world wide*.

good example...

 Sounds like me that these companies are able to make Wicket work on a big 
 scale.

I think the same way. I am not the guy who has doubts about it.

 It also depends on what you call enterprise application...

I am looking for complex applications on the client side.

 Vocus is a SaaS solution for high schools in the Netherlands. Though
 250-300 concurrent users isn't that much of a scaling problem, we do
 need to handle 120K-200K requests per day. It is quite an intensively
 used application, with a very broad functionality base.

Can you post a link? Is there any public information?

Thanks
Michael Mosmann

Re: Enterprise Application

[Michael Mosmann]

 It was featured at the Wicket meetup in november last year, the slides
 are available here:
 
 http://www.slideshare.net/dashorst/wicket-live-on-stage
 
 It is an application specific for dutch educational institutions
 tailored to the Dutch laws, so
 there is little  value in international documentation. If you can read
 dutch (German is just
 dutch with an accent :), you can take a  look at:
 
 http://vocuslis.nl/
 
 Another good example of a complex, scalable website built with Wicket
 is teachscape (Eelco,
 Igor and Matej work/have worked there). It handles much more users
 than Vocus, and is also
 a complex beast. More information here:
 
 http://teachscape.com
 
 Martijn
 

thanks for your information.. the will help a lot. :)

Michael Mosmann