Hi.
Users sometime accidently input space at the end. Then they can not figure out what happend themselves.
If we change v-model to v-model.trim, Vue will auto trim the space. Should the trim action be a default behavior?
1 Like
It does not seem like a bad idea, ie in a single-line text entry box like text-line I can’t think of a significant reason to preserve leading and trailing whitespace characters. To your point, it has a significant benefit especially for ID sorts of fields where the value entered needs to be matched in the future.
Overall, I agree, this seems like it would be an improvement.
For ID sorts of fields, there is some server side validation explicitly in services for certain IDs but it might be interesting to do something lower level to always trim leading and trailing whitespace when setting ID fields… perhaps not when doing a find (at least at the EntityFacade level) because that would make it impossible to do finds by existing IDs that have leading or trailing whitespace.
That gets me thinking maybe there is one downside to always trimming all text-line input, and that is when manually specifying an ID you won’t be able to specify IDs with spaces any more. There are workarounds for some things like by editing the URL (where most IDs are when used for navigation), but we may need an option to turn this off and then use that option on the Auto Screens and Entity Edit screens in the Tools app find forms (and possibly others).
I tend to follow the principal the computer should only do exactly what the user tells it to do (the trick is to figure out the best way to let the user specify exactly what they want to do). This is a good example of where it applies.
If the programmer assumes that the user will always expect the trim to be applied, then problems can happen when the users wants the trim not to be applied.
Instead of assuming that trim always applies, consider making it easy for the developer to allow for whitespace trimming when that’s needed.
Basically, I think a good default should be the minimal possible amount of code and complexity, so that it’s easy to add edge cases later when they apply.
Ok, I think make trim as default for text-line only, and add a attribute auto-trim='fase' when developers want the input as is.
It’s a non backwards compatible change. I think the default should stay the same and add an attribute for auto-trim that can be set to true to allow it.
Often times, if there is a required field, I will just input a space to submit dummy data because some data is required. This would break that use case.
As @michael pointed out this is technically not backward compatible, but is a minor enough behavior change that I don’t think it justifies a major version bump (or delaying until we do the 4.0.0 bump).
Related to that is considering what we want for the SimpleScreens screens… it seems like a good ides that probably should have been done before, and if we add it but not on by default then we’ll have to modify lots of lines in lots of files. From a quick search with most of the moqui components in place it looks like just a bit over 1,100 instances of ‘text-line’.
The body of functionality in SimpleScreens and other places is something I try to consider with all framework changes, many of which are meant just to improve the applications based on those screens and they are the closest thing to a large body of ‘real world’ code that we have easy access to for guiding framework design.
Another consideration is what is the design regardless of backward compatibility… and I think that answer to that is better to trim leading/trailing whitespace by default as it makes things less error prone for many cases for end users, even including things like addresses and phone numbers and such.
For the backward compatibility part the main thing we’d need is a note added in the ReleaseNotes.md file (in some components still .txt) where they’ve been mentioned for past releases, and where is intended for people to look for things related to updates and releases. One thing that is obvious pretty quickly in the ReleaseNotes files is that there have been a number of non-backward compatible changes in releases that only had a minor version bump, not a major bump as would be required for strict semantic versioning.
FWIW, strict semantic versioning is a bit cumbersome for something as big as moqui-framework/-runtime, and is one of the big reasons that many don’t even try to use it (like Linux for example, famously using the ‘feels right’ method for major vs minor version bumps). For my part, I like the idea of semantic versioning and thing it helps with communication and expectations. A major version bump makes sense when we know users will have to make changes or things will break (like the move to Java 11 and external ElasticSearch and such in v3), but otherwise it’s not such a big deal and the ReleaseNotes are adequate for communication. On the other hand, if Moqui were on version 27 instead of 3 it would look a lot more mature. 