[
https://issues.apache.org/jira/browse/IBATIS-569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12659180#action_12659180
]
Dan Turkenkopf commented on IBATIS-569:
---------------------------------------
Doing a little more thinking about this, I wonder if allowing plugins to
register as Rules providers would work.
In the initialized method, a plugin could register with the IbatorContext as a
rules provider (i.e. implements an IbatorRulesProvider interface). Then when
another class gets the IbatorRules from the IntrospectedTable it could call out
to all the rules providers and ask for their response. If any of them return
false, then the overall answer would be false as well.
I think I could put that mechanism together pretty quickly and it would
definitely meet my needs. Thoughts?
> Simulate mode for Ibator Plugins
> --------------------------------
>
> Key: IBATIS-569
> URL: https://issues.apache.org/jira/browse/IBATIS-569
> Project: iBatis for Java
> Issue Type: Wish
> Components: Tools
> Affects Versions: 2.3.3
> Reporter: Dan Turkenkopf
>
> As I'm playing with creating Ibator plugins for various purposes, I'm running
> into the issue of conflicting actions.
> For example, I have one plugin that optionally removes the insert method from
> the DAO class, but I have another one that creates a new method that calls
> the insert method. When running the two of them on the same table, my
> generated DAO has compile errors.
> Since the plugins shouldn't know anything about each other, I need some way
> to know whether the DAO's insert method is actually generated or not.
> I played around with a way of tracking generation state at the
> IbatorPluginAggregator level, but the timing of component creation doesn't
> appear to be in the right order for what I'm doing (the
> daoImplementationGenerated method is called before the
> daoInsertMethodGenerated method).
> My suggestion is to run through the generation process twice - once to
> determine which components should be generated, and a second time to actually
> generate them. Granted, this would slow down generation, but since it's an
> out-of-band process anyway, speed should be less important. And this would
> allow plugins to be independent but still react to whether another plugin
> changes the generated output.
> I'm willing to continue working on this and submit a patch, but wanted to get
> some feedback before going too much further.
> Thanks,
> Dan Turkenkopf
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
