Marc-André Lafortune
Marc-André Lafortune
This PR isolates conflict handling in an `Enforcer` class. A basic implementation with policty of `:accept`, `:warn` or `:raise` and a `DiagnosticsEngine` insures compatibility. @iliabylich I didn't update the documentation...
Using `memory_profiler` on RuboCop revealed a lot of allocations from `TreeRewriter`. Before looking at reducing the number of allocated `TreeRewriter`, I thought it best to look at that class first....
The docs at https://whitequark.github.io/parser/ are 7 years old, but still linked from the README
The current `inspect` methods for most classes are not very usable: ```ruby @corrector= #:accept, :different_replacements=>:raise, :swallowed_insertions=>:raise}, @source_buffer= #0, 31=>0, 102=>0, 166=>0, 268=>6, 343=>6, 421=>6, 492=>6, 571=>6, 646=>6, 722=>6, #... @line_for_position=...
There should be an [easy way to bypass validation](https://stackoverflow.com/questions/59559304/how-to-prevent-parsley-validation-when-submit-form/59568567). Currently, the return value of the `form:validate` and `field:validate` are ignored, but it could be nice to allow skipping validation.
With the right set of feature, there shouldn't be a need for `addError`, `updateError` and `removeError`. Others?
`extra/bind` is set to be removed in v3. If you need some of that functionality, please comment below, so we can figure out the best way to get it rolled...
A missing feature is to handle interdependent fields better. I'm trying to see how we would group those, and maybe something as simple as `data-parsley-multiple="some-unique-name"` would be good enough. Here's...
Can we deprecate doing anything before loading `Parsley`? I don't really see an upside, there shouldn't be any need for it. Load `parsley`, then do whatever you want with it....
HTML5 `type="email"` accepts the `multiple` attribute when requesting a list of emails. Parsley should look for that attribute...