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