You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jmeter-dev@jakarta.apache.org by Jordi Salvat i Alabart <js...@atg.com> on 2004/01/02 01:51:13 UTC
TestBeans: proof of concept
How to try:
- Check out branch testbeans_experimental_branch
- Build & run
- Right-click on Workbench -> Add -> Sampler -> HTTPSamplerBean
- See the automatically-generated GUI.
The component probably doesn't work. Of course I'll need to fix this
before declaring the proof-of-concept complete.
Understanding the thing:
To start with, forget about all the changes in the core packages for the
time being. Let's focus in the HTTPSamplerBean class, which is a port to
the new concept of the HTTPSampler class in the
Root_testbeans_experimental_branch version.
HTTPSamplerBean is exactly the same as the HTTPSampler except that:
- It longer uses those JMeterProperties, but regular, familiar Java Bean
properties instead.
- It subclasses TestBean and implements Sampler instead of subclassing
AbstractSampler. It would be trivial to create an AbstractSamplerBean
class to play the role of the AbstractSampler.
- sample() now calls "prepare()" first thing. This is important, but my
idea is to change the engine to do this call. [Or I could have
sample(Entry) call it in the above-mentioned AbstractSamplerBean, which
would declare sample(Entry) final and sample() abstract.]
I don't think I've done any other relevant changes (well, I've tried not
to).
The resulting class is obviously simpler than the original HTTPSampler,
but really not that much. The obvious advantage is in the GUI classes.
The GUI is based in two classes only: HTTPSamplerBeanBeanInfo (4 lines
of code) and HTTPArgumentsEditor (3 lines). They are necessary because
the HTTPSampler is a particularly complex test element, in that its GUI
has an embedded ArgumentsPanel, that is: the GUI for another test
element is embedded here. I chose it precisely because of this
complexity: I wanted to prove that the two approaches (old-style
testelements and TestBeans) can interoperate fully.
The BeanInfo class will grow significantly larger before the
proof-of-concept is complete, but I wanted you to have a look at this
when it's still this simple -- it's a good example for what a developer
prototyping a new component will need to do.
About the additions I've done in the core packages, feel free to have a
look, but I don't think it's that important now. The bits that are not
about handling the GUI are about maintaining compatibility with the
current approach. For example, TestBean is now a subclass of
TestElement, but it doesn't really need to be in the future: we will be
able to keep the bean and it's "description" (the propertie's values or
expressions to be used to compute them) separate.
Constructive and destructive comments welcome.
--
Salut,
Jordi.
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: TestBeans: proof of concept
Posted by Jordi Salvat i Alabart <js...@atg.com>.
En/na Sebastian Bazley ha escrit:
>>>Some tidying up to do, e.g. some fields should be check-boxes (and I think we'll need radio buttons elsewhere).
>>
>>My idea is not to have any checkboxes. Boolean fields, for example,
>>would be edited with a combo box having 4 options:
>>- "Use default" (or "undefined")
>>- "Yes"
>>- "No"
>>- a user-entered string (to enable using variables and functions)
>
>
> Good idea - I'd forgotten about that.
This is done now. I'll be checking in in a few minutes. Please have a look.
> Were you planning to do the same with radio buttons?
> For example, Size Assertion has quite a few radio buttons to select the different comparison types.
> Would this be as easy to use if it was a combo-box?
Anyway, there's nothing preventing us to use radio buttons (or any other
contraption) if they are really more appropriate for a particular property.
> I was thinking of GUIs which have a lot of options; having to use separate lines for each might make the screen rather long.
>
> For example:
> - HTTPSampler has Follow Redirects, Use KeepAlive, Retrieve All Embedded Resources.
> - ThreadGroup has Loop Count with ForEver and Text input boxes which logically belong on the same line.
>
> But there are other ways of arranging these.
>
Let's wait and see how it looks in practice.
>>The upgrade path is something I've not given much thought to. I'm not so
>>sure there will be a clean and safe upgrade path -- which is a problem,
>>of course.
>
>
> This is critical for us, so needs to be addressed, in my view.
It's not critical for me. But I understand it can be critical for many
users, so yes, it needs to be addressed. But I'd defer thinking about
how to get there to when we approximately know where we want to get :-)
> I'm not against your approach, but I'm not yet convinced - it would be useful to complete the HTTPSampler example to see how it all
> works out.
Absolutely agreed. I absolutely want to see where I get before we
decide. It's a big change, so it has to pay off its high cost.
--
Salut,
Jordi.
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: TestBeans: proof of concept
Posted by Sebastian Bazley <Se...@london.sema.slb.com>.
----- Original Message -----
From: "Jordi Salvat i Alabart" <js...@atg.com>
To: "JMeter Developers List" <jm...@jakarta.apache.org>
Sent: Friday, January 02, 2004 6:20 PM
Subject: Re: TestBeans: proof of concept
> En/na Sebastian Bazley ha escrit:
> > ----- Original Message -----
> > From: "Jordi Salvat i Alabart" <js...@atg.com>
> > To: "JMeter Developers List" <jm...@jakarta.apache.org>
> > Sent: Friday, January 02, 2004 12:51 AM
> > Subject: TestBeans: proof of concept
> >
[...]
> > OK, this seems to work, except that "runningVersion" should not appear in the GUI. (perhaps others as well?)
> > - don't know if this affects the design or not.
>
> I know. My initial version was stopping introspection at the TestBean
> class, so that any properties defined below that would not appear.
> You'll see the "name" property appearing twice, for example. But when I
> created the TestBeanBeanInfo class I had to remove that... I'll find a
> solution for this -- eventually. Worst-case, I will mark those
> properties as hidden.
OK
> > Also, the field names will need to become resources - I guess this will be easy enough.
>
> Having display names for the properties is part of the Java Beans spec.
> I don't know about i18n, but I will find out. If there isn't a standard
> way, we can invent one -- looks pretty trivial.
OK - might be worth setting up an example.
> >
> > Some tidying up to do, e.g. some fields should be check-boxes (and I think we'll need radio buttons elsewhere).
>
> My idea is not to have any checkboxes. Boolean fields, for example,
> would be edited with a combo box having 4 options:
> - "Use default" (or "undefined")
> - "Yes"
> - "No"
> - a user-entered string (to enable using variables and functions)
Good idea - I'd forgotten about that.
Were you planning to do the same with radio buttons?
For example, Size Assertion has quite a few radio buttons to select the different comparison types.
Would this be as easy to use if it was a combo-box?
> We could define property attributes to control which of these options
> should be available for each individual property. And of course you
> always have the option to create your own property editor.
OK
[...]
> >
> > Need to allow for multiple input fields on a single line, and logical grouping of fields.
> > Would this be difficult?
>
> I was planning on logical grouping and explicit ordering. On multiple
> fields on a single line, I had not thought about it. I'm not sure it's a
> good idea.
I was thinking of GUIs which have a lot of options; having to use separate lines for each might make the screen rather long.
For example:
- HTTPSampler has Follow Redirects, Use KeepAlive, Retrieve All Embedded Resources.
- ThreadGroup has Loop Count with ForEver and Text input boxes which logically belong on the same line.
But there are other ways of arranging these.
>
> >
> >>The component probably doesn't work. Of course I'll need to fix this
> >>before declaring the proof-of-concept complete.
> >>
> >
> >
> > I would add that being able to replicate the existing GUI layout (more or less) is also necessary.
>
> I don't think that's a point. Replicating the existing GUI is trivial by
> using a bean customizer.
I had not realised that it is trivial, but given that it is, I agree.
> The interest is in obtaining a GUI with
> equivalent (or better) functionality and usability, but more consistent
> and with less work.
Agreed.
>
[...]
> >>I don't think I've done any other relevant changes (well, I've tried not
> >>to).
> >
> > The JMeterProperty keys have been removed
> > - I think they will need to be retained so that old JMX files can be converted, at least.
> > Could perhaps extend the upgrade.properties file processing to handle this?
>
> The upgrade path is something I've not given much thought to. I'm not so
> sure there will be a clean and safe upgrade path -- which is a problem,
> of course.
This is critical for us, so needs to be addressed, in my view.
[...]
> > However, I do think the GUI needs to be customisable.
>
> I think there's very few cases in which it needs to. The visualisers are
> probably the only really good example.
If the GUI layout changes drastically, it may increase the re-learning curve.
I was also referring to the need to be able to arrange the fields on the screen in a logical order, and group them - a simple list
ordered alphabetically by variable name is not all that easy to use ...
>
> > Is there a danger that the new GUI classes will then become very complicated?
>
> Not more complicated than they are now. Java Beans GUI stuff is really
> simple: either you provide an AWT component that does the editing (in
> which case you essentially revert to what we have now) or you let the
> platform do it for you -- you can still provide hints, of course, plus
> components to be used to edit individual properties (as I've done for
> the Arguments property).
Yes, the arguments editor works well - except that it should probably not have a title on the left hand side.
It would be useful to see how to arrange the other HTTPSamplerBean properties in logical groups.
>
> > Should we be looking at a GUI design language ?
> >
> > For example, XUL - http://www.mozilla.org/xpfe/xptoolkit/index.html - not sure if that is suitable for our purposes as it
stands.
> >
>
> I don't think we have such big GUI requirements to justify the
> investment. In any case, that would be a different development -- not
> incompatible at all with this experiment, I guess.
Depends on how difficult it is to generate a nice layout ...
>
> >>The GUI is based in two classes only: HTTPSamplerBeanBeanInfo (4 lines
> >>of code) and HTTPArgumentsEditor (3 lines). They are necessary because
> >>the HTTPSampler is a particularly complex test element, in that its GUI
> >>has an embedded ArgumentsPanel, that is: the GUI for another test
> >>element is embedded here. I chose it precisely because of this
> >>complexity: I wanted to prove that the two approaches (old-style
> >>testelements and TestBeans) can interoperate fully.
> >
> >
> > The GUI classes are now in the same directory as the sampler, whereas previously they were in a separate gui/ directory.
> > I prefer retaining a separate directory.
>
> The default way for the beans stuff to obtain a property editor for a
> class is to append the name "Editor" to the class name -- in the same
> package. You can also provide a list of editor search paths, but I
> prefer to stick to the default ways unless there's a good reason to do
> otherwise.
>
> The same applies to the BeanInfo classes.
>
OK, point taken.
[...]
> >>Constructive and destructive comments welcome.
> >>
> >
> >
> > Well done for tackling the GUI set-up complications!
> >
> > But I'm a bit concerned that quite a lot of work has gone into the current GUI design over the years.
> > It's not perfect, but I think it is generally well laid out, and it would be confusing if all the layouts changed drastically.
>
> I agree there's a lot of work, but I disagree in that it's generally
> well laid out. I find it awful, inconsistent, inconfortable to work
> with, full of bugs, and generally annoying. That's of course one of the
> main motivators for this experiment. I would expect users to welcome the
> cost of getting familiar with a fairly new GUI if the change is for better.
Taking the HTTPSampler as an example, I find the existing layout OK.
On the whole, related items are grouped together.
However, Follow Redirects and Use Keep-Alive need moving - they perhaps belong in the Optional Tasks section.
The GUI is awkard to use in some respects (tab order is not always clear, and the selected field is not always obvious etc), but I
assume that is down to Swing/Java rather than JMeter.
[...]
I'm not against your approach, but I'm not yet convinced - it would be useful to complete the HTTPSampler example to see how it all
works out.
S.
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: TestBeans: proof of concept
Posted by Jordi Salvat i Alabart <js...@atg.com>.
En/na Sebastian Bazley ha escrit:
> ----- Original Message -----
> From: "Jordi Salvat i Alabart" <js...@atg.com>
> To: "JMeter Developers List" <jm...@jakarta.apache.org>
> Sent: Friday, January 02, 2004 12:51 AM
> Subject: TestBeans: proof of concept
>
>
>
>>How to try:
>>
>>- Check out branch testbeans_experimental_branch
>>- Build & run
>>- Right-click on Workbench -> Add -> Sampler -> HTTPSamplerBean
>>- See the automatically-generated GUI.
>
>
> OK, this seems to work, except that "runningVersion" should not appear in the GUI. (perhaps others as well?)
> - don't know if this affects the design or not.
I know. My initial version was stopping introspection at the TestBean
class, so that any properties defined below that would not appear.
You'll see the "name" property appearing twice, for example. But when I
created the TestBeanBeanInfo class I had to remove that... I'll find a
solution for this -- eventually. Worst-case, I will mark those
properties as hidden.
> Also, the field names will need to become resources - I guess this will be easy enough.
Having display names for the properties is part of the Java Beans spec.
I don't know about i18n, but I will find out. If there isn't a standard
way, we can invent one -- looks pretty trivial.
>
> Some tidying up to do, e.g. some fields should be check-boxes (and I think we'll need radio buttons elsewhere).
My idea is not to have any checkboxes. Boolean fields, for example,
would be edited with a combo box having 4 options:
- "Use default" (or "undefined")
- "Yes"
- "No"
- a user-entered string (to enable using variables and functions)
We could define property attributes to control which of these options
should be available for each individual property. And of course you
always have the option to create your own property editor.
> Would be nice to align input fields.
There's a TODO in the code about using a table to align the input fields
-- the current solution is just a quick hack built from already-existing
code.
>
> Need to allow for multiple input fields on a single line, and logical grouping of fields.
> Would this be difficult?
I was planning on logical grouping and explicit ordering. On multiple
fields on a single line, I had not thought about it. I'm not sure it's a
good idea.
>
>>The component probably doesn't work. Of course I'll need to fix this
>>before declaring the proof-of-concept complete.
>>
>
>
> I would add that being able to replicate the existing GUI layout (more or less) is also necessary.
I don't think that's a point. Replicating the existing GUI is trivial by
using a bean customizer. The interest is in obtaining a GUI with
equivalent (or better) functionality and usability, but more consistent
and with less work.
>
>>Understanding the thing:
>>
>>To start with, forget about all the changes in the core packages for the
>>time being. Let's focus in the HTTPSamplerBean class, which is a port to
>>the new concept of the HTTPSampler class in the
>>Root_testbeans_experimental_branch version.
>>
>>HTTPSamplerBean is exactly the same as the HTTPSampler except that:
>>
>>- It longer uses those JMeterProperties, but regular, familiar Java Bean
>>properties instead.
>>
>>- It subclasses TestBean and implements Sampler instead of subclassing
>>AbstractSampler. It would be trivial to create an AbstractSamplerBean
>>class to play the role of the AbstractSampler.
>>
>>- sample() now calls "prepare()" first thing. This is important, but my
>>idea is to change the engine to do this call. [Or I could have
>>sample(Entry) call it in the above-mentioned AbstractSamplerBean, which
>>would declare sample(Entry) final and sample() abstract.]
>>
>>I don't think I've done any other relevant changes (well, I've tried not
>>to).
>
>
> The JMeterProperty keys have been removed
> - I think they will need to be retained so that old JMX files can be converted, at least.
> Could perhaps extend the upgrade.properties file processing to handle this?
The upgrade path is something I've not given much thought to. I'm not so
sure there will be a clean and safe upgrade path -- which is a problem,
of course.
>
>>The resulting class is obviously simpler than the original HTTPSampler,
>>but really not that much. The obvious advantage is in the GUI classes.
>
>
> Yes - the current design makes for very tedious coding,
> and it is easy to do things in the GUI class by mistake that need to be done for non-GUI mode as well.
>
> But it does offer complete control over GUI layout.
>
> I've little or no experience of Beans, so I don't know how easy it will be to customise the GUI layouts.
There's not much about beans & GUIs... just half a dozen pages on
BeanInfos and PropertyEditors in the Java Bean Spec -- that's it.
>
> However, I do think the GUI needs to be customisable.
I think there's very few cases in which it needs to. The visualisers are
probably the only really good example.
> Is there a danger that the new GUI classes will then become very complicated?
Not more complicated than they are now. Java Beans GUI stuff is really
simple: either you provide an AWT component that does the editing (in
which case you essentially revert to what we have now) or you let the
platform do it for you -- you can still provide hints, of course, plus
components to be used to edit individual properties (as I've done for
the Arguments property).
> Should we be looking at a GUI design language ?
>
> For example, XUL - http://www.mozilla.org/xpfe/xptoolkit/index.html - not sure if that is suitable for our purposes as it stands.
>
I don't think we have such big GUI requirements to justify the
investment. In any case, that would be a different development -- not
incompatible at all with this experiment, I guess.
>>The GUI is based in two classes only: HTTPSamplerBeanBeanInfo (4 lines
>>of code) and HTTPArgumentsEditor (3 lines). They are necessary because
>>the HTTPSampler is a particularly complex test element, in that its GUI
>>has an embedded ArgumentsPanel, that is: the GUI for another test
>>element is embedded here. I chose it precisely because of this
>>complexity: I wanted to prove that the two approaches (old-style
>>testelements and TestBeans) can interoperate fully.
>
>
> The GUI classes are now in the same directory as the sampler, whereas previously they were in a separate gui/ directory.
> I prefer retaining a separate directory.
The default way for the beans stuff to obtain a property editor for a
class is to append the name "Editor" to the class name -- in the same
package. You can also provide a list of editor search paths, but I
prefer to stick to the default ways unless there's a good reason to do
otherwise.
The same applies to the BeanInfo classes.
>
>>The BeanInfo class will grow significantly larger before the
>>proof-of-concept is complete, but I wanted you to have a look at this
>>when it's still this simple -- it's a good example for what a developer
>>prototyping a new component will need to do.
>>
>>About the additions I've done in the core packages, feel free to have a
>>look, but I don't think it's that important now. The bits that are not
>>about handling the GUI are about maintaining compatibility with the
>>current approach. For example, TestBean is now a subclass of
>>TestElement, but it doesn't really need to be in the future: we will be
>>able to keep the bean and it's "description" (the propertie's values or
>>expressions to be used to compute them) separate.
>>
>>Constructive and destructive comments welcome.
>>
>
>
> Well done for tackling the GUI set-up complications!
>
> But I'm a bit concerned that quite a lot of work has gone into the current GUI design over the years.
> It's not perfect, but I think it is generally well laid out, and it would be confusing if all the layouts changed drastically.
I agree there's a lot of work, but I disagree in that it's generally
well laid out. I find it awful, inconsistent, inconfortable to work
with, full of bugs, and generally annoying. That's of course one of the
main motivators for this experiment. I would expect users to welcome the
cost of getting familiar with a fairly new GUI if the change is for better.
> Other points:
> - I suggest deprecating wrapInProperty() and unwrapProperty() to discourage use
Yes, I should have done that.
> - need to ensure that batch (non-gui) mode still works
I first need to ensure that non-batch (gui) mode still works :-)
> - ditto for client-server mode, which reminds me:
>
> In the next few days, I'm intending to try implementing RMI serialisation by using the external (XML) representation of the test
> plan, instead of serialising all the test element objects.
>
> This should reduce the data volumes sent across, as well as simplifying a lot of classes (no need to worry about implementing
> serializable). Don't know if this will affect your bean work.
Go ahead. I'm working on a separate branch. I'm ready for a long merge
if we decide to move it to head.
--
Salut,
Jordi.
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: TestBeans: proof of concept
Posted by Sebastian Bazley <Se...@london.sema.slb.com>.
----- Original Message -----
From: "Jordi Salvat i Alabart" <js...@atg.com>
To: "JMeter Developers List" <jm...@jakarta.apache.org>
Sent: Friday, January 02, 2004 12:51 AM
Subject: TestBeans: proof of concept
> How to try:
>
> - Check out branch testbeans_experimental_branch
> - Build & run
> - Right-click on Workbench -> Add -> Sampler -> HTTPSamplerBean
> - See the automatically-generated GUI.
OK, this seems to work, except that "runningVersion" should not appear in the GUI. (perhaps others as well?)
- don't know if this affects the design or not.
Also, the field names will need to become resources - I guess this will be easy enough.
Some tidying up to do, e.g. some fields should be check-boxes (and I think we'll need radio buttons elsewhere).
Would be nice to align input fields.
Need to allow for multiple input fields on a single line, and logical grouping of fields.
Would this be difficult?
>
> The component probably doesn't work. Of course I'll need to fix this
> before declaring the proof-of-concept complete.
>
I would add that being able to replicate the existing GUI layout (more or less) is also necessary.
> Understanding the thing:
>
> To start with, forget about all the changes in the core packages for the
> time being. Let's focus in the HTTPSamplerBean class, which is a port to
> the new concept of the HTTPSampler class in the
> Root_testbeans_experimental_branch version.
>
> HTTPSamplerBean is exactly the same as the HTTPSampler except that:
>
> - It longer uses those JMeterProperties, but regular, familiar Java Bean
> properties instead.
>
> - It subclasses TestBean and implements Sampler instead of subclassing
> AbstractSampler. It would be trivial to create an AbstractSamplerBean
> class to play the role of the AbstractSampler.
>
> - sample() now calls "prepare()" first thing. This is important, but my
> idea is to change the engine to do this call. [Or I could have
> sample(Entry) call it in the above-mentioned AbstractSamplerBean, which
> would declare sample(Entry) final and sample() abstract.]
>
> I don't think I've done any other relevant changes (well, I've tried not
> to).
The JMeterProperty keys have been removed
- I think they will need to be retained so that old JMX files can be converted, at least.
Could perhaps extend the upgrade.properties file processing to handle this?
>
> The resulting class is obviously simpler than the original HTTPSampler,
> but really not that much. The obvious advantage is in the GUI classes.
Yes - the current design makes for very tedious coding,
and it is easy to do things in the GUI class by mistake that need to be done for non-GUI mode as well.
But it does offer complete control over GUI layout.
I've little or no experience of Beans, so I don't know how easy it will be to customise the GUI layouts.
However, I do think the GUI needs to be customisable.
Is there a danger that the new GUI classes will then become very complicated?
Should we be looking at a GUI design language ?
For example, XUL - http://www.mozilla.org/xpfe/xptoolkit/index.html - not sure if that is suitable for our purposes as it stands.
>
> The GUI is based in two classes only: HTTPSamplerBeanBeanInfo (4 lines
> of code) and HTTPArgumentsEditor (3 lines). They are necessary because
> the HTTPSampler is a particularly complex test element, in that its GUI
> has an embedded ArgumentsPanel, that is: the GUI for another test
> element is embedded here. I chose it precisely because of this
> complexity: I wanted to prove that the two approaches (old-style
> testelements and TestBeans) can interoperate fully.
The GUI classes are now in the same directory as the sampler, whereas previously they were in a separate gui/ directory.
I prefer retaining a separate directory.
>
> The BeanInfo class will grow significantly larger before the
> proof-of-concept is complete, but I wanted you to have a look at this
> when it's still this simple -- it's a good example for what a developer
> prototyping a new component will need to do.
>
> About the additions I've done in the core packages, feel free to have a
> look, but I don't think it's that important now. The bits that are not
> about handling the GUI are about maintaining compatibility with the
> current approach. For example, TestBean is now a subclass of
> TestElement, but it doesn't really need to be in the future: we will be
> able to keep the bean and it's "description" (the propertie's values or
> expressions to be used to compute them) separate.
>
> Constructive and destructive comments welcome.
>
Well done for tackling the GUI set-up complications!
But I'm a bit concerned that quite a lot of work has gone into the current GUI design over the years.
It's not perfect, but I think it is generally well laid out, and it would be confusing if all the layouts changed drastically.
Other points:
- I suggest deprecating wrapInProperty() and unwrapProperty() to discourage use
- need to ensure that batch (non-gui) mode still works
- ditto for client-server mode, which reminds me:
In the next few days, I'm intending to try implementing RMI serialisation by using the external (XML) representation of the test
plan, instead of serialising all the test element objects.
This should reduce the data volumes sent across, as well as simplifying a lot of classes (no need to worry about implementing
serializable). Don't know if this will affect your bean work.
Sebastian
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org