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
Friday, February 16, 2007
Making the leap to Java 1.5
Okay, so autoboxing sucks.
This was supposed to be a big feature that would save some typing, save some needless work and let things happen simply, the way the SUN intended.
Not so much.
There's no NULL handling behind the scenes, so with every autoboxing operation you do, you're just setting yourself up for an NPE. Forget it. Forget the three seconds of typing time you're saving and just leave the code the way it was. Obscure? Fine. Fuck it.
Don't use Objects, ever. Ever. Use primitives or you'll get some NPE you'll never chase down. The Classes have enough static members that use primitives that you'll never have to use an Object (hopefully) and then you won't have to worry about whether you're unintentionally autoboxing a stupid Object and setting yourself up for debugging hell.
Just use the primitives, man. And forget about autoboxing.
Until more later on,
Liam
This was supposed to be a big feature that would save some typing, save some needless work and let things happen simply, the way the SUN intended.
Not so much.
There's no NULL handling behind the scenes, so with every autoboxing operation you do, you're just setting yourself up for an NPE. Forget it. Forget the three seconds of typing time you're saving and just leave the code the way it was. Obscure? Fine. Fuck it.
Don't use Objects, ever. Ever. Use primitives or you'll get some NPE you'll never chase down. The Classes have enough static members that use primitives that you'll never have to use an Object (hopefully) and then you won't have to worry about whether you're unintentionally autoboxing a stupid Object and setting yourself up for debugging hell.
Just use the primitives, man. And forget about autoboxing.
Until more later on,
Liam
This still exists?
Okay, so I'm not working on an installer anymore, I'm not working in C++, C# or anything like that right now. I'm on a Java project.
So my first post this year in Intuitive Techniques will be this:
JAVA IS COMPLICATED.
All you people out there who say that Java is easier than C++ have no idea what you're talking about.
Sure there are a couple of things about C++'s memory management that are tricky, but Java has way more to it. Add to that the learning curve with all sorts of code-generation, frameworks, web programming and just about every kind of technology you can add and still call it a Java project and you have COMPLICATIONS.
Java-type and Java-based technologies on my current project:
Java (duh)
Ant tasks
JSP
Javascript
Apache Struts
JBOSS
Tomcat
Weblogic
Apache Struts-Bridge (it really is different from Apache Struts)
Liferay portal
Portlets
IntelliJ IDEA (which is the best IDE I've ever used)
QCommon - our own architectural framework
JUNIT
Put all of these together and you have a recipe for disaster. Somehow, though, the team I'm on has been able to keep up with a demanding schedule. I just wish I didn't feel like I was drowning most of the time.
I'll catch up. It's just a matter of when.
Yours in bugs,
Liam
(Next up: Java 1.5 -or- how to make something complicated easier to mess up.)
So my first post this year in Intuitive Techniques will be this:
JAVA IS COMPLICATED.
All you people out there who say that Java is easier than C++ have no idea what you're talking about.
Sure there are a couple of things about C++'s memory management that are tricky, but Java has way more to it. Add to that the learning curve with all sorts of code-generation, frameworks, web programming and just about every kind of technology you can add and still call it a Java project and you have COMPLICATIONS.
Java-type and Java-based technologies on my current project:
Java (duh)
Ant tasks
JSP
Javascript
Apache Struts
JBOSS
Tomcat
Weblogic
Apache Struts-Bridge (it really is different from Apache Struts)
Liferay portal
Portlets
IntelliJ IDEA (which is the best IDE I've ever used)
QCommon - our own architectural framework
JUNIT
Put all of these together and you have a recipe for disaster. Somehow, though, the team I'm on has been able to keep up with a demanding schedule. I just wish I didn't feel like I was drowning most of the time.
I'll catch up. It's just a matter of when.
Yours in bugs,
Liam
(Next up: Java 1.5 -or- how to make something complicated easier to mess up.)
Labels: Java
