You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We use a lot of value objects with Neos 9.0. One of the reasons for that is a better type safety.
For example: Because we know, that NodeAggregateId can't contain certain characters, we can safely use them for delimiters (e.g. in Cache entry/tag identifiers).
The constraints for WorkspaceName are really loose currently: /^[\p{L}\p{P}\d \.]{1,200}$/u (basically 1 - 200 characters of any class).
We should reduce length (how many characters are allowed) and width (which characters are allowed) drastically IMO.
As a side effect we could decide to omit the SHA1 hashing for cache tags
The text was updated successfully, but these errors were encountered:
Also related, during the discussion of exposing the workspace name in the node we considered the idea of virtual workspace names:
WorkspaceName::fromString() must be stricter without colons (so that we could allow in the future for extension, e.g. WorkspaceName::detached(ContentStreamid $csId) (with an internal representation like “cs:”)
idk if this is still legit as the discussion is age old now and we only wanted to limit it to be able to implement future ideas
We use a lot of value objects with Neos 9.0. One of the reasons for that is a better type safety.
For example: Because we know, that
NodeAggregateId
can't contain certain characters, we can safely use them for delimiters (e.g. in Cache entry/tag identifiers).The constraints for
WorkspaceName
are really loose currently:/^[\p{L}\p{P}\d \.]{1,200}$/u
(basically 1 - 200 characters of any class).We should reduce length (how many characters are allowed) and width (which characters are allowed) drastically IMO.
As a side effect we could decide to omit the
SHA1
hashing for cache tagsThe text was updated successfully, but these errors were encountered: