[ https://issues.apache.org/jira/browse/IBATIS-569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12658995#action_12658995
]
Dan Turkenkopf commented on IBATIS-569:
---------------------------------------
Hi Jeff,
I saw the initialized method. That's a really nice feature that will make things a lot easier.
That said, I don't think it applies in this case since the plugins are entirely unrelated
- I just happened to run them on the same table at the same time. I think that's probably
the proper behavior - leaving the plugins independent of each other and only figuring out
things through the basic Ibator functionality.
The IbatorRules approach might work better though. It would suggest that any plugin that
halts any of the basic Ibator generated functionality would have to inform the Rules object
somehow so that all other plugins are made aware. You'd need to add a way to set the IbatorRules
object for a table, of course.
I'm still pondering the implications, but a couple of things jump out at me. You'd have to
have some way for different plugins to weigh in on whether they'd be generating a piece of
functionality - so that implies some kind of chaining like the IbatorPluginAggregator does
I think. Also, the way this would work best is if all these indicators can be set ahead of
the actual generation - otherwise order becomes very important. So the initialized method
is probably the right time for this hook. Of course plugins are free to not register their
intent (or to lie about it) and not generate the methods, but this could work as a relatively
low-impact mechanism.
Any ideas on how you'd want the proxying to work?
> 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.