i thought of a few scenarios where it makes sense to have a soft reference to to an entity and expose it through an UI for the user with a link to the reference. A very good example of this is the screen history, where every edit screen is shown in history log.
What i would se as a very good improvement is to get a kind of an API for reuse of other purposes like:
General follow-up screen for entites, where you can create a resubmission for any kind of business instances
persistent notification screen, where if anything to a particular entity happens, a message (notification) is sent to particular users
Basically anything that is not related to a particular type of business entity.
I’m not sure how this API could look like, but some kind of reuse of the ideas behind screen history would be beneficial (Although it’s not a big deal copy the the parts of the source code of the ScreenHistoryEntity and the code of the screen-history-browse.xml). Perhaps this is a thing you can evaluate.
When i tried it myself i made a string field “softReference” of type string and store the result of an EntityLoadInfo in the column like this: “sec$Role-0c018061-b26f-4de2-a5be-dff348347f93-role.browse” (perhaps, EntityLoadInfo might even be this SoftReference type…)
The next thing is the ability to display this reference on the UI.
I think there are two parts of this. The first thing is the caption that gets displayed. If i get it correctly, in the screen history browser, you stored the caption explicitly and just displayed it. When i tried it, i used the entityLoadInfo reference to pull out the instanceName of the Entity.
Okay, now I understand what you mean. I think it makes perfect sense, but how often it will be used in an average enterprise app? I mean, maybe just an example of using EntityLoadInfo would be enough? From your description, I see that implementation of such “soft reference” is quite feasible and transparent on the application level, or am I wrong?
well, yes you are right in some sense. The question how often this kind of association will be used - i don’t know. Coming from a Rails background, there was a thing called “polymorphic association”, which allowed to have arbitrary entities (employee, product, customer) to have references to e.g. a document entity. This is a thing that is just totally missing in the JPA world. I know that in Hibernate native there is something like this with the @Any annotation (further examples: Polymorphic Association Mapping with Any Relationship in Hibernate) but in JPA i didn’t found anything about it.
So the next thing then is to not deal with the problem on a persistence layer level, but more on an application level with something like “soft references”.
Regarding the question, if it should be part of the problem, or let it be the problem of the application at hand - i don’t know either Yes, the implementation is quiet straight forward, as there is nothing really complicated that therefore has to be encapsulated in a framework. But oftentimes it’s not only about the question if is complicated or cumbersome enough to be part of the underlying infrastructure, but also about the convention fact and the “best practices” baked in (one example of this would be your experience regarding the caption - why it makes sense to “duplicate” the information in the db, what impacts that will have on something like l10n, which performance improvements you are trying to achieve etc.).
Best practices can, as you said mean to have either a good documentation or examples, or it could be baked into the framework. Obviously there is always the problem of feature bloat, but you probably know that with a forum that has at least 2 feature requests a day
So, yeah it’s up to you. An example would be great (even on the existing history screen).
In fact, there are other parts of the platform that could benefit from a generic API for “any entity references” - Dynamic Attributes and FTS queue.
So now I think you are right, this is quite a common requirement, and we should create a common base for the platform usages and an API for application projects. We’ll certainly include it to the roadmap.