Friday, February 23, 2007
Javascript
Yeah, I know. It doesn't do everything you'd want. It's got features that are incompatible with certain browsers. It's a quick and dirty patch when things don't work the way you'd like them to. My argument is: So what? If you don't like the browser-specific stuff, don't use it. Take the long way around and things will work just fine. Quick and dirty patches aren't necessarily a bad thing.
I had to do some client-side validation for a form (after having spent a couple of weeks implementing the exact same validation, server-side). It took me two days because Javascript just works. You don't have to mess around with someone else's broken or crappy API. You just have to make it work.
[Ranterator: on]
The server-side validation I was doing was for an update function. It needs to be on the server-side. The exact-same validation goes on client-side for a pay function. Don't ask why we can't validate the server-side stuff client-side. It hurts to think about it. Anyway, we currently use Struts Commons validator for server-side. It doesn't work. If you have an indexed field (which we do) for validation, it will validate a certain field (amount, date, whatever) up until it runs into an error, then it will crash and die.
Okay, that was overly dramatic. It will complete the rest of the form, it just won't continue to validate that one field. So if you have five entries and it fails validation on, say email address for the second one, it will validate the rest of the form, but all of the other email addresses after the second one will not be validated. Sure, that may be okay for some people, but we want all failed validations to show up. Three lines of code. Three lousy lines of code separated us from this functionality. But I can't change struts code. So I jumped in and tried to wrap their code, inherit from their code, play nicely with their code but all of their stuff is sealed. Not sealed so much as every fucking thing I needed to use was private. So, I said screw it. I wrote my own validation method and used their validation results object (messily and with empty fields that just had names). It worked but I felt like my brain needed a shower afterward.
[Ranterator: off]
When I was coding the Javascript side, I discovered why they put those three lines of code in there. It's hard to properly label a failed validation when failing one causes it to fail a bunch. So I can understand why that would have been a thought. But there are a thousand different ways to deal with that, two of which I implemented. One in Java (server-side) and one in Javascript.
Instead of validating all indexes of a field at once, validate the whole indexed thing at once, chaining the validations so that if it fails the most severe one, it doesn't move on. (null before formatting before value-specific stuff) But Struts can't do that for some reason, and they can't have us able to derive from their code, so the stupidity continued. But I fought through it and checked in some ugly, ugly code that does what I want.
So yeah, Javascript's cool.
I had to do some client-side validation for a form (after having spent a couple of weeks implementing the exact same validation, server-side). It took me two days because Javascript just works. You don't have to mess around with someone else's broken or crappy API. You just have to make it work.
[Ranterator: on]
The server-side validation I was doing was for an update function. It needs to be on the server-side. The exact-same validation goes on client-side for a pay function. Don't ask why we can't validate the server-side stuff client-side. It hurts to think about it. Anyway, we currently use Struts Commons validator for server-side. It doesn't work. If you have an indexed field (which we do) for validation, it will validate a certain field (amount, date, whatever) up until it runs into an error, then it will crash and die.
Okay, that was overly dramatic. It will complete the rest of the form, it just won't continue to validate that one field. So if you have five entries and it fails validation on, say email address for the second one, it will validate the rest of the form, but all of the other email addresses after the second one will not be validated. Sure, that may be okay for some people, but we want all failed validations to show up. Three lines of code. Three lousy lines of code separated us from this functionality. But I can't change struts code. So I jumped in and tried to wrap their code, inherit from their code, play nicely with their code but all of their stuff is sealed. Not sealed so much as every fucking thing I needed to use was private. So, I said screw it. I wrote my own validation method and used their validation results object (messily and with empty fields that just had names). It worked but I felt like my brain needed a shower afterward.
[Ranterator: off]
When I was coding the Javascript side, I discovered why they put those three lines of code in there. It's hard to properly label a failed validation when failing one causes it to fail a bunch. So I can understand why that would have been a thought. But there are a thousand different ways to deal with that, two of which I implemented. One in Java (server-side) and one in Javascript.
Instead of validating all indexes of a field at once, validate the whole indexed thing at once, chaining the validations so that if it fails the most severe one, it doesn't move on. (null before formatting before value-specific stuff) But Struts can't do that for some reason, and they can't have us able to derive from their code, so the stupidity continued. But I fought through it and checked in some ugly, ugly code that does what I want.
So yeah, Javascript's cool.
Labels: Javascript, rant, Struts, validation
# posted by Liam J. @ 8:28 AM 
