Community
Participate
Working Groups
Lets say you have a property that is a JavaType target with a JavaTypeConstraint annotation specifying kind. However, what if you want the type to be derived from the value of some model property at runtime. In this case, it would be good to have a JavaTypeConstraintService where the type() info could be computed at runtime. This way when the "create" action occurs, we could supply what baseType to use for the new class.
Created attachment 206825 [details] Patch attempt #1 This is my rough draft of a patch. I just want to make sure I'm going in the right direction before I continue with it.
Looks like you are on the right track. A few comments from a very rough review... 1. JavaTypeConstraintService methods should return collections rather than arrays. 2. Need to cover kind() and behavior() with service too. 3. Need to find all places where JavaTypeConstraint annotation is referenced and replace with references to the service. 4. For the service to be truly dynamic, some of the consumers of this metadata (such as JavaTypeValidationService) need to listen on JavaTypeValidationService. The Service API already includes listener API.
I am being somewhat optimistic here since there is only a week left, but I will target this to 0.4 for now.
Created attachment 206829 [details] Patch #2 - completed the constraint service to have behavior() and kind() - converted the lists to collections, although there are two places where it is assuming an order of the items in the collection which looks like a problem - removed all references to JavaTypeConstaint with reference to the JavaTypeConstraintService, - switched to using element.service(property, JavaTypeConstraintService) instead of just property.service(..) - tried to implement the listener for Facts and Validation serivce but I don't know if it is having the desired effect.
Created attachment 206910 [details] Patch v3 This patch is same as before but it includes documentation.
Created attachment 206911 [details] mylyn/context/zip
Accepted Patch v3 with following changes: 1. Improved the API of JavaTypeConstraintService to be based on cache/refresh architecture similar to EnablementService. 2. Removed listener from JavaTypeConstraintFactsService. It isn't necessary since FactsService doesn't cache internally and refreshing the element doesn't draw on the FactsService. It's used on demand in other contexts. 3. JavaTypeValidationService does need to trigger property refresh when JavaTypeConstraintService changes, but the patch was refreshing the whole element (too much refresh). 4. JavaTypeValidationService was originally written to cache constraint information during init. This doesn't work if the constraint information is dynamic. Removed the caching. 5. In JavaTypeBrowseActionHandler, lookup of JavaTypeConstraintService was using property metamodel context instead of property instance context. 6. In JavaTypeCreateActionHandler, caching was removed with interpretation of constraint moved to the run method, except that it was still writing to member fields. Multiple invocations of run would surely result in amusing results. See the interfaces field, in particular. Changed the fields to local variables. 7. Moved analysis of the constraint in JavaTypeCreateActionHandler further down in the run method as there are some paths that abort early and there is no sense in analyzing the constraint in those cases. 8. Improved the documentation content.
Thanks for pushing in this fix. I have my downstream service working nicely now. Marking as Verified.
Thanks for the verification. Closing.
