On 8/29/07, Mauro Talevi <[EMAIL PROTECTED]> wrote: > 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.
The benefit for this one is a lot less code to manage. > > > * 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. I know in general the BehaviourClass encloses methods, but I am just saying that by the current design, there is no preventing the user to do it the other way. This method will make it easier for the plugin to know when to display the tree, and when to mark a behaviour class as finished. It could do that by tracking the number of the children and how many have been processed, but I thought that was just more complicated that the framework itself should help making plugin writing easier. > > > * 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). Thanks. I guess I'll have to inject the class loader in along with the class name. > > Cheers > > > --------------------------------------------------------------------- > To unsubscribe from this list please visit: > > http://xircles.codehaus.org/manage_email > > -- Shane http://www.shaneduan.com --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
