RE: Parser refactoring - what next?
I have no preference either way. a factory would be nice. peter BAZLEY, Sebastian [EMAIL PROTECTED] wrote: The reason I suggested a factory might be useful is that some parsers might be shareable, and some might not. Using a constructor to acquire a parser makes it more difficult to share instances (I think). I had a look at using dynamic loading of the parser last night, and found that it was not trivial, as the parser classes have private constructors. [Adding a factory method would be one solution, I guess.] == I think it would be better to retrieve the parser instance in a separate class, not directly in HTTPSamplerFull, as this would make it a bit more flexible. Not sure if the (e.g.) getParser() method should always use the value of jmeter.html.parser, or whether it should accept another property name and/or a class name. Perhaps start with the fixed name, and create additional methods if they prove necessary later... == Another oops. I did not notice the html.parser package, so I put the extracte parser code in the html.sampler package. I think it would be better to move them, and they can then keep company with htmlparser.java. S. -Original Message- From: Jordi Salvat i Alabart [mailto:[EMAIL PROTECTED] Sent: 24 November 2003 18:45 To: JMeter Developers List Subject: Re: Parser refactoring; should Jmeter fetch more than images/appl ets? OK. I'm doing that. I will also try to devise some easy-to-reproduce test that we can use for comparison. En/na peter lin ha escrit: i like the idea of an iterator, since that is how we use it anyways :) peter [...] In the short-term, I suggest hard-coding the class names in HTTPSamplerFull, but it might be useful to use a factory in future. Or simply grabbing jmeter.html.parser and instantiating the class from the name? [...] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Do you Yahoo!? Free Pop-Up Blocker - Get it now
Re: Parser refactoring - what next?
sounds great. If I'm lucky, I might be able to spend 2-3 hours over the holiday weekend to debug htmlparser :) peter Jordi Salvat i Alabart [EMAIL PROTECTED] wrote: Sorry, I had a long network outage today, so I used my (otherwise pretty idle) time to do that refactoring. Added a factory method. Put everything in the http.parser package -- bug had to rename what was there to get a reasonably nice and consistent naming. Sorry if we've duplicated work. I thought I had said I would be doing this. -- Salut, Jordi. En/na BAZLEY, Sebastian ha escrit: The reason I suggested a factory might be useful is that some parsers might be shareable, and some might not. Using a constructor to acquire a parser makes it more difficult to share instances (I think). I had a look at using dynamic loading of the parser last night, and found that it was not trivial, as the parser classes have private constructors. [Adding a factory method would be one solution, I guess.] == I think it would be better to retrieve the parser instance in a separate class, not directly in HTTPSamplerFull, as this would make it a bit more flexible. Not sure if the (e.g.) getParser() method should always use the value of jmeter.html.parser, or whether it should accept another property name and/or a class name. Perhaps start with the fixed name, and create additional methods if they prove necessary later... == Another oops. I did not notice the html.parser package, so I put the extracte parser code in the html.sampler package. I think it would be better to move them, and they can then keep company with htmlparser.java. S. -Original Message- From: Jordi Salvat i Alabart [mailto:[EMAIL PROTECTED] Sent: 24 November 2003 18:45 To: JMeter Developers List Subject: Re: Parser refactoring; should Jmeter fetch more than images/appl ets? OK. I'm doing that. I will also try to devise some easy-to-reproduce test that we can use for comparison. En/na peter lin ha escrit: i like the idea of an iterator, since that is how we use it anyways :) peter [...] In the short-term, I suggest hard-coding the class names in HTTPSamplerFull, but it might be useful to use a factory in future. Or simply grabbing jmeter.html.parser and instantiating the class from the name? [...] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Do you Yahoo!? Free Pop-Up Blocker - Get it now
RE: Parser refactoring - what next?
-Original Message- From: Jordi Salvat i Alabart [mailto:[EMAIL PROTECTED] Sent: 25 November 2003 15:43 To: JMeter Developers List Subject: Re: Parser refactoring - what next? Sorry, I had a long network outage today, so I used my (otherwise pretty idle) time to do that refactoring. Added a factory method. Put everything in the http.parser package -- bug had to rename what was there to get a reasonably nice and consistent naming. I look forward to trying this out. Sorry if we've duplicated work. I thought I had said I would be doing this. No problem. I saw your comment, but thought it related only to the idea of returning an Iterator instead of a Set. But it wasn't wasted time, as it all helps my knowledge of Java and JMeter. S. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Parser refactoring - what next?
-Original Message- From: BAZLEY, Sebastian Sent: 25 November 2003 16:00 To: 'JMeter Developers List' Subject: RE: Parser refactoring - what next? -Original Message- From: Jordi Salvat i Alabart [mailto:[EMAIL PROTECTED] Sent: 25 November 2003 15:43 To: JMeter Developers List Subject: Re: Parser refactoring - what next? Sorry, I had a long network outage today, so I used my (otherwise pretty idle) time to do that refactoring. Added a factory method. Put everything in the http.parser package -- bug had to rename what was there to get a reasonably nice and consistent naming. I look forward to trying this out. To follow up my own posting: The new layout with the factory makes it _much_ easier to follow. So much so that I am encouraged to tidy the JTidy implementation so that it only does a single scan of the tree... S. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
