The single most annoying thing about Python is that I expect it to be harder. I know that's totally strange, but I've been conditioned by years of programming other languages to expect to need a man page (or an O'Rielly book) to be able to pick up something new. To understand the API, I've come to expect JavaDoc-type verbose documents that explain every argument in the slightest detail.
But Python makes a good portion of that useless. It meets me where I am and uses what I know in ways that I'm comfortable with. It's the perfect language, the one I've wanted forever, and now that I have it, I don't know what to do with it. I get caught up in trying to find this reference or that book to make sure I'm doing things right. I get hamstrung by the very training that has helped me survive so many other languages.
This is totally maddening. It shouldn't be this easy.
The event handler problem is (more or less) solved.
Instead of the hacked up solutions I was proposing below, I've come up with a (possibly) better hacked up solution. What I'm proposing is that NW should define all event handlers needed to run the environment page for the page writer. No fuss, no ungodly long <body> tags.
But, of course, there's a problem. In IE, when I set an event handler programatically, I'm doing just that, setting it. Not appending to a set of handling functions, no, I'm just setting it. Mozilla's addEventListener function is much nicer, and can work in conjunction with inline definitions on tags, but alas I'm looking for a cross-browser solution here that doesn't suck, and coming up short.
Worst case (for now), we might have to dictate that page writers set handlers on the body function only through methods we define, and never directly on the tags themselves. It's onerous, and I'm not convinced that it's better in the short run, but I think it might be a good thing moving forward.
Time will tell.
So I just got out of a poly-sci exam. Allow me to relate the tale...
I overslept this morning, deftly sleeping through latin (and I wasn't there, making it worse). When I awoke, it was nearly noon. Not a good thing. My class starts at noon. Damnit.
On the upside, the bus doesn't come 'till 12:08 or so, so I've got 2 minutes to find socks, pants, a shirt that doesn't smell or look too bad, and schlep down to the bus stop. I find clothes (after a fashion) and make it down to the bus just in time. Now you see, my class is on the "far" side of campus as far as the bus route is concerned, so despite the fact that I got on the bus at like 12:10, I didn't actually get to class until 12:24. Remeber the exam started at noon. On the dot. I think I'm sunk.
So I arrive to class to find like 4 people left out of the 50 or so who normally attend. The prof hands me the exam and the scantron form. 12 minutes later, I hand them both back to him.
You know, I had expected more from some of my classes. I mean, this is a collage education I'm supposed to be getting, right?
I don't go to that class half the time because I know that if I show up every third class, read a bit, and attend at least one review session, I'll be able to ace the quizes and exams.
Good ideas are rarely convenient.
I've been trying to figure out ways to clean up the requirements that NW places on body tags for pages. Similarly, I've been trying to figure out ways to make keystroke events fire for the "selected" component, and nothing else, and today it hit me.
Instead of writing:
onLoad="__NW_env__.init();"
onmousemove="__NW_env__.setCurrXY(event);
onmousedown=" __NW_env__.selectAndResize(event);
onmouseup="__NW_env__.unsetSelectedComponent();"
onmouseover="__NW_env__.setTooltips(event);"
onmouseout="__NW_env__.disolveTooltips();"
for each body tag, we should be able to something like:
onLoad="__NW_env__.onLoad(event);" //console omitted
onmousemove="__NW_env__.onMouseMove(event);
onmousedown=" __NW_env__.onMouseDown(event);
onmouseup="__NW_env__.onMouseUp(event);"
onmouseover="__NW_env__.onMouseOver(event);"
onmouseout="__NW_env__.onMouseOut(event);"
etc...
and let each of those member functions of the environment core handle the dispatching. Better yet:
onLoad="NW_onLoad(event);"
onmousemove="NW_onMouseMove(event);
onmousedown=" NW_onMouseDown(event);
onmouseup="NW_onMouseUp(event);"
onmouseover="NW_onMouseOver(event);"
onmouseout="NW_onMouseOut(event);"
etc...
should also work, again dispatching each event to the proper functions and objects. I think such an approach will clean up environment pages considerably. But the part that's really exciting of my revelation was that for each of these new functions (likely memebers of NW_env), there should be an array of function pointers that widgets and components can add to and remove from at will. Each time said event fires, all of these FPs should also be called. Basically, each event will get it's own "registry" of function pointers. By doing this, we could put a bit of code in the component selection code that will allow us to "register" the selected component's keystroke handlers with the global event handler for keystrokes. The global handler can intercept any environment-level keystrokes, while passing the rest on to the registered FPs.
Modifications required to the core to make this happen:
- event specific wrapper functions in __NW_env__, register/unregister functions for FPs to each event.
- modifications to the setSelectedComponent() function to support FP registering
- modifications to the component class to support keystroke functions and registering with sub-components. Only top-level components should be registering with the environment, so sub-components should be able to register with the top-level comp for inclusion in the chain.
- modify earth days to include an extra 12 hours in order to have time to implement this.
The really exciting (I think) part about this approach is that it's going to let us do really neat effects based on events (movement, keystrokes, etc...) that would have required much more elaborate changes previously. In this way, we're exposing infinately extensible "hooks" into each event via the environment core. This way we can keep the environment pages clean and still give ourselves enough flexibility moving forward.
And I just finished the environment page tutorial. Damnit.
It occured to me yesterday that the netWindows site doesn't practice what it preaches. It's more or less a static site with a NW toolbar at the top. How utterly dull.
I think that moving to an XML or database backend with some python or PHP in the middle talking to a netWindows component really is the better way to make the site work if I'm going to continue to keep hacking on this thing. I mean, why save the "good stuff" for the sample environment page? I think I started thinking about all of this after tripping over idontsmoke.co.uk yesterday and being struck by the sheer simplcity of it.
But I don't have any idea what the NW component should look like or how it should behave. I think the behaviour is simpler than the look. I'm a back-end coder by habit and I like mucking in the bowels of an application/site. I'm good at it. Making it look nice? I wish I were good at that, but the harsh reality of life is that I'm not. So I'm open to suggestion on this one. Little boxes that you click and expand into things seem like a good idea. And they should get the content when requested. Not before. The whole site should be able to live on a single page (more or less). Not sure what to do about the help pages. They've got their own style sheet, and I think I'd have to write an addition to environ_core.js that lets me import styles from sheets into a running page. A big can of worms, that one.
Anyway, gotta go to another exciting and engaging (cough) poly-sci class. At least I've still got good books to read.
Older Posts
Newer Posts