Nuances playing around with AngleSharp and Jint about anglesharp HOT 3 CLOSED

This is certainly a really useful list. Thanks a lot for writing it all down!

The AngleSharp.Scripting project is currently just a proof of concept, however, I will definitely continue to improve it. This will fix some of your problems, others will have to be solved in the core library. It is definitely on my list, since one of the goals I have for 0.9 (not the next, i.e. 0.8, release) is to run html5test.com, which requires a lot of JavaScript. Then eventually jQuery should also run out of the box. This will be an interesting moment.

Now to all your bullets (some of my thoughts):

1. You are totally correct. There must be a way of injecting missing interfaces. I already thought about this, because I realized that I can't provide all interface (implementations) and also I probably should not provide all. The IService interface is a hint where I am going with this, but more structure and more thinking is needed to come up with something really useful. The navigator object is also required for the html5test.com.
2. I think the official interface does not allow that, but it may be one of the APIs where AngleSharp could be more useful than browsers / APIs. I could decorate the JavaScript / DOM API to be getter-only and provide an additional setter for .NET.
3. Yes, the "new" way of doing things is with an event constructor. Until now AngleSharp implemented the old way, which was using a factory method on the document (createEvent) in combination with a special initEvent (this name is different for specialized events, but it is always init*, where * is the name of the interface) method. AngleSharp will also open up the constructor in v0.8.
4. Do you think this is generally the better way? I mean I coded the whole AngleSharp.Scripting library in a couple of hours and it is far away from being perfect. It was just meant as a starting point / proof of concept. I would happily see someone trying to improve it / fix such bugs. What you did seems like a good addition and should definitely be merged into the project.
5. I guess 4.) also applies here. Extensible should definitely be set and the rest as well.
6. Yeah you are right. Here the value should be transformed via some toString (maybe not the .NET ToString(), but rather a Jint wrapper, or something that behaves similarly) as a JS engine would do it.
7. Hm the readystatechange event should be raised automatically at the end of the document loading. Either the document has already finished loading or something weird happened. I'll have a look!

Again thanks for letting me know. If you have any useful additions to the Scripting project (as the ones noted above), then I would be more than happy to accept pull requests.

from anglesharp.

Thank you for your response.
Regarding the "fixes" for the Scripting library, please feel free to include them when you think it's better timing. Since it's a proof of concept project, I don't think there is any point in pulling in a request.
Also, no, I don't think my fixes are the "better way". It's just enough to have a working context on a window object!

As for the readystangechange, don't bother searching for a bug: I evaluated the javascript manually, after the dom was parsed, and that's why I wanted to raise the event myself.

Keep up the good work. I'll be definitely looking forward to 0.9 ;-)

from anglesharp.

I am closing this issue. It has been completely moved to the AngleSharp.Scripting repository. There the issue has been decomposed into smaller items. These items will be handled step by step.

from anglesharp.