Hi viktor dev-team,
I am very happy to see all the progress that has been done on the platform side. One update I’m not sure that i’m happy with is this new feature:
• Adjusted ChildEntityManager to open child entities in a new tab
I Foresee problems on this side for a lot of apps we have now:
How we use the ChildEntityManager a lot now is in a ‘project’ entity. It was a bit of a nuisance that when going into the ChildEntity the message pops up that you have to save the parametrization of the parent (when a new child entity was created). The benefit of that is that you know for sure that the parametrization of the project is saved and so: the user always uses the latest version of the parent.
Now: by opening the child in a new tab will result in two things:
- the users (possibly) is editing on two places in parallel which rely on eachother (we frequently get “last_saved_params” on the parent: but now it isn’t garanteed that this indeed is the last params.
- the parent is blocked for other users if it stays open → multiple users could work on one project.
Did you address these things in your design? Because IMO this is a breaking change for some designs…
At least I would like to have the option (as parameter of the childentitymanager) to decide as developer if a new tab should be opened.
Thank you for pointing this out. I’ve already added this to our internal issue tracker, but will try to see if I can retrieve more information about how this change came about, and to see how we can improve on this.
It seems that this change was put about for cases where a
ChildEntityManager is added within an editor that has a few steps. If a user would create an entity, and enter the entity, then upon return they would have to start again from step 1.
That makes sense, but even in that case: there is no guarantee that the last_saved_params of the parent is actually the parametrization that the end-user thinks he is using.
It is implied (for an end-user) that you can work on multiple entities simultaneously. It feels a bit that this messes with the statelessness of VIKTOR, the hard thing is that the end-user doesn’t understand that he has to save the current state first before they are used correctly in a child-entity. Imagine if a structural calculation is performed based on incorrect information from a parent-entity because the user forgot to save it? I don’t like that unreliability, and reliability should outweigh going through a few extra steps for the end-user.
I think the best fix would be: let the developer decide what is desirable in a situation.
I completely agree. I’ve raised your points internally. I’ll keep you updated on the progress that is made on this subject.
We have rolled this feature back, because we agree with your concerns.
We will work on a finding a solution which improves both cases!