New Feature: opening child entities in a new tab ChildEntityManager

🚀 Support (Q&A) 🐛 Bug & Error Reports
1

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.

1 Like
2

Hi Wichard,

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.

3

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.

4

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.

5

I completely agree. I’ve raised your points internally. I’ll keep you updated on the progress that is made on this subject.

6

Hi @Wichard,

We have rolled this feature back, because we agree with your concerns.

We will work on a finding a solution which improves both cases!

1 Like