+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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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 have eliminated this ArrayList,
greatly reducing
17 matches
Mail list logo
