[
https://issues.apache.org/jira/browse/IBATIS-569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12659221#action_12659221
]
Jeff Butler commented on IBATIS-569:
------------------------------------
The initialized method currently has the opportunity to override the default
rules (setRules()). However, when I mentioned the proxy class, I really hadn't
thought it through completely. IbatorRules as it stands would be difficult to
proxy. I'll definitely fix that.
My first thought is to do something very simple - turn IbatorRules into an
Interface, rework the three supplied implementations, and supply a basic rules
proxy class. Then each plugin could easily override one or more rules from the
default calculated rules. Pseudo code like this:
public class MyPlugin extends IbatorPluginAdapter {
public void initialized(IntrospectedTable introspectedTable) {
IbatorRule rules = introspectedTable.getRules();
MyRules myRules = new MyRules(rules);
introspectedTable.setRules(myRules);
}
}
public class MyRules extends IbatorRulesProxy {
public MyRules (IbatorRules ibatorRules) {
super(ibatorRules);
}
@Override
public boolean generateInsert() {
return false;
}
}
This way you could chain rules implementations together in different plugins if
required, but we wouldn't have to do anything too complex. I think this is a
fairly rare use case so I don't want to overdesign.
> 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.
