[jira] Commented: (IBATIS-569) Simulate mode for Ibator Plugins

["Jeff Butler (JIRA)" <ib...@incubator.apache.org>]

    [ https://issues.apache.org/jira/browse/IBATIS-569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12658576#action_12658576 ] 

Jeff Butler commented on IBATIS-569:
------------------------------------

Hi Dan,

There are a couple of new things that could help:

1. The plugin API now contains an "initialized" method.  This method is called after database introspection and before any of the code generation methods.  One plugin could use this method to set attributes for use by another plugin.

2. As far as "simulate" mode, there's something sort of like that already.  All code generation in Ibator is controlled by an instance of IbatorRules.  This class contains methods that enable/disable all the different code fragments produced by Ibator.  In your plugin, you could make a simple proxy of the calculated IbatorRules object that overrides certain behaviors, and then replace the calculated rules object with your new instance.  For example, your first plugin could turn off the insert method completely - and then the second plugin could query the rules object to see that insert is disabled.


> 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.