ibatis-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Butler (JIRA)" <ibatis-...@incubator.apache.org>
Subject [jira] Commented: (IBATIS-569) Simulate mode for Ibator Plugins
Date Mon, 22 Dec 2008 15:50:44 GMT

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

View raw message