[10:00AM] dylan_: hey
[10:00AM] slightlyoff: howdy!
[10:00AM] ttrenka joined the chat room. (10:00AM)
[10:00AM] ttrenka: i'm here
[10:00AM] slightlyoff: neat
[10:01AM] ttrenka: probably can't talk too long though
[10:01AM] slightlyoff: OK
[10:01AM] ttrenka: but while we wait...http://www.simonkelk.co.uk/mainframe-misc-heaven-sk.html
[10:01AM] ttrenka: some mild entertainment for you.
[10:02AM] dylan_: lol
[10:02AM] ttrenka: apparently I'm going to burn in HELL
[10:02AM] slightlyoff: nice
[10:02AM] ttrenka: :)
[10:02AM] dylan_: i've been enjoying paul graham's latest: http://paulgraham.com/hs.html
[10:02AM] ttrenka: yeah
[10:02AM] ttrenka: was reading that before, didn't realize that was a new one
[10:03AM] ttrenka: how long do we want to wait?
[10:03AM] dylan_: 5 min?
[10:03AM] ttrenka: ok
[10:04AM] dylan_: schontz might join, what about mda?
[10:04AM] slightlyoff: MDA isn't respoding to IM, so he seems doubtful
[10:04AM] ttrenka: david isn't signed in at all either
[10:04AM] slightlyoff: call him?
[10:04AM] slightlyoff: (schontz)
[10:04AM] slightlyoff: ;-)
[10:04AM] ttrenka: if you want
[10:04AM] slightlyoff: nah, no big deal
[10:04AM] dylan_: i have no cell service at my desk
[10:05AM] ttrenka: k
[10:05AM] ttrenka: someone want to explain this action tag, then?
[10:05AM] ttrenka: ;)
[10:05AM] dylan_: well, the idea was to treat events/actions like any other property set
[10:06AM] ttrenka: ok
[10:06AM] dylan_: and to support both normal dom style events, and AOP style advice
[10:06AM] slightlyoff: mda just joined the land o the living
[10:06AM] ttrenka: heh
[10:06AM] dylan_: if you haven't already, take a look at the files in /templates
[10:06AM] ttrenka: ok, let me do an update
[10:07AM] ttrenka: if I can
[10:07AM] slightlyoff: which ones? and which lines?
[10:07AM] ttrenka: bollocks
[10:07AM] dylan_: dojoml.xml, and exampleApp.xml, grep for event and connect
[10:08AM] slightlyoff: bollocks?
[10:08AM] dylan_: that's the latest work i've done on it, which was sometime last year
[10:08AM] ttrenka: yeah
[10:08AM] ttrenka: sorry, just figured out why I was having issues with SVN
[10:08AM] ttrenka: ok
[10:08AM] mda joined the chat room. (10:08AM)
[10:08AM] ttrenka: I'm seeing this:
[10:09AM] ttrenka:
[10:09AM] ttrenka:
[10:09AM] ttrenka:
[10:09AM] ttrenka:
[10:09AM] ttrenka:
[10:09AM] ttrenka: in dojoml.xml, right?
[10:09AM] dylan_: yup
[10:09AM] slightlyoff: hrm, does that mean that we never got around to the tag?
[10:09AM] slightlyoff: or is connect just a synonym?
[10:09AM] dylan_: same thing, just a different name
[10:10AM] ttrenka: ok
[10:10AM] ttrenka: still seems like DOM 0
[10:10AM] ttrenka: is that right?
[10:10AM] slightlyoff: not really
[10:10AM] ttrenka: in terms of a single function being assign
[10:10AM] ttrenka: assigned
[10:10AM] slightlyoff: I can have multiple sets of these
[10:10AM] slightlyoff: all pointing at the same function
[10:10AM] ttrenka: ...i actually see it as more of a cross between DOM 0 and XBL
[10:10AM] ttrenka: I think
[10:11AM] slightlyoff: and they can be set to be either before-advice, after-advice, or around-advice
[10:11AM] ttrenka: ok
[10:12AM] ttrenka: this is going to sound stupid.
[10:12AM] slightlyoff: so in the same waht that you could do __sig__.connect() or dojo.event.connect(), you use to accomplish method interception
[10:12AM] dylan_: so we had some issues when thinking about this before, but i want to get your opinion and ideas before getting into that :)
[10:12AM] ttrenka: but what's the issue?
[10:13AM] ttrenka: are you guys waiting for an opinion from me?
[10:13AM] dylan_: so i guess the first questions i have then are, does this make sense, is it flexible, does it do what it should, is it easy to use?
[10:14AM] ttrenka: oh ok
[10:14AM] mda: one thing that comes to mind is that with mandatory instance-to-instance wiring, you can't just say anymore "this is a click handler"
[10:14AM] ttrenka: concur
[10:14AM] mda: like if a container widget has 50 buttons in it.
[10:14AM] slightlyoff: yes
[10:14AM] dylan_: we would still allow that in inline markup
[10:14AM] slightlyoff: how?
[10:14AM] slightlyoff: I've actuallly hacked this in to the current system
[10:15AM] slightlyoff: where if you give the name of a function on the widget class to the ctor, it'll create a new anonymous function out of it
[10:15AM] slightlyoff: and then connect it
[10:15AM] slightlyoff: the problem with this is that it's limited to events that are explicitly supported
[10:15AM] dylan_: right
[10:15AM] mda: why is it so limited?
[10:16AM] slightlyoff: so there's a breif syntax on the template to allow attachment
[10:16AM] ttrenka: k
[10:16AM] slightlyoff: well, that was my concern, and why we're all in IRC today = )
[10:16AM] mda: if i've got a component that has an onX() function, it can be called for any X() event.
[10:17AM] mda: that isn't new, that is how VB, and lots of other method/property/events RAD systems do things.
[10:17AM] ttrenka: yep
[10:17AM] slightlyoff: right
[10:17AM] ttrenka: i have a q
[10:17AM] slightlyoff: but the DOM provide more events that we're currently supporting on these things
[10:17AM] ttrenka: how do the connect and event tags establish context?
[10:17AM] dylan_: that's one of the issues :)
[10:18AM] ttrenka: gotcha.
[10:18AM] mda: and does the handler get the identical args of the originating function?
[10:18AM] slightlyoff: yes
[10:18AM] slightlyoff: it's after-advice in the current system
[10:18AM] ttrenka: ok
[10:19AM] ttrenka: where does one define the handlers themselves?
[10:19AM] mda: so where is the side-effect context? like the glorious window.event?
[10:19AM] slightlyoff: my other concern is replacement
[10:19AM] ttrenka: (grill grill grill :))
[10:19AM] slightlyoff: heh
[10:19AM] dylan_: the handlers themselves are script
[10:19AM] slightlyoff: well, right now I think the side effect context is the place where we say new Function("this is some script");
[10:20AM] david_ascher joined the chat room. (10:20AM)
[10:20AM] slightlyoff: hi david!
[10:20AM] ttrenka: thta's not how it actually works, is it?
[10:20AM] david_ascher: hi all
[10:20AM] dylan_: hey david
[10:20AM] ttrenka: hi
[10:20AM] slightlyoff: actually, yes
[10:20AM] slightlyoff: (and I don't like it either)
[10:20AM] slightlyoff: let me get you code...one sec...
[10:20AM] ttrenka: using the new Function constructor?
[10:20AM] mda: but callee has to be able to find out stuff about the originating object right?
[10:20AM] slightlyoff: open problem
[10:20AM] ttrenka: executing it in the global context?
[10:21AM] mda: or is this another thing as a consequence of one-to-one wiring, there has to be a new function written for every handler to hardwire knowledge of the originator?
[10:21AM] mda: that doesn't sound right :)
[10:21AM] ttrenka: ugg
[10:21AM] slightlyoff: http://dojotoolkit.org/viewcvs/viewcvs.py/*checkout*/src/webui/widgets/Parse.js?content-type=text%2Fplain&rev=245
[10:21AM] slightlyoff: well, it's not one-to-one wiring
[10:22AM] slightlyoff: or rather, it's many to one, but you're only allowed to attach to the events we make explicit
[10:22AM] ttrenka: line #?
[10:22AM] slightlyoff: and that's my main concern with the system
[10:22AM] slightlyoff: grr, wrong file
[10:22AM] slightlyoff: one sec = )
[10:22AM] ttrenka: heh
[10:22AM] slightlyoff: http://dojotoolkit.org/viewcvs/viewcvs.py/src/webui/Widget.js?rev=246&view=auto
[10:22AM] slightlyoff: look at "mixInProperties"
[10:23AM] slightlyoff: or just search for dojo.event.connect()
[10:23AM] ttrenka: ok
[10:24AM] slightlyoff: the other half of this is in the template creation code
[10:24AM] ttrenka: no idea what rev I'm looking at, but it's line 149
[10:24AM] slightlyoff: let me find that
[10:24AM] slightlyoff: heh
[10:24AM] ttrenka: ok, here's a q.
[10:24AM] ttrenka: event.connect, when you pass it the "this" reference
[10:24AM] slightlyoff: that's the widget object
[10:25AM] ttrenka: is that where you are establishing execution context for the new Function?
[10:25AM] ttrenka: i.e. when that function is fired, is it firing in the context of "this"?
[10:25AM] slightlyoff: yes, implicitly, and badly
[10:25AM] ttrenka: ok
[10:25AM] dylan_: why badly?
[10:25AM] slightlyoff: 'cause it's not explicitly handled
[10:26AM] ttrenka: one of the big things I did when I did the event system for f( m ) was to get around this issue by making sure the first arg passed to any handler function was the context of execution
[10:26AM] slightlyoff: it's just a side effect right now
[10:26AM] dylan_: ok
[10:26AM] slightlyoff: ...and not the event object like a normal event handler would want?
[10:26AM] ttrenka: oh, that's the second arg
[10:26AM] ttrenka: :)
[10:26AM] slightlyoff: heh
[10:26AM] ttrenka: that's why every handler in f( m ) expects only 2 args
[10:26AM] ttrenka: source and event objects,
[10:27AM] slightlyoff: right
[10:27AM] ttrenka: it makes it a bit easier to write handlers against it.
[10:27AM] slightlyoff: well, we have something similar for around advice
[10:27AM] ttrenka: right
[10:27AM] ttrenka: but.
[10:27AM] slightlyoff: where if you want to really, really intercept the function, you get a context as an argument
[10:27AM] ttrenka: why is that not the default behavior?
[10:28AM] ttrenka: or are you executing the new Function object in context?
[10:28AM] slightlyoff: well, because it would make everyone write every function our way
[10:28AM] ttrenka: i.e. "this".call(funcObject)
[10:28AM] slightlyoff: instead of being able to retrofit old code with the event system
[10:28AM] ttrenka: ...and what's wrong with that idea?
[10:28AM] ttrenka: k
[10:28AM] ttrenka: wait
[10:29AM] ttrenka: above should be funcObject.call("this"_
[10:29AM] ttrenka: sorry
[10:29AM] ttrenka: whoops
[10:29AM] ttrenka: is being able to retrofit an existing app one of the primary goals of this system?
[10:29AM] david_ascher left the chat room. (10:29AM) Reason: " The IRC Client of the Gods! -> http://www.hydrairc.com <- HydraIRC"
[10:29AM] slightlyoff: yes
[10:29AM] ttrenka: why?
[10:30AM] slightlyoff: lower the barrier to entry, the better
[10:30AM] ttrenka: (I don't remember talking about this, that's all)
[10:30AM] ttrenka: ok
[10:30AM] slightlyoff: people shouldn't have to swallow a lot ot use Dojo
[10:30AM] slightlyoff: only what they want/need
[10:30AM] dylan_: the first hit is free
[10:30AM] ttrenka: in that case.
[10:30AM] slightlyoff: but we're digressing somewhat
[10:30AM] ttrenka: I would suggest that attaching an event should start off really simply
[10:30AM] slightlyoff: how the general event system works is orthoginal to how DOM-ish events
[10:30AM] slightlyoff: are handled
[10:31AM] ttrenka: I would think that Dylan's tag would be the initially used tag
[10:31AM] ttrenka: and attach it DOM0 style.
[10:31AM] ttrenka: make sure it executes in the context of the widget object.
[10:32AM] ttrenka: i.e. if I have a grid
[10:32AM] ttrenka: and I define the dojo:event tag in the propertyBag of the grid
[10:32AM] slightlyoff: right
[10:32AM] ttrenka: then i would expect my handler to either execute in the context of the grid object
[10:32AM] slightlyoff: but Mark's whole point was that it's heavyweight
[10:32AM] ttrenka: that syntax isn't heavyweight.
[10:32AM] ttrenka: limiting, yes
[10:32AM] slightlyoff: and that you should be able to say something like
[10:33AM] ttrenka: or grid onclick
[10:33AM] ttrenka: etc.
[10:33AM] ttrenka: is that right, mda?
[10:34AM] ttrenka: ...anyways..
[10:34AM] ttrenka: if the goal is to lower the barrier of entry, then the simpler the markup is, the better it is
[10:34AM] dylan_: i'm ok with an inline single attribute event handler definition in theory... just not sure how to specify what it applies to in the case of property sets that apply to a class or group of widgets
[10:34AM] slightlyoff: agreed
[10:34AM] ttrenka: so I would completely agree with mda on that one
[10:34AM] slightlyoff: but we don't want to cut out power too those who want it (namely, oursevles)
[10:34AM] ttrenka: and I'd probably even eliminate the propertyBag itself
[10:34AM] ttrenka: of course
[10:34AM] slightlyoff: so I think that keeping the tag is good
[10:35AM] slightlyoff: but we need somethign simple for direct attachment
[10:35AM] mda: (sorry in a con call, but i see that someone is agreeing with me....)
[10:35AM] ttrenka: what's wrong with doing that in code?
[10:35AM] ttrenka: np :)
[10:35AM] slightlyoff: heh
[10:36AM] ttrenka: how about something like this.
[10:36AM] ttrenka: 1. simple attachment:
[10:36AM] ttrenka:
[10:36AM] ttrenka: 2. complex attachment:
[10:37AM] dylan_: yes, but what goes inside the onevent?
[10:37AM] slightlyoff: code
[10:37AM] slightlyoff: event handler clode
[10:37AM] ttrenka:
[10:37AM] ttrenka:
[10:37AM] ttrenka:
[10:37AM] ttrenka: is sugar, more or less
[10:39AM] ttrenka: or we can provide a mechanism for attaching arbitrary events to any widget.
[10:39AM] ttrenka: sure
[10:39AM] slightlyoff: so that brings up the question I'm trying to get answered: what events do we support?
[10:39AM] ttrenka: I think that's dependant on the widget
[10:39AM] dylan_: i thought the whole point of advice was not having to provide such a mechanism... isn't advice just that mechanism?
[10:39AM] ttrenka: don't you think?
[10:40AM] ttrenka: is it?
[10:40AM] slightlyoff: advice will let you attach to whatever's already being fired
[10:40AM] dylan_: well, i guess something needs to trigger the advice
[10:40AM] ttrenka: ok
[10:40AM] ttrenka: I was completely off on that one :)
[10:40AM] slightlyoff: the question here is whether or not we should fire every possible event type or some subset
[10:40AM] slightlyoff: one sec
[10:41AM] ttrenka: k
[10:41AM] ttrenka: I would argue subset
[10:41AM] ttrenka: ...and give the ability to quickly extend if need be
[10:41AM] slightlyoff: http://dojotoolkit.org/viewcvs/viewcvs.py/*checkout*/src/webui/widgets/HTMLButton.js?content-type=text%2Fplain&rev=242
[10:41AM] slightlyoff: have a look at the last line
[10:41AM] dylan_: however, if it is something as strange as ... send a signal between these two widgets if the first widget has more than 8 rows, how is that really an event?
[10:42AM] slightlyoff: the event/message duality thing has nasty consequences
[10:42AM] ttrenka: what, dojoAttachEvent="onClick"?
[10:42AM] slightlyoff: (at times)
[10:42AM] slightlyoff: but that's not our problem
[10:42AM] slightlyoff: ahhh! good question!
[10:42AM] slightlyoff: when the template is parsed, we look for attributes called "dojoAttachEvent"
[10:42AM] ttrenka: ok
[10:42AM] slightlyoff: and then if there's a method on the widget class wit hthat name, we connect that event to that widget's named event
[10:43AM] ttrenka: i think you guys are making this too complex
[10:43AM] ttrenka: at some point, there will be a standard set of events that most widgets will support
[10:43AM] ttrenka: i don't see any reason to define this kind of flexibility into the system
[10:43AM] slightlyoff: there's also support for doing dojoAttachEvent="widgetMethod:onClick" to fire something other than a default-name method
[10:43AM] slightlyoff: dude, what I'm saying is that this wasn't "designed"
[10:43AM] slightlyoff: this particular thing is the hack I did to make this work
[10:43AM] ttrenka: it seems designed to me
[10:44AM] ttrenka: ok
[10:44AM] slightlyoff: but it seems to cover a lot of what you're discussing
[10:44AM] ttrenka: it does
[10:44AM] slightlyoff: so either we can talk about making it better or throwing it out
[10:44AM] ttrenka: heh
[10:45AM] schontz joined the chat room. (10:45AM)
[10:45AM] dylan_: about time, slacker :)
[10:45AM] schontz: heh
[10:45AM] schontz: I just figured out how to get this setup w/trillian
[10:45AM] dylan_: welcome
[10:45AM] ttrenka: heh
[10:45AM] schontz: I'm gonna be down for a few minutes while I travel to class
[10:45AM] ttrenka: ok
[10:46AM] ttrenka: well
[10:46AM] ttrenka: from what I'm seeing, and hearing...
[10:46AM] slightlyoff: so, the system as it stands now requires the widget author to be explicit about what events to attach from where
[10:46AM] ttrenka: I would argue that a widget would definitely have a predefined set of events.
[10:46AM] slightlyoff: OK
[10:46AM] ttrenka: right
[10:47AM] slightlyoff: and we don't support the full gamut of DOM events?
[10:47AM] slightlyoff: (unless the widget supports them all)
[10:47AM] ttrenka: and the reason why I'd argue that is because I think if we told joe average coder that they had to be explicit about attaching events, that would be a deal killer
[10:47AM] ttrenka: no, I don't think we should
[10:47AM] ttrenka: (the full gamut)
[10:47AM] ttrenka: but
[10:47AM] slightlyoff: they differ from browser to browser
[10:48AM] ttrenka: ...I think it wouldn't be a bad idea to offer a mechanism, through code, to be able to get at the internal event properties
[10:48AM] ttrenka: for the advanced coder, if you will
[10:48AM] dylan_: basically my viewpoint in general is this: the dom event mechanism pretty much sucks, and I want something better... but we need to support dom events because most people are used to that... now how do we effectively support dom events in a way that is as flexible as our other mechanisms for describing components
[10:48AM] slightlyoff: yeah, that makes sense
[10:48AM] slightlyoff: well, we can create the event handlers in a closure
[10:48AM] slightlyoff: and give them an implicit context object in their namesapce
[10:48AM] ttrenka: I think the basic idea here is to insulate someone from the browser differences
[10:49AM] slightlyoff: (instead of abusing arguments)
[10:49AM] dylan_: and namespace differences...
[10:49AM] slightlyoff: yeah, I agree
[10:49AM] ttrenka: if I have a button in HTML, and an button in SVG, I would want my event handlers to be the same
[10:49AM] slightlyoff: also agreed
[10:49AM] ttrenka: yeah
[10:49AM] ttrenka: so I would expect to be writing an onClick handler
[10:49AM] ttrenka: or an onButtonDown
[10:49AM] ttrenka: onButtonUp
[10:49AM] slightlyoff: yep
[10:49AM] dylan_: or something higher level like an onActivate
[10:49AM] slightlyoff: yes
[10:49AM] ttrenka: ...and I would expect that my handlers would be written similarly to DOM handlers
[10:49AM] slightlyoff: it's funny
[10:50AM] ttrenka: but they don't have to *be* DOM handlers.
[10:50AM] ttrenka: what?
[10:50AM] slightlyoff: as a side-effect, the current system supports almos all of that
[10:50AM] ttrenka: that's a plus, then.
[10:50AM] slightlyoff: we just don't have the context thing worked out
[10:50AM] ttrenka: less reworking
[10:50AM] ttrenka: ok
[10:50AM] ttrenka: connect needs to support that
[10:50AM] dylan_: yes, context has been our #1 issue
[10:50AM] ttrenka: ?
[10:50AM] ttrenka: ok
[10:50AM] slightlyoff: so it sounds like we need a couple of things now
[10:50AM] slightlyoff: 1.) to figure out what context we want to provide in the handler namespace, and at what name
[10:50AM] slightlyoff: 2.) a base list of dom-iish events to support
[10:51AM] ttrenka: honestly?
[10:51AM] slightlyoff: 3.) whether or not the current syntax for template authors to hook those things up is sane
[10:51AM] ttrenka: for context, I'd recommend just doing something like handler.apply(context, args)
[10:51AM] ttrenka: when the connect mechanism actually fires
[10:51AM] slightlyoff: OK
[10:52AM] slightlyoff: that's fine
[10:52AM] dylan_: ugh, an 11am meeting just showed up on my calendar
[10:52AM] slightlyoff: run away! run away!
[10:52AM] ttrenka: and pass the context when you do the connection.
[10:52AM] ttrenka: heh
[10:52AM] slightlyoff: so what should the context be? the widget?
[10:52AM] ttrenka: depends on how you connect it
[10:52AM] ttrenka: but yes, I would do it in the context of the widget.
[10:52AM] slightlyoff: so if I say "this" should it point to the widget?
[10:52AM] ttrenka: yes
[10:52AM] dylan_: well, defining handler that way assumes you know what the handler is going to be...
[10:53AM] slightlyoff: ok, that's sweet, it's like a 2-line fix = )
[10:53AM] ttrenka: you're writing the function already
[10:53AM] ttrenka: (not you, the general you)
[10:53AM] slightlyoff: yeah
[10:53AM] ttrenka: you might not know what the actual context will be, but you should have a good idea that it will be a button executing it
[10:53AM] slightlyoff: sounds sane
[10:53AM] slightlyoff: can someone come up with a list of events?
[10:53AM] schontz: how do events get attached/detached in widget land?
[10:54AM] dylan_: it feels limiting, but i'm not sure why
[10:54AM] slightlyoff: well, we still support
[10:54AM] slightlyoff: the power is there if you need it = )
[10:54AM] schontz: my thought is to mimic widget library events as opposed to DOM events
[10:54AM] dylan_: right, but we have the same context issue there as well, right
[10:54AM] slightlyoff: we're discussing about how to do both
[10:54AM] ttrenka: there is a code equivilent, right?
[10:54AM] slightlyoff: yes, of course
[10:54AM] ttrenka: then that's solved.
[10:54AM] ttrenka: :)
[10:55AM] slightlyoff: dojo.event.connect(widget, handler, myobj, mylistener);
[10:55AM] ttrenka: let's face it: a markup document describes the initial state of some application.
[10:55AM] slightlyoff: yep
[10:55AM] ttrenka: after the app is initialized, you're in code land and not markup land.
[10:55AM] slightlyoff: also agreed
[10:55AM] dylan_: ok
[10:55AM] slightlyoff: but the initial state goes a long, long way = )
[10:56AM] ttrenka: if handlers need to be added or removed on the fly, it will be done with code, or by interpreting new doc fragments that are also frozen in time.
[10:56AM] ttrenka: yeah
[10:56AM] ttrenka: of course
[10:56AM] ttrenka: we all on the same page?
[10:56AM] dylan_: yes, and the or by inter... is a big point btw
[10:56AM] schontz: does anyone but me think the widgets should have a shorthand widget.connectEvent(hadler, myobj, mylistener)?
[10:56AM] ttrenka: it's you
[10:56AM] slightlyoff: heh
[10:56AM] ttrenka: :P
[10:57AM] ttrenka: I think we've been implying that
[10:57AM] ttrenka: haven't we?
[10:57AM] slightlyoff: well, I haven't = )
[10:57AM] schontz: o
[10:57AM] slightlyoff: since this is mostly being done in the parser phase, I hadn't considered it
[10:57AM] ttrenka: the q has been whether or not we have events that are specific to widgets.
[10:57AM] ttrenka: right?
[10:57AM] slightlyoff: but it seems a good idea, doesn't it = )
[10:57AM] schontz: I just know I have a much easier time dealing with method name + fewer args
[10:57AM] ttrenka: it can be, sure
[10:57AM] ttrenka: stick it on the Widget class
[10:57AM] slightlyoff: yep
[10:58AM] dylan_: ok
[10:58AM] slightlyoff: and then implement our changes in the light of that
[10:58AM] schontz: well, if we have a decent event structure, then making an event specific to a/some widget(s) should be easy, no?
[10:58AM] ttrenka: yeah
[10:58AM] ttrenka: that's the idea
[10:58AM] dylan_: alex, are you going to put this log up somewhere?
[10:58AM] slightlyoff: yes, that's easy
[10:58AM] slightlyoff: um, where do you want it?
[10:58AM] schontz: and now, class. catch you guys in a few if you're there
[10:58AM] schontz: here, rather
[10:58AM] slightlyoff: (also, I'm going to be out of town starting in 2 hours or so)
[10:58AM] dylan_: somewhere in svn, perhaps
[10:58AM] slightlyoff: not the wiki?
[10:58AM] dylan_: in documents
[10:58AM] dylan_: or the wiki...
[10:58AM] ttrenka: heh
[10:59AM] dylan_: whatever... somewhere that we can all come back to it
[10:59AM] slightlyoff: OK
[10:59AM] slightlyoff: well, I'll throw it in SVN for now
[10:59AM] dylan_: ok, gotta go... have fun in tahoe... and everyone else, have a good weekend
[10:59AM] slightlyoff: later!
[10:59AM] slightlyoff: thanks for all your help
[10:59AM] ttrenka: np
[10:59AM] ttrenka: :)
[10:59AM] slightlyoff: oh! who's working up a list of events?
[11:00AM] ttrenka: I think that's dependant on the widget
[11:00AM] ttrenka: don't you think?
[11:00AM] slightlyoff: so there won't be a base list?
[11:00AM] ttrenka: no
[11:00AM] slightlyoff: hrm
[11:00AM] ttrenka: if there is, it will be really minimal
[11:00AM] ttrenka: like onInit?
[11:00AM] dylan_: i'll put some head time into some of this next week
[11:00AM] ttrenka: onShow, onHide?
[11:00AM] ttrenka: that kind of thing?
[11:00AM] ttrenka: onRender?
[11:00AM] slightlyoff: well, you can currently connect to any method on the widget with attribute syntax
[11:00AM] ttrenka: k
[11:01AM] slightlyoff: so you could easily listen to the show() and hide() methods by saying
[11:01AM] ttrenka: sure
[11:01AM] ttrenka: that's fine
[11:01AM] ttrenka: but you were asking about a base set of events
[11:01AM] slightlyoff: a consequence of me being lazy = )
[11:01AM] ttrenka: ?
[11:01AM] ttrenka: that all widgets would have
[11:01AM] ttrenka: right?
[11:01AM] slightlyoff: well, they'll get defined as stub functions on the base widget
[11:01AM] ttrenka: of course
[11:01AM] ttrenka: so I'd say onInit
[11:02AM] ttrenka: definitely without a doubt.
[11:02AM] slightlyoff: and you can remove them on your own widget by saying something like this.onWhatever = null;
[11:02AM] ttrenka: and possibly onRender
[11:02AM] ttrenka: sure
[11:02AM] ttrenka: maybe onDestroy
[11:02AM] ttrenka: and that would be it, no?
[11:02AM] slightlyoff: but things like onMouseMove and onClick and onKeyPress don't interest you?
[11:02AM] ttrenka: not if there's no point in the widget having it
[11:03AM] slightlyoff: hmm
[11:03AM] slightlyoff: OK, I'll have to thikn it over = )
[11:03AM] ttrenka: would I want to support MouseMove on a text input?
[11:03AM] slightlyoff: that's a good question = )
[11:03AM] ttrenka: events specific to the widget
[11:03AM] ttrenka: we just need to make sure we're consistent in naming conventions, that's all
[11:04AM] ttrenka: oh
[11:04AM] slightlyoff: right
[11:04AM] slightlyoff: and for template authors...
[11:04AM] ttrenka: and we need to make sure there's a canceling mechanism
[11:04AM] slightlyoff: ahh, that's a good catch
[11:04AM] ttrenka: (running across that problem now with f( m ))
[11:04AM] slightlyoff: any ideas on syntax? or would you do it in the handler?
[11:04AM] ttrenka: no idea
[11:04AM] ttrenka: that's the problem
[11:05AM] ttrenka: I don't really like the way it's implemented in the DOM, but there may not be a better way
[11:05AM] slightlyoff: mda, do you have any thoughts on canceling and bubbling?
[11:06AM] slightlyoff: so "no" then ;-)
[11:08AM] slightlyoff: so should we flag that for discussion later?
[11:08AM] slightlyoff: I don't think it'll keep us from getting the current todo list done
[11:08AM] ttrenka: sure
[11:09AM] slightlyoff: my last question is about the template syntax
[11:09AM] ttrenka: ok
[11:09AM] slightlyoff: good? bad? ugly?
[11:09AM] ttrenka: based on what? the template string you have in the Button widget?
[11:10AM] slightlyoff: yeah
[11:10AM] slightlyoff: = )
[11:10AM] ttrenka: um
[11:10AM] slightlyoff: sorry, it's my only data point
[11:10AM] ttrenka: it's not what I was expecting or envisioning.
[11:10AM] ttrenka: heh
[11:10AM] ttrenka: but close, I suppose
[11:10AM] ttrenka: :)
[11:10AM] slightlyoff: but it's how a template author can attach a DOM event to a widget event right now
[11:11AM] slightlyoff: is there anything you'd want to see fixed with it? what were you expecting?
[11:11AM] ttrenka: well
[11:11AM] ttrenka: to be honest, I hadn't gotten that far.
[11:11AM] ttrenka: :)
[11:12AM] slightlyoff: heh
[11:12AM] ttrenka: I was expecting that the template itself would be all HTML, no custom attributes.
[11:12AM] ttrenka: no assigned IDs.
[11:12AM] ttrenka: CSS info, though
[11:12AM] slightlyoff: well, we don't assign IDs
[11:12AM] ttrenka: well, we probably need to when the widget is inserted into the document
[11:12AM] slightlyoff: and the cutom attributes are for attach points into the widget object
[11:12AM] ttrenka: right
[11:12AM] ttrenka: except
[11:12AM] ttrenka: well
[11:13AM] ttrenka: let me ask this: where is the code that grabs that template string and inserts it into the document?
[11:13AM] slightlyoff: the other way to do this is to force someone to write a method that descends the DOM and handles the connection themselves
[11:13AM] ttrenka: ...and to be honest, that's exactly what I was expecting to happen
[11:13AM] slightlyoff: so the template string gets turned into a node, cloned, attached, and THEN inserted into the document once it's connected to the widget object
[11:13AM] ttrenka: with internal, private event handlers that tap into the DOM events, that fire off the widget ones
[11:14AM] ttrenka: so where does the "turning into a node" happen?
[11:16AM] ttrenka: ....well...
[11:16AM] ttrenka: I'll tell you what
[11:16AM] slightlyoff: one sec, let me find it...
[11:16AM] ttrenka: no, that's ok
[11:16AM] ttrenka: is anyone else still here?
[11:16AM] ttrenka: or is it just you and me?
[11:17AM] slightlyoff: I think it's you and me = )
[11:17AM] ttrenka: heh
[11:17AM] ttrenka: ok
[11:17AM] ttrenka: send me an email before you take off for Tahoe
[11:17AM] ttrenka: I'm heading home, gonna finish working from there
[11:17AM] ttrenka: have fun on de slopes :)
[11:17AM] dylan_ left the chat room. (11:17AM) Reason: Read error: 110 (Connection timed out)
[11:18AM] ttrenka left the chat room. (11:18AM) Reason: "Trillian (http://www.ceruleanstudios.com)"
[11:19AM] schontz_ joined the chat room. (11:19AM)
[11:19AM] schontz_: hola
[11:20AM] slightlyoff: it's all done but the shouting = )
[11:20AM] slightlyoff: I'll be posting the transcript, though
[11:20AM] schontz_: I see
[11:20AM] schontz_: alright
[11:21AM] schontz_: Glad I could be so helpful :P
[11:21AM] slightlyoff: = )
[11:22AM] schontz_ left the chat room. (11:22AM) Reason: Client Quit
[11:27AM] schontz left the chat room. (11:27AM) Reason: Read error: 110 (Connection timed out)