Oct 26th, 2009, 01:51 PM
User addon/plugins and existing behavior
I'm looking forward to RC3 with the ability to write your own addon as demonstrated at Springone. I have some questions on how the plugins will work with existing roo behavior.
For example, I added two Jira tickets, one for the ability to change toString and the other for SoftDelete. If I wanted to implement these as addons, how would they interact with the core roo addons.
With those two examples, the toString would effectively replace the roo toString and provide a nicer web facing toString method when the system goes to production. Would I have to remove the Roo toString addon?
For the softdelete, it would add a field to the entity and also override the delete mechanism. It would also need to be aware of any finders so that by default it happened in the background. In this case, it would work alongside the current entity code instead of replacing it. Would I have to register the softdelete addon to watch for the metadata changes in the entity addon?
Oct 27th, 2009, 03:29 AM
toString is easy. You'd just make a new @RooToStringImproved annotation that triggers your improved toString method. Although you might be better-off providing an enhancement to the existing toString add-on instead, as we'd likely accept it.
Soft delete is more complicated. What you really want is to modify the existing Entity add-on to provide some setters on EntityMetadataProvider so you can modify the defaults for whether a persist/remove/findAll etc method is added by default. That way other add-ons can accept EntityMetadataProvider as a constructor argument and then EntityMetadataProvider.setDefaultRemove(false). That should sort out the first part. The finder integration would probably be best tackled by improving the existing finder add-on to allow a strategy to be plugged in that modifies the generated JPA QL statements. Perhaps Stefan can offer some suggestions on that.
The trouble with these add-on examples is they're relatively difficult as you want to modify an existing behaviour of Roo add-ons without replacing them entirely. To that end you'd need to look at how the existing add-ons could be made to support strategy interface and other similar techniques to allow your add-ons (and other add-ons that might be used concurrently) can participate. We're open to changes to the core add-ons (like the entity and toString add-ons) to facilitate third-party add-ons being involved with fine-tuning operations without needing to entirely replace the base add-on(s).
Oct 27th, 2009, 09:56 AM
Thanks for the reply. I think modifying the existing toString might be the best bet so I will take a look at doing that.
As for the Entity changes, I think the strategy approach is a great idea as it would allow addons to be able to change some of the behavior of the Entity/Finders without having to rewrite them completely.
I remember reading a post with a request to make Entity/Finder aware of the Spring Security objects, so that it would automatically adjust the finders so that it would query for user ownership on objects in tables by default instead of having to manually add them to the list with finder add.
This means roo would have to be able to plug multiple strategies into Entity and Finder, e.g. SoftDeleteStrategy, UserAwareStrategy.
I think this would fit in nicely with roo's vision of taking care of tedious and repetitive tasks for you.
Oct 27th, 2009, 03:57 PM
Being able to modify/customize the behaviour of core addons could be very useful, for example in UI customization and reduce the need of writing complete addons, many custom needs can be implemented as a modification of existing addons.
Last edited by Andrew Swan; Aug 21st, 2011 at 08:33 PM.
Reason: Fixed typo
Oct 28th, 2009, 09:52 AM