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

The vote is closed with: 1x Yes, remove IDetachable from IModel 7x No, keep IModel detachable So we can conclude that IModel will remain detachable. Best regards, Emond On maandag 3 april 2017 09:38:03 CEST Emond Papegaaij wrote: > Something went wrong sending this mail. I did write some more,

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

On dinsdag 4 april 2017 00:24:56 CEST Pedro Santos wrote: > > 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 suspected the discussing was becoming is a bit lengthy for everyone to follow. So to make

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

[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

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

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.

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

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

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

[X] No, keep IModel detachable I can see Pedro's point. A Model really is only something that can get and set. But detaching is such an important part of the lifecycle of many Wicket things (including Models) that I think it is an acceptable tradeoff in clarity to have IModel extend IDetachable.

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

[-1] No, keep IModel detachable Sven On 03.04.2017 09:38, 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

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

[x] No, keep IModel detachable Even I understand Pedro's concern, Emond raised one of the most important point here: detaching is entirely part of the model life-cycle.

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

[ X ] No, keep IModel detachable Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov 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

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

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

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

On Mon, Apr 3, 2017 at 9:20 AM, Emond Papegaaij wrote: > TL;DR Vote at the bottom > > On zondag 2 april 2017 00:25:12 CEST Pedro Santos wrote: > > > The major concern I have with this change is that it does not improve > > > anything. This change has impact on both

[VOTE] Proposal to remove IDetachable from IModel hierarchy

TL;DR Vote at the bottom On zondag 2 april 2017 00:25:12 CEST Pedro Santos wrote: > > The major concern I have with this change is that it does not improve > > anything. This change has impact on both the calling and implementing > > side of detach. Neither side becomes easier. > > It does

Re: Proposal to remove IDetachable from IModel hierarchy

> Most of our models have detach logic. However, we do not have that many custom > model implementations. Most of these detach implementations are custom types > implementing IDetachable and those methods are not empty either. So you are good here, all those detachable model specializations will

Re: Proposal to remove IDetachable from IModel hierarchy

On donderdag 30 maart 2017 17:49:40 CEST Pedro Santos wrote: > > 1674 calls to IDetachable.detach() from our codebase, most for models > > hard to conclude anything from this number, because this proposal didn't > change the most commonly used models abstractions: > LoadableDetachableModel,

Re: Proposal to remove IDetachable from IModel hierarchy

> It's difficult to get exact numbers, but here are some: > 48137 java files, 74565 class files, not all wicket related, that's > the entire codebase I'm working on thanks for sharing > 1674 calls to IDetachable.detach() from our codebase, most for models hard to conclude anything from this

Re: Proposal to remove IDetachable from IModel hierarchy

It's difficult to get exact numbers, but here are some: 48137 java files, 74565 class files, not all wicket related, that's the entire codebase I'm working on 1674 calls to IDetachable.detach() from our codebase, most for models 1338 implementations of detach(), I don't know how many come from

Re: Proposal to remove IDetachable from IModel hierarchy

Hi Ernesto, this proposal aims to provide a semantically correct interface. Wicket core will remain being the one responsible to handle user's models lifecycle, as Emond correctly pointed this out: > Storing state directly in components is > considered bad practise. The same is true for

Re: Proposal to remove IDetachable from IModel hierarchy

Emond, The numbers from wicketstuff: 2957 classes in total 71 empty detaches causing compilation errors 34 in wicket-fondation 2 detache methods that werent a dummy empty methods; on in a test case in LazyModelTest; one in the FutureModel in wicketstuff-minis project The project I'm currently

Re: Proposal to remove IDetachable from IModel hierarchy

Totally agree with Ernesto. François > Le 30 mars 2017 à 09:04, Ernesto Reinaldo Barreiro a > écrit : > > Hi, > > As a wicket user I would hate to have to ask myself if my model are > detachable or not. I work as freelance wicket consultant and I have got to > the

Re: Proposal to remove IDetachable from IModel hierarchy

Hi, As a wicket user I would hate to have to ask myself if my model are detachable or not. I work as freelance wicket consultant and I have got to the opportunity to see quite a few wicket projects, most of them already started/mature projects, and the hard time some developers have to figure out

Re: Proposal to remove IDetachable from IModel hierarchy

On Wed, Mar 29, 2017 at 11:03 PM, Pedro Santos wrote: > > -1 > > is it a veto or a vote against the proposal? > It means "I don't like the proposal" Honestly I don't really know how vetoing works here at Apache... > > Pedro Santos > > On Wed, Mar 29, 2017 at 4:34 PM,

Re: Proposal to remove IDetachable from IModel hierarchy

On woensdag 29 maart 2017 17:02:05 CEST Pedro Santos wrote: > Hi Emond, > > > It is an integral part of the lifecycle of IModel > > Most of the models in Wicket and Wicketstuff have no detach logic, hardly > an integral part. Just because not all implementations need an implementation of

Re: Proposal to remove IDetachable from IModel hierarchy

Hi Emond, > It is an integral part of the lifecycle of IModel Most of the models in Wicket and Wicketstuff have no detach logic, hardly an integral part. > One could say that the sole purpose of the detach traversal is to detach all models. Wicket detaches all components in the page in

Re: Proposal to remove IDetachable from IModel hierarchy

Fully agree with Emond! As a user I will hate such kind of change. Several years ago this change might be OKish, but now with Java 8 default methods it would be insane to break everyone's code when default methods make it invisible. Until 7.x I'd have to add empty impl for detach() when I don't

Re: Proposal to remove IDetachable from IModel hierarchy

Hi Pedro, I fail to see why it is a problem for IModel to be IDetachable. It is an integral part of the lifecycle of IModel. One could say that the sole purpose of the detach traversal is to detach all models. A model knows how to retrieve data, update data and to detach its internal

Re: Proposal to remove IDetachable from IModel hierarchy

>From user's perspective this is a symmetrical problem. This sadness is carried over to an user in the other side, in need to avoid any detach logic or processing in his component or model if the target model isn't detachable. Right know he would have to come up with his own marker e.g.:

Proposal to remove IDetachable from IModel hierarchy

Hi team, Not every model is detachable, but right now all models extends from IDetachable because this contract is forced to any implementation for IModel. The only way users have to communicate their model isn't detachable, for their own purpose, is by creating their own mechanism; but I think