Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixed unique ID generation for some cases #668

Merged
merged 7 commits into from
Feb 17, 2019
Merged

Conversation

exyi
Copy link
Member

@exyi exyi commented Feb 9, 2019

We are now using unique id counter instead of relying on List.Count,
which solves problems with controls added in a strange order (like
x.Add(controlA); x.Add(controlB); x.Remove(controlA); x.Add(controlC),
where B and C remain in x with the same id).

When a control is added to the collection, it's id is assigned only if
it's parent also has the id. And when the id is assigned, it's assigned
recursively to the entire subtree that does not have any ids. This solves
problems with entire hiearchies being added into the control tree (that
are heavily used in DotVVM BP)

@quigamdev Could you please check that it really solves these problems in BusinessPack and that it does not create new ones?

exyi and others added 7 commits February 9, 2019 13:44
We are now using unique id counter instead of relying on List.Count,
which solves problems with controls added in a strange order (like
`x.Add(controlA); x.Add(controlB); x.Remove(controlA); x.Add(controlC)`,
where B and C remain in `x` with the same id).

When a control is added to the collection, it's id is assigned only if
it's parent also has the id. And when the id is assigned, it's assigned
recursively to the entire subtree that does not have any ids. This solves
problems with entire hiearchies being added into the control tree (that
are heavily used in DotVVM BP)
@quigamdev
Copy link
Contributor

I have tested these changes in DotVVM BusinessPack and I have committed change of order of IDs assignation and execution of lifecycles. Everything else seems to be ok. Tests are passing, so I will merge this PR.

@quigamdev quigamdev merged commit 1ef0ba4 into master Feb 17, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants