DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15826>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15826 New Test Component type: Extractors Summary: New Test Component type: Extractors Product: JMeter Version: Nightly (Please specify date) Platform: Other OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: Main AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] >From an e-mail I wrote a while ago: [...] I also would like to see limited scripting functionality replacing/complementing the current ${functions} with ECMAScript expresions. This would also address Mike's wish to have more complex parsing.. Being more specific, I was thinking about a simplification of the functions functionality. A function currently produces a value from the current test execution context, which includes the results of the last request and little more. This causes difficulties, for example, if you want to use a piece of info in a response two requests later. The solution was this "variable-names" stuck to the end of the function call so that you can (re-)use that value later on -- but it's all tied with strings. My idea is to create a new kind of component, an "Extractor", which would receive samples and extract data from them, placing the results in variables. Similar to Assertions, these extractors would most often be placed inside a Sampler, but it could make sense to put one in a controller if it needs to repeat the extraction for each sampler in there. Once you have this, you can almost eliminate the concept of ${functions} and almost stick to ${variables} -- although being able to use expressions on the variables, possibly including real functions, would be great. I say "real functions" because the current ones are very badly named, since their results depend (almost exclusively) on things other than their parameters, so they are not functions in a proper sense. A side advantage of this "Extractor" idea is that complex stuff like regular expressions could go into their own field in a GUI form, instead of being embedded in a longer text. Possible extractors: - Regexp extractor - Cookie extractor - Session id extractor - Form field extractor [...] -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
