#Prodigy hacks javascript manual
(With the choice and manual NER interface, we ended up adding "accept" and "spans" as well.)Īnyway, I’m curious to hear your thoughts on this! ( Here’s a related discussion on user input fields in Prodigy btw.)Īllowing it to freely edit annotation tasks is potentially problematic – a small bug or inconsistency can easily ruin an entire dataset without the user even noticing. So initially, the front-end’s editing privileges were limited to the "accept" property only. Allowing it to freely edit annotation tasks is potentially problematic – a small bug or inconsistency can easily ruin an entire dataset without the user even noticing. After all, this API already exists: it’s HTML and JavaScript.Īnother question is how opinionated we want the Prodigy app to be, and to what extent the front-end should be allowed to modify the incoming data. However, It still feels more natural to me than reinventing the wheel and coming up with our own templating API – like, an arbitrary JSON format or something like that. This seems doable – I’m just not sure if it’s a reasonable approach. But markup added via dangerouslySetInnerHTML is essentially a black box, so it would always require the front-end to actually parse the HTML and convert it to React elements.
#Prodigy hacks javascript how to
In theory, we could also allow users to add custom hooks to their markup to tell Prodigy how to pass values forward (like ).
![prodigy hacks javascript prodigy hacks javascript](http://cache.hackedonlinegames.com/uploads/games/pictures/472/pFCN6OJKEVMJ6.jpg)
To my surprise, it worked – but it still feels very wrong. I did experiment with a few possible solutions, including some crazy stuff like evaling raw JSX with Babel.
#Prodigy hacks javascript code
So executing random user code wouldn’t be a problem either – but it also wouldn’t be very useful.
![prodigy hacks javascript prodigy hacks javascript](http://photos1.blogger.com/x/blogger/3402/1340/400/614554/urlremoval_blogpost9.png)
This is pretty difficult.īecause Prodigy is a developer tool and only intended to be hosted internally, preventing cross-site scripting isn’t such a high priority here. The main problem is that in order to interact with the current annotation task that’s displayed, user scripts would also need to be able to call the pre-compiled app’s internals (more specifically, dispatch an action). Thanks – this is actually something I’ve been thinking about a lot, and I still don’t have a perfect solution. I’m not blocked on this now, but I want to bring it up for a discussion because I think allowing scripting will lead to much more interesting custom templates. I can’t really approach this kind of problem without being able to include scripts. This should allow me to generate multiple examples for the DB when they do finally accept/reject the example. I’m interested in generating more than one example from a single example being reviewed, so I would like to add new interactions that let the user give slightly more feedback before a yes/no. With open('recipes/textcat_eval.js') as txt: with open('recipes/textcat_eval.html') as txt: Perhaps a new recipe option to specify a single script file that will be injected into the base page, when combined with an html_template, e.g.
![prodigy hacks javascript prodigy hacks javascript](https://i.pinimg.com/originals/38/59/19/385919c6bc3f98e554ff8eba88f4eed9.jpg)
I saw a suggestion that maybe static/index.html could be modified to include a script, but I don’t think that’s a very workable solution (unless I misunderstand) because you’d have to copy the files into or out of site-packages. There’s a react github discussion about it, but the TLDR is it looks like ele.innerHTML = '.' doesn’t work. I’m having a difficult time getting prodigy to allow custom scripts in my recipe specific templates, e.g.