Sail can also be used to send data back to the app. This is done via HTML forms - and with embedded JS in limited circumstances. Because of the simplicity of sail pages, and near unlimited bandwidth+compute (for the average user), we can just send forms back to our app, and then send back a newly rendered sail page. This
1) Game board should be reset with a button.
using a form, we submit an HTML5 POST Request to the back end. Without an action attribute, it is just send to our back-end naturally.
This is intercepted by the ++on-poke arm of TWUI, and hits the +http-response arm.
for the reset, the following has to happen:
=^ : call the ttt+on-poke arm, and get back the [state (cards)] that the app produces.
state overwrites game, and updates app.
we extract the state, confirming that the board has been reset.
then, we call the sail page with the updated board (using ++onsave and zapgar).
2) Users should be able to click a board square, to place a move on the board.
This was ultimately scrapped - as we only need a one way display for the app, for students.
Sail can also be used to send data back to the app. This is done via HTML forms - and with embedded JS in limited circumstances. Because of the simplicity of sail pages, and near unlimited bandwidth+compute (for the average user), we can just send forms back to our app, and then send back a newly rendered sail page. This
1) Game board should be reset with a button.
2) Users should be able to click a board square, to place a move on the board.
This was ultimately scrapped - as we only need a one way display for the app, for students.
Hours: 6