For some reason, Sencha decided to NOT make every single component in their architecture raise a click event. I don’t comprehend this, but I’m sure they had good reasons – possibly performance, possibly scalability.
Whatever the reason, if you want to make anything clickable, it’s very simple. Simply add the following listener.
id : 'myLabel',
xtype : 'label',
html : '<div class="myHelpLabel"></div>',
listeners : {
render : function(c) {
c.getEl().on('click', function(){ this.fireEvent('click'); }, c);
}
}
Poof. Now you can detect when that element is clicked in your controller (if you’re using the Sencha MVC architecture).
init: function(){
this.control({
'sampleView #myHelpLabel' : {
click : function(c) {
// Do something brilliant
}
},
...
I found it… what’s the right word… puzzling when I worked at DaVita how I was approached on several occasions to remove, or alter information I had put on my blog about DaVita. It was nothing that exposed trade secrets, competitive advantages, or strategic initiatives. One time, it was simply the fact that I had the word DaVita in the blog post that somehow triggered a red flag, and I was instructed to redact it.
Now that I no longer work at DaVita and for Smith Micro, the company, while it doesn’t embrace social media, certainly isn’t completely ignorant of its power and possibilities. In a recent issue of Harvard Business Review, I very much enjoyed reading an article with interviews from senior people at large companies discussing how they are handling the social media beast.
Yes, all of them mentioned how security and leaking is an issue, but the companies who made online expression part of their corporate culture – rather than blocking all possible access by every employee – found that their teams went out of their way to responsibly share information when communicating online.
DaVita was a great company at managing, nurturing and supporting the local social interactions of people all across the company, but seemed clueless when it came to the online extension of those relationships.
I wonder how many companies out there are truly making an effort to embrace the future rather than sticking their heads in the sand and pretending that the change isn’t happening. Of course, there are some organization that simply cannot risk their teams having the ability to share information online while they are work – I understand that. However, it also appears that some companies hide behind this visage of “oh we’re working on far too important stuff to risk some stupid employee telling everyone about it” when they manufacture paper clips, or build medical devices, when the truth is that they simply don’t understand how to manage it.
Fear and ignorance are powerful motivators.
By popular demand, the next meeting for Pittsburgh JavaScript Developers will be about jQuery.
I can’t wait until the Windows port of Node.js is stable. I put together this great, simple application to show off at one of my Pittsburgh JavaScript Developers meetings, but it requires anyone who brought a laptop to connect to the building’s guest wireless network.
Well, when I hooked up my laptop and fired up my VMWare instance of Ubuntu, it failed to get an IP address from the DHCP server, so all my “hard” work was for naught. Therefore, I’m simply going to share my code with everyone and have you run it yourself, and anyone else in your office that can hit your machine.
Now.js is one of the most exciting Node modules I’ve run across. You can hit their website to read more, but this is how they describe what it does.
I have to admit, when I first hit the site, I was thinking, “Yeah, right.” Luckily my healthy skepticism was immediately dashed as I ran their example, and it worked! Without the need to change system settings, or add in a bunch of hoodoo-voodoo code somewhere else to make it look like real-time communication.
Anyway, go to their site, read up on it, and after you’ve run through their examples, come back here and grab my Beer Drinkers & Hell Raisers code from my Github account.
In there is three files, but you only need chat_server.js and beerdrinker.html.
The only modification you need to make is on line 22 of beerdrinker.html where you place the IP address of the machine that has Node running.
<script src="http://{insert IP addy here}:8081/nowjs/now.js"></script>
Now, technically, there’s more than 40 lines of code when you count all the HTML and additional Node code I have in there to enable the file serving… BUT the code that makes my cheesy beer drinking game work is 39 lines of code (amazingly, only 8 lines at the server!).
Once you clone the repo locally, simply execute -
node chat_server.js
And then have your friends hit http://your.ip.address/beerdrinker.html. All you need to do is -
More of a personal post for future reference, but in case anyone else stumbles across this, let me know if you have a better way of doing this.
I’m writing an application with ExtJS 4 and when the user clicks on the close button a Window header, I simply want to close it and reset the state on the parent window. However, when the user clicks on the Save button, I want to perform some other actions and then close the child window and the state of the parent window’s controls will be something else.
My problem is that in the MVC architecture defined in ExtJS 4, I only had the child window’s close event on which I could listen – that event is fired when the user clicks on the header icon, and when I execute window.close() in the save method’s logic.
Anyway, the only way I could capture when the user clicked on the header close icon was to override the Ext.panel.Panel method initTools(). I simply copied the entire method from ext-debug-all.js and changed which method handles the header button click gesture. I then added the headerClose() method which is basically the close() method but with an added event being fired – headerclose.
Ext.define('MyApplication.Child.Window' ,{
initTools : function() {
...
if (me.closable) {
me.addClsWithUI('closable');
me.addTool({
type: 'close',
handler: Ext.Function.bind(me.headerClose, this, [])
});
}
...
},
headerClose: function() {
if (this.fireEvent('beforeclose', this) !== false) {
this.fireEvent('headerclose', this);
this.doClose();
}
}
};
Now, in my controller I can handle that gesture specifically while handling the more general close event in a different way.
/*
* Action handler for when the user clicks on the window close button
* on the child window, while the general close event does nothing
*/
'childWindow': {
headerclose: function() {
this.resetParentState();
},
close : function() {
// Just a stub to show nothing is done on close()
}
},
'saveButton': {
click : function(button) {
doSomethingVeryCool();
button.up('window').close(); // This will not reset the state of parent window
}
}