Possibility to use custom parser for test data

[GoogleCodeExporter]

We have many test cases defined for different framework. test cases are defined 
via xml file. 

I have made my own reader and added it to populators READERS dictionary. This 
works for me. Is it possible add this kind of parameter for Framework class?
from .xmlreader import XmlReader

READERS = {'html': HtmlReader, 'htm': HtmlReader, 'xhtml': HtmlReader,
           'tsv': TsvReader , 'rst': RestReader, 'rest': RestReader,
           'txt': TxtReader, 'xml': XmlReader}

Original issue reported on code.google.com by jussi.va...@gmail.com on 21 Nov 2012 at 8:07

[GoogleCodeExporter]

I have been thinking about this kind of functionality earlier and actually 
proposed it in comments of issue 1189. I think this could be implemented so 
that you could specify new parsers, and override existing, from the command 
line, for example, like `--parser XML:XmlReader`. Shouldn't be too complicated 
to implement. What do you think?

Original comment by pekka.klarck on 21 Nov 2012 at 11:27

• Changed state: Pending

[GoogleCodeExporter]

Sounds good. New parser is appended to dictionary and override if there is key 
for that file extensions. Right? 

Original comment by jussi.va...@gmail.com on 23 Nov 2012 at 7:40

[GoogleCodeExporter]

Yep, new parser should be added to the dictionary and be used with the 
registered extensions. I would like all these features to be implemented:

1) Register new parsers for new extensions (e.g. xml:XmlReader)
2) Register existing parser for new extension (e.g. rhtm:HtmlReader)
3) Register new parsers for existing extensions (e.g. html:MyParser)
4) Disable existing parsers (e.g. html:NONE)

Original comment by pekka.klarck on 26 Nov 2012 at 8:12

[GoogleCodeExporter]

Jussi, is the XmlReader you have implemented generic? Would you be interested 
in releasing it as a separate project? That would make it more attractive for 
us to implement this feature. Possibly it could already be done in 2.7.6 along 
with related issue 1018.

Original comment by pekka.klarck on 26 Nov 2012 at 8:13

[GoogleCodeExporter]

Issue 1189 has been merged into this issue.

Original comment by pekka.klarck on 26 Nov 2012 at 8:16

[GoogleCodeExporter]

I'm afraid it is not generic. 

Original comment by jussi.va...@gmail.com on 26 Nov 2012 at 8:39

[GoogleCodeExporter]

Any change you could make it generic?

Original comment by pekka.klarck on 3 Dec 2012 at 1:13

• Changed title: Possibility to use custom parser for test data

[GoogleCodeExporter]

here is my parser. As you can see content is not very generic. But perhaps you 
can use it as a reference or example.

Original comment by jussi.va...@gmail.com on 3 Dec 2012 at 2:53

Attachments:

• xmlreader.py

[GoogleCodeExporter]

Attached is a patch to implement user defined parsers, generally following the 
scheme described in comment 3 above by Pekka.

it provides a --parser command line option to specify an extension and class to 
handle the parsing, alowing reassignment of existing parsers to new extensions, 
or allowing new parsers to be added either for existing or new extensions. It 
does not allow disabling of a default parser, though that would not be hard to 
change.

Changes in the patch include modifications to support the new cli option, 
documentation updates, and a set of acceptance tests.  

Diff is based on today's trunk.

Original comment by ChrisPri...@gmail.com on 26 Feb 2014 at 5:20

Attachments:

• robotframework-1283.diff

[GoogleCodeExporter]

Great timing. I have just started work on parsers for .docx and .xlsx files, 
using 3rd-party python libraries.  I have a minimal-working example in a local 
clone of RF trunk, and about to start working on some test cases.  So the patch 
above would make this much easier if you were not interested in merging these 
parsers into the main project. I could set these up as a separate project, with 
an independent set of test cases.

I have some time to work on this further next week.   If you are going to merge 
the cli patch soon, I will hold off further work until it is available for me 
to complete the development.

Just also to say thanks for making RF so awesome.  I have recently introduced 
it into a major new project in a global investment bank with great success ... 
time to release new software changes into production has come down from about 3 
months to about a week, because we do almost all the testing using RF instead 
of hours of throwaway manual regression testing.

Original comment by adadcall...@gmail.com on 27 Feb 2014 at 7:53

[GoogleCodeExporter]

here's a clone with the changes applied (in the issue-1283 branch)

https://code.google.com/r/chrisprinos-robotframework-1283/source/browse?name=iss
ue-1283

Original comment by ChrisPri...@gmail.com on 27 Feb 2014 at 9:58

[GoogleCodeExporter]

I have uploaded the first experimental version of a pair of parser modules for 
Microsoft .docx and .xlsx formatted files using this new patch:

https://github.com/rjsmith/robot-ooxml

Original comment by adadcall...@gmail.com on 6 Mar 2014 at 10:52

[GoogleCodeExporter]

I really like the idea about being able to replace the built-in parser with a 
custom one I vote for this issue if it provides the ability to override 
built-in parsers for existing files (eg: use my own parser for .robot files).

Original comment by bryan.oa...@gmail.com on 14 May 2014 at 3:51

[GoogleCodeExporter]

Robot Framework is being migrated to GitHub and issues have already been moved 
to https://github.com/robotframework/robotframework/issues/. Old IDs are 
preserved so you can find this particular issue using URL like:

    https://github.com/robotframework/robotframework/issues/<id>

Original comment by pekka.klarck on 30 Jun 2014 at 2:12

• Changed state: Moved

[GoogleCodeExporter]

Hi Chris. I am trying to see if RF will agree to merge your parser patch. 
please see comment thread here:
https://github.com/robotframework/robotframework/issues/1283#issuecomment-775348
07

Would you be willing to submit a PR ?  Thanks again for your original work ....

Regards,
Richard

Original comment by adadcall...@gmail.com on 6 Mar 2015 at 10:56