Re: Stable behavior ids

2020-05-15 Thread Andrea Del Bene
+1 On 15/05/20 09:01, Emond Papegaaij wrote: Hi All, With Sven's comment in mind and the fact that Andrea did not directly understand the implications of the new method, I decided that the new method was indeed not a good idea. Don't worry about me, it appends to me quite often to not

Re: Stable behavior ids

2020-05-15 Thread Sven Meier
Hi Edmond, +1 from me. Thanks Sven On 15.05.20 09:01, Emond Papegaaij wrote: Hi All, With Sven's comment in mind and the fact that Andrea did not directly understand the implications of the new method, I decided that the new method was indeed not a good idea. It complicates the API and

Re: Stable behavior ids

2020-05-15 Thread Emond Papegaaij
Hi All, With Sven's comment in mind and the fact that Andrea did not directly understand the implications of the new method, I decided that the new method was indeed not a good idea. It complicates the API and brings too little benefit. I've updated the PR once more to clarify the impact and

Re: Stable behavior ids

2020-05-11 Thread Emond Papegaaij
Hi Sven, I agree with you that this method is not very nice. It indeed complicates the API even more and it is very hard to explain why it is needed. It however is the most efficient implementation I could think of. There is a compromise we can use: we can freeze all behavior ids when one is

Re: Stable behavior ids

2020-05-11 Thread Sven Meier
Hi Edmond, I agree that we should get rid of BehaviorIdList, it's probably the most inefficient implementation. But I'm against complicating matters even more with an additional method - at least until we know how the implementation will be improved post-9.0. Why would anyone need a

Re: Stable behavior ids

2020-05-08 Thread Emond Papegaaij
Hi Sven, Yes, this is all about optimization. It already was. It is not difficult to keep stable ids for behaviors, you can simply store an id per behavior. However, this is very inefficient. A long time ago, the decision was made to only store these ids when needed. Unfortunately, there is no

Re: Stable behavior ids

2020-05-07 Thread Sven Meier
Hi Emond, I'm not happy with that method. It's one additional method like many others in Wicket which are not clear what they are good for. I didn't understand the description. What's the reason for this stable id hassle? Why can't the id be stable when a behavior wants it? Is this really

Re: Stable behavior ids

2020-05-07 Thread Emond Papegaaij
Hi all, I've updated my pull request at https://github.com/apache/wicket/pull/432 . I've added the method I described and changed the current code to use this new method. Also, the documentation is updated and clarified to better reflect the rules a developer has to follow to keep stable ids.

Re: Stable behavior ids

2020-05-07 Thread Emond Papegaaij
Hi Sven and Andrea, Sven: All tests still pass, I've also updated the ImmutableBehaviorIdsTest with some additional checks. However, the tests I've seen so far are not very exhaustive on this part. Many of them also pass with a bit of luck :) Andrea: What I mean with 'moved to the front' is that

Re: Stable behavior ids

2020-05-07 Thread Sven Meier
Hi, we have a test for stateless behaviors: org.apache.wicket.ajax.markup.html.form.StatelessAjaxSubmitLinkTest We should just make sure it still works. Have fun Sven On 07.05.20 12:13, Andrea Del Bene wrote: On 07/05/20 10:37, Emond Papegaaij wrote: Hi Martin, I know what these id's

Re: Stable behavior ids

2020-05-07 Thread Andrea Del Bene
On 07/05/20 10:37, Emond Papegaaij wrote: Hi Martin, I know what these id's are for, and this still works as expected. However, your claim about stable id's on stateless pages currently does not work as you describe. The id's of behaviors is stored in the component they are added to, also

Re: Stable behavior ids

2020-05-07 Thread Emond Papegaaij
Hi Martin, I know what these id's are for, and this still works as expected. However, your claim about stable id's on stateless pages currently does not work as you describe. The id's of behaviors is stored in the component they are added to, also when the component is stateless. As you said, a

Re: Stable behavior ids

2020-05-07 Thread Martin Grigorov
Hi Emond, The behavior id is something internal to Wicket. It is used *by* Wicket to find the requested behavior in a Component. For example if a Component has more than one Ajax behaviors (yes, Ajax behaviors could be stateless too since 7.4.0. Before that there was a project in WicketStuff) it

Re: Stable behavior ids

2020-05-06 Thread Emond Papegaaij
Hi, While running, I came up with a solution for which only a minor change to the contract of the method is needed: ids for stateless behaviors will be stable within a single requests, but can change over requests. I think this is reasonable, given the way stateless components work. I would like

Re: Stable behavior ids

2020-05-06 Thread Emond Papegaaij
Hi Andrea, Stateful is fine, stateless is not. A component cannot keep a stable id when it's stateless. I'm trying out a change that forbids getBehaviorId() for stateless behaviors, and I'm hitting a few tests with stateless ajax. I don't see how this is supposed to work anyway. We request the

Re: Stable behavior ids

2020-05-06 Thread Andrea Del Bene
On 06/05/20 16:52, Emond Papegaaij wrote: Hi all, During my refactoring of the component state (WICKET-6774) I noticed that behavior ids are currently stored in a very inefficient way: an ArrayList is added to Component data to store references to behaviors with a stable id. On my branch I