On 8 February 2015 at 18:16, Philippe Mouawad <[email protected]> wrote: > On Sunday, February 8, 2015, sebb <[email protected]> wrote: > >> I've just had a look at the BackendListener implementation. >> [Sorry, I should have spent some time on this when it was first added.] >> >> Although it clearly works, it does not seem to me to be a particularly >> user-friendly design. >> The GUI is not very easy to use. >> > it follows the same gui design as Java Sampler one.
Yes, which is also not all that user friendly. > The limit comes from it genericity > What do you find not easy to use ? > There layout is just a list of names ane values; there's no logical grouping and no s > >> Would it not be possible to implement the Gui and sampler classes as >> stand-alone classes? > > > Not clear for me, as I don't see sampler here. I meant listener, but in fact that won't quite work. No matter, the main issue is that the Gui is not as easy to use as it could be. >> >> These can all derive from the same abstract parent class(es). >> >> == >> >> Also, it looks like the underlying BackendListener is duplicated for >> each GUI Listener in the test plan. So each sample will be processed >> multiple times, and there will be multiple queues. > > > True but have a look at BackendListenerClient#createSampleR esult which > would be impacted by the redesign. > Also not sure there will be more than 2 Listeners in a plan. > If we create a good live listener (Graphite) + and good Post Test listener > (Report generator) then it would be enough for most cases. I doubt it. > That seems very wasteful. >> >> At the moment there is only one possible listener type so there is no >> need to create more than one listener in a given scope, however in >> future there will presumably be more. >> >> I think it would be better if the backend listeners were able to >> register themselves with a single BackendListener which then >> distributes the sample as needed to the eventual recipients. >> >> I've not looked into how this would fit in with scoped listeners; it >> may be necessary to allow for muliple listeners, one in each scope, >> and then allow for different listener types to be attached to the >> different scopes. This needs further research. >> >> == >> >> Unlike existing Listeners, there does not seem to be any way to limit >> processing to only successful/failed samples. >> >> Not sure this is needed . > Backend implementation can do the filtering itself through > createSamplerResult by returning null. Perhaps, though that is not very efficient. >> >> I think the current implementation needs rethinking. >> If it is to be included in the next release as it currently stands, I >> think it needs to be very clearly documented as being subject to >> change. >> > > > Can't you rework it before release ? I don't know how long this will take. I thought you were keen to get a release out soon.
