[
https://issues.apache.org/jira/browse/IBATIS-569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12659482#action_12659482
]
Jeff Butler commented on IBATIS-569:
------------------------------------
I just checked in changes for this to SVN. They are as described above, except
that the class to extend is IbatorRulesDelegate - NOT IbatorRulesProxy.
Delegate is a more appropriate pattern for what I was describing.
Let me know what you think.
> 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
> Assignee: Jeff Butler
>
> 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.