On 8/29/07, Mauro Talevi <[EMAIL PROTECTED]> wrote: > Shane Duan wrote: > > 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. > > Don't really follow you - maybe I'm not understanding the proposed change :-)
Sorry... The gist of this proposal is getting rid of the "verifier" field in a class (BehaivourVerifier? I forgot the name.) and everything associated with it. That is all. > > >>> * 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. > > But this is where the BehaviourListener comes in - telling you when the > behaviour has been verified. Right. The listener does not tell you when the whole class is done, just when the method is done. I am proposing to change it so that the listener tells you when the whole class is done. > > Why don't you post a patch with your proposed changes (wrt to the > BehaviourClass and verifier) and > we can review them with more concreteness. > > I personally can't seem to get the drift of the proposal, so I can't say much > more. > > > Thanks. I guess I'll have to inject the class loader in along with > > the class name. > > I think injecting the ClassLoader in the constructor of the class doing the > instantiating is the > best thing. > > 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
