Shane Duan wrote:
As part of the work of making a GUI IDEA plugin for jBehave, I think I need
to do some changes on the jBehave core:
* Get rid of verifier field. There are a bit of code handling this field, yet
the only place it is being passed in is from the behaviors of the
classes themselves. I think removing this field will lead to less
code with the same functionality.
Not sure how that benefits you. But if you have a better way of doing, sure
like to hear it.
* In order to report the behaviors so that they can show up in the
plugin, I need to create another implementation MethodHandler that can
do more that counting. Should I make it private like the
MethodCounter, and add anothr method on BehaviorClass like
"report(BehaviorReporter reporter)", or should I just make the
"traverseMethodsWith" method public? Now I am writng this, create
another method on BehaviorClass sounds like a good idea.
+1 to BehaviourReporter - it can then be utilised for other plugins too.
* The design of BehaviourClass implies that you can have a
BehaviourClass inside another BehaviourClass. In order to be able to
build this tree structure on I also need to add another method to
MethodHandler, something like "finishHandleBehaviourClass". This
makes me think maybe the MethodHandler is a visitor pattern after all.
Can you elaborate on this use case? The BehaviourClass encloses methods
rather than another class.
* It is kind of silly to load an instance of the BehaviorClass just to
do the report, so I am thinking of making the instance field in
BefhaviorMethod lazily loaded.
No harm in this. Please make sure you use the injected ClassLoader to this, or
else
it won't be possible to use it in some plugins (eg Maven).
Cheers
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
