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 :-)
* 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.
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
