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 Sun, 28 Dec 2008 22:32:44 GMT

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