Closed dresslerdemos closed 3 months ago
Beside
Another feature may be to return a different interface after a setter was used, so that previously used setters are not suggested for further calls.
which was scrapped, the ideas laid out above have been implemented.
Currently the
getProperties
method must return a list ofPropertyBuilder
instances. The has disadvantages:PropertyBuilder
instance, which allows to return multiple instances for the same property name. The behavior when such thing is done is undefined.getProperties
method it is not clear what effect the order of the list has.getProperties
implementation the methodscreateAttribute
,createToOneRelationship
andcreateToManyRelationship
can be used to easily create and configure properties. However, in case the instance needs to be adjusted further down the logic it needs to be saved into a variable. With many properties this becomes hard to manage. A better approach would be if the properties were available via properties or getters in a corresponding class. This class could be the resource type itself, utilizingproperty-read
magic, a separate class generated from annotations in the resource type class or the entity class or something different.PropertyBuilder
class seems too generic. There should be at least separate classes for attributes and relationships. Relationships may be differentiated into to-many and to-one relationship classes. Another feature may be to return a different interface after a setter was used, so that previously used setters are not suggested for further calls. This can be archived by automatically generating the interfaces. When this is explored further one needs to consider that this feature may be confusing during usage and may even hinder code writing in cases where the instance needs to be saved into a variable to call an already used setter again later, depending on some conditions.