Question

Object only editable when not committed

4

Good morning. I have a pretty common usecase and I also have a working solution, but I wonder if there is a nice best practice for it. I want an object to be editable, as long as it is not committed to the database. Once it is committed, it should be read only. Currently, I have to access rules. One defines the read access and does not have any constraint. The second one defines the write access and has the constraint “[false()]”. It works but it looks ugly to me. Maybe I only need to redefine my definition of “nice code” but I wonder if there is any better solution.

asked 2020-07-20

Andreas Blaesius

3 answers

Eric Tieniber · Answer 1 · 2020-07-20

Hmm yes, that security rule is definitely obscure. Perhaps a good idea for the idea forum.

One other design would be to use a helper or staging entity to store the “draft” data, and then save that into a persisted, read-only record when it’s saved. Then you get clean security rules, but at the cost of maintaining an extra entity.

Tim v Steenbergen · Answer 2 · 2020-07-20

Nice! Learned something again: in the Access rules, the Create-rights don't check the XPath constraints.

Setting the constraint to "[false()]” does get you the behavior you want, but I agree that it is ugly in the sense that I need some extra explanation whenever I stumble upon code like that. I am pretty sure that there is no best practice for it. The best alternative I can think of is adding a false string-comparison that explains its purpose:

['This entity is creatable but once created, it ' = ' not modifiable.']

I consider this still ugly, but I would need no further explanation.

Nirmalkumar · Answer 3 · 2020-07-21

Another approach I have seen other developers doing is, have an attribute in the entity itself called ‘isNew’ which is set to true when object is created. And set to false when object is committed. This ‘isNew’ will be more inline with isNew check that Mendix offers as well. With this, we might also have a cleaner Access rules based on this boolean.

May be we can also try to capture the details with NPE and clone it to Persistable entity. This way, the persistable entity always have one Read only access rule and NPE can be delegated for create purposes.