Last modified: 2014-03-11 02:04:57 UTC
Currently: * byteLimit() will internally do all kinds of event binding to get notice of changes. * We have our own 'change' callback for InputWidget elements. * in mw.ViewPageTarget we use our 'change' event, our own getValue, manually run it through byteLength (not byteLimit), in order to get the current length that we assume byteLimit got to as well. * When the length is exceeded by user input, byteLImit internally will start chopping off characters (or rather, cancel user events after it hit the limit, and falls back to chopping off characters until it fits again). Problems: * Mimics the change event. * Duplicates logic for byteLength outside byteLimit, this will fail if the logic changes, and already fails if the byteLimit has a filter callback. Ideally: byteLimit (standalone) * Its own on('change') - so we don't have to mimic it * Ability to retrieve byte length as perceived by byteLimit - so we don't have to reverse engineer it * Option to disable the chopping off (instead, more like Twitter where the underlying user interface element will allow new characters, but it will have an event like 'length-exceeded' and 'length-satisfied' or 'length-recovered' so we dan display a nicer user interface (e.g. make the number negative and red) or: Ideally: byteLimit (utility mixin) * Option to feed it change events instead of having it listen on its own. * Get back from each event – the current state (length exceeded or not, and what the length is, having taken the filter in account).
