I attempted a little version-control archeology to remind myself why I
made event handlers stop propagation by default. I made the change in
September 2009, but, poking around mailing-list traffic at that time, I
don't see any discussion of the issue.
What does everyone think? What's the right default behavior for an
event handler on a tag? It would be possible to change all events to
[transaction bool] instead of [transaction unit], so that the return
value is given literally; but that sounds like awkwardness that doesn't
pay its way for most cases.
Since stopping propagation was made the default, someone contributed
built-functions [preventDefault] and [stopPropagation], which correspond
to methods by those names on JavaScript event objects, in at least some
popular browsers. Would it make sense to (1) have event handlers return
truthy values by default (I believe Julian's patch has this effect) and
(2) require calling [preventDefault] or [stopPropagation] to change the
behavior?
On 05/07/2015 09:38 AM, Julian Squires wrote:
I tried to write something like the following:
datatype s = A | B | C
fun main () =
s <- source A;
return <xml><body><form>
<radio{#Test}>
<radioOption value="A" onclick={fn _ => set s A} />
<radioOption value="B" onclick={fn _ => set s B} />
<radioOption value="C" onclick={fn _ => set s C} />
</radio>
<dyn signal={v <- signal s;
return <xml><div>{[case v of A => "A"
| B => "B"
| C => "C"]}</div></xml>} />
</form></body></xml>
Because the onclick event handler produced is hard-coded to return
false, the radio buttons don't update correctly.
I have applied the attached patch to my own installation to get around
it, but I imagine this might break existing code. It seems like one
would want more explicit control of the return value of the event
handler.
_______________________________________________
Ur mailing list
[email protected]
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
