IE6 and input type changes: short answer, ie6 sucks, long answer:
The Problem
I ran into another problem the other day native to ie6 (well ie7 and ie8 too, to be fair) where by I was trying to dynamically change a text input field from type=”text” to type=”password”. Safari, chrome and firefox had no issues. It was a simple as node.type = ‘password’, or since I was using mootools, node.set(’type’,'password’). Resolved. But wait…
Then I ran into IE6, whereby I got a nice “This command is not supported.”. It took me a while to figure this out. At first I thought the node didn’t have mootools ’set’ method for some reason (didn’t access it right?), but once I found out the reason, I looked for workarounds. None really. Other resolutions that attempted completely different code, but no workaround for IE6 specific to change the type. It seemed microsoft had decided that an input field’s type should not be able to change after it’d been loaded. I’ll get to that in a second
My Resolution
Spit out password fields on the page for when it gets sent back to the client. When the DOM has loaded, iterate over the input[type=password] fields (I did this via the mootools selector node.getElements(’input[type=password’)), make them hidden (via add a class or adjusting it’s style property), and make a new node that has an input type with the text value. I added the same classes to it as the password node had. When a user focused on the field (the text one that was originally a password field), I destroyed it, and removed the hidden class.
What really bothered me
“This is an expected behavior. One can’t change the type of an INPUT element once it is already created and became part of the DOM. The behavior is documented below in the Remarsk Section:”
That was microsoft’s response in their developer forums. That was last year, and instead of addressing it as an issue and complying with a standard, they were stubborn and basically refuted the claim as a bug. I’m not sure how I feel about the standard. I understand why an input type is set after the DOM has been loaded. I can’t change a tag type from div to span after the fact (or at least I shouldn’t be able to). Ideally, in my own head that is, every input type should have a separate tag value. <button />, <select />, <file />, <text />, <textarea /> and <password />. I think that’d be ideal, and save a lot of confusion.
Either way, that’s my resolution. M$ response is kind of sucky, but what can ya do.
PHP: Abstract classes vs static classes; whats what?
In the past I’ve spent a great deal of time trying to understand the different between PHP5 abstract and static classes/methods. I find out, use the differences on whatever I’m doing, and the forget. No more. I will document my understanding here to help myself, and some day others, out.
Methods (not classes) can be defined as static (eg. not static class Oliver{} but rather static function talk()) in order to call them without going through an instantiated object. From my perspective, it makes code cleaner and less messy by wrapping related functions in a class wrapper instead of defining them globally. It should be noted though, that classes with static methods CAN be instantiated, and those methods can be called either statically (via the :: double colon notation, or via the -> right arrow notation on the instantiated object).
That takes us to abstract classes. Abstract classes CANNOT be instantiated. They can be the parent of a class which can be instantiated, but they themselves cannot be. So for example, if I have two types of users, RegularUser and AdminUser, I could create an abstract class User which defines method signatures (via the abstract keyword) like abstract function login($username,$password){} or I can define static functions which can be called (via the same rules as above). A new User object can never be created directly though.
So what does that mean in terms of real-world usage? Personally, if I don’t want a class every to be instantiated, such as a class that has utility functions or string manipulation functions, I will define it as abstract, and define all it’s methods to be static. If I have a parent object which should never be instantiated, I’ll do the same, but leave the method declarations to the child classes for the most part.
So then when do I use a normal class that happens to have static methods? I haven’t really. I’m sure there can be uses for it, but I’ve never found myself in a situation where I need to access an object’s method without the context of the object’s instantiation. Maybe it’ll come up one day, but as I’m moving closer and closer to a full mvc based coding life style, I have a feeling that I won’t find myself in that situation anytime soon.