|
|
webOS Nation Forums > webOS apps and software > webOS development > Style Question Re: JavaScript in WebOS App
These seem to be two different styles of JavaScript for WebOS development
[code]
function AppAssistant() {
});
}
AppAssistant.prototype.initialize = function() {
};
AppAssistant.prototype.setup = function() {
};
[/code]
[code]
AppAssistant = Class.create({
initialize: function(controller){
},
setup: function(){
}
});
[/code]
The first seems to be used more, but the second is more space efficient. Which do you prefer and why?
[code]
function AppAssistant() {
});
}
AppAssistant.prototype.initialize = function() {
};
AppAssistant.prototype.setup = function() {
};
[/code]
[code]
AppAssistant = Class.create({
initialize: function(controller){
},
setup: function(){
}
});
[/code]
The first seems to be used more, but the second is more space efficient. Which do you prefer and why?
The first does seem to be used more for the Assistants. I am not sure if there are any specific benefits over the class.create for the assistants.
Strangely, the Palm devs used the class.create more often for the stock apps, but the sample apps mostly used the AppAssistant.prototypes syntax.
However, for custom objects I always use the create.class method as it is definitely more flexible for those purposes.
Strangely, the Palm devs used the class.create more often for the stock apps, but the sample apps mostly used the AppAssistant.prototypes syntax.
However, for custom objects I always use the create.class method as it is definitely more flexible for those purposes.
I was noticing the difference between what Palm did and what Palm said. 
I have tried it both ways and don't see anything lacking with the later option. Just wondering if I missed something.
I have tried it both ways and don't see anything lacking with the later option. Just wondering if I missed something.
It's just a different way of constructing objects. There's no real difference I think except for the second one being a bit more appealing to people with a JAVA background.
I'm using the second one because it just looks better.
Either works I believe. Palm seems to have Prototype built into the framework, so that might be connected. I could be wrong, but it seems just a matter of preference.
Originally Posted by Jason Robitaille:
Either works I believe. Palm seems to have Prototype built into the framework and is a viable option. One just seems to be done with Prototype and the other seems without it. I could be wrong, but it seems just a matter of preference.
Either works I believe. Palm seems to have Prototype built into the framework and is a viable option. One just seems to be done with Prototype and the other seems without it. I could be wrong, but it seems just a matter of preference.
The prototype in this sense is nothing to do with the Prototype framework. It is a JavaScript property to add something to all instances of the object.
The first example is building an object and then adding on functionality down the file. The second is creating an object with all the functionality in one swipe.
I don't know if there is a performance advantage either way, other than reading and parsing the extra text for the first. There might be an advantage of not messing up the list in the second with a more formal "prototype" version.
The class.create syntax is part of the Prototype framework. The .prototype in the assistants is just plain old javascript.
Originally Posted by Blubble:
The class.create syntax is part of the Prototype framework. The .prototype in the assistants is just plain old javascript.
Ahh. Gotcha. That explains why it was vaguely familiar to me. I messed with Prototype a while back, but not much since.The class.create syntax is part of the Prototype framework. The .prototype in the assistants is just plain old javascript.
Dude, thank you for asking this question. I've been wondering the same thing. Although I was under the impression that they both used the prototype framework.
Coming from an ANSI C background (damn you OOP!) I can read the .prototype method a lot more clearly. It just seems to make more sense. For some reason, I feel like I should be reading the class.create method backwards. The use of colons reminds me too much of BASIC.
Coming from an ANSI C background (damn you OOP!) I can read the .prototype method a lot more clearly. It just seems to make more sense. For some reason, I feel like I should be reading the class.create method backwards. The use of colons reminds me too much of BASIC.
webOS Nation Forums > webOS apps and software > webOS development > Style Question Re: JavaScript in WebOS App
