Add keukenliefde parser

[jaapio]

This patch adds support for keukenliefde.nl

[jaapio]

@jayaddison i think it is better now, I merged the 2 loops into one large one.

[jayaddison]

Thanks! Looking pretty good - do you have an example recipe where the listitems (li tags) are used, to check the behaviour of those?

[jaapio]

I was just testing a bit more, but found some recipe that didn't work because the html is different, can I add a second test somehow to cover the other situations?

[jayaddison]

I was just testing a bit more, but found some recipe that didn't work because the html is different, can I add a second test somehow to cover the other situations?

Yep, you certainly can - for that I'd recommend copying the approach taking by an existing multi-test scraper.

For example, two tests for The Clever Carrot (note the different test_file_name setting in particular):

• https://github.com/hhursev/recipe-scrapers/blob/cde9382f4d3345acb550d8327ffc17c75debd974/tests/test_theclevercarrot_1.py
• https://github.com/hhursev/recipe-scrapers/blob/cde9382f4d3345acb550d8327ffc17c75debd974/tests/test_theclevercarrot_2.py

[jaapio]

Thanks, will have a look, I found out that some old recipes are different in html format, which will make it a challenge to make this work. But that's mostly my issue as this site seems to be a mess :-P

[jaapio]

I added 2 more test cases which brings the total number at 3:

1. normal case with paragraphs for the instructions
2. normal case with list items for the instructions
3. legacy format recipe without classes to match, which requires some guessing

I tried to extract methods when possible to reduce the number of duplicated lines in the code. And it should now not crash any more when something is a bit different from what we expected.

Please let me know what you think of this :-), should I extract the legacy format to another class or is it ok like this?

[jayaddison]

should I extract the legacy format to another class or is it ok like this?

Hmm, good question. Roughly speaking: I think the current approach with multiple fallbacks in a single class is fine here.

Trying to find a reason why that is / general guidance: firstly it's often down to what makes the code easiest to manage, with a large amount of personal preference. And by personal preference, I mean the scraper author (you in this case :)). So if you want, experiment with the alternative, and if you find that you have a clear preference, we can go with that.

The other consideration would be how much of the structure of the HTML page is shared. Generally I'd say that if most of the page is the same, then re-using a single class probably makes more sense. If there are three completely different page structures, then three different classes might be more likely to make sense.

[jaapio]

Think this is done for now, please let me know if other changes are required

[jayaddison]

Yep, looks good to me @jaapio - thank you for this contribution. If I had one minor nitpick it would be to add the same language coverage in all three test modules for consistency. That's optional though: I plan to merge this soon (within the next 30 mins or so) either way.

[jaapio]

Here you go sir, thanks for this project and your assistance!

As I'm working through my bookmarked recipes you can expect more contributions from my side.

[jayaddison]

Excellent, thanks! And you're welcome. Please do, and any feedback on improving the development process here would be gratefully received too.