fluid-work IRC Logs-2008-11-05

Owned by Fluid IRC Log Bot
Last updated: Nov 05, 2008Version comment
25 min read

[00:24:32 EST(-0500)] * ptmahent (n=ptmahent@74.12.29.122) has joined #fluid-work
[03:22:23 EST(-0500)] * ptmahent (n=ptmahent@74.12.29.122) has joined #fluid-work
[07:29:14 EST(-0500)] * ptmahent (n=ptmahent@74.12.29.122) has joined #fluid-work
[08:39:39 EST(-0500)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work
[09:02:26 EST(-0500)] * Justin_o (n=Justin@142.150.154.101) has joined #fluid-work
[10:15:32 EST(-0500)] * anastasiac (n=team@142.150.154.160) has joined #fluid-work
[10:26:47 EST(-0500)] * ptmahent (n=ptmahent@kb-v832-130-63-234-4.airyork.yorku.ca) has joined #fluid-work
[10:36:17 EST(-0500)] * apetro (n=apetro@wsip-98-174-242-39.ph.ph.cox.net) has joined #fluid-work
[10:56:20 EST(-0500)] * michelled (n=team@142.150.154.197) has joined #fluid-work
[10:57:15 EST(-0500)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined #fluid-work
[11:04:30 EST(-0500)] * theclown (n=theclown@guiseppi.atrc.utoronto.ca) has joined #fluid-work
[11:16:46 EST(-0500)] * ptmahent (n=ptmahent@kb-v832-130-63-234-4.airyork.yorku.ca) has joined #fluid-work
[11:35:51 EST(-0500)] * Justin_o (n=Justin@142.150.154.101) has joined #fluid-work
[12:05:23 EST(-0500)] * ecochran (n=ecochran@dhcp-169-229-212-12.LIPS.Berkeley.EDU) has joined #fluid-work
[12:28:20 EST(-0500)] * ptmahent__ (n=ptmahent@kb-v832-130-63-234-4.airyork.yorku.ca) has joined #fluid-work
[12:29:29 EST(-0500)] * apetro_ (n=apetro@12.164.139.7) has joined #fluid-work
[12:43:38 EST(-0500)] * jessm (n=Jess@c-76-19-199-61.hsd1.ma.comcast.net) has joined #fluid-work
[12:45:42 EST(-0500)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work
[12:54:43 EST(-0500)] * Topic is 'Hump Day' set by jessm on 2008-11-05 12:54:43 EST(-0500)
[12:59:39 EST(-0500)] * jacobfarber (n=Jacob@142.150.154.106) has joined #fluid-work
[13:28:39 EST(-0500)] <jessm> http://wiki.fluidproject.org/display/fluid/all+hands+meeting+Berkeley
[13:28:43 EST(-0500)] <jessm> fill in your fields!
[13:37:10 EST(-0500)] * apetro (n=apetro@wsip-98-174-242-39.ph.ph.cox.net) has joined #fluid-work
[14:48:02 EST(-0500)] * colinclark (n=colin@142.150.154.101) has joined #fluid-work
[14:49:27 EST(-0500)] <ecochran> hi folks, colinclark michelled mostly, I'd like to talk through a few InlineEdit issues
[14:49:37 EST(-0500)] <colinclark> ecochran: Sure, shoot.
[14:50:06 EST(-0500)] <ecochran> the first issue is that we currently have a finishedEditing function which is the way that developers grab updates to Inline Edit
[14:50:19 EST(-0500)] <ecochran> this feels like a holdover from before we had events
[14:50:31 EST(-0500)] <ecochran> and that we should be using the modelChanged event
[14:50:44 EST(-0500)] <ecochran> developers should just use a listener on that event
[14:50:53 EST(-0500)] <ecochran> does that make sense
[14:50:55 EST(-0500)] <ecochran> ?
[14:51:06 EST(-0500)] <colinclark> Yeah, it makes sense to me.
[14:51:22 EST(-0500)] <colinclark> So we've got this option called finishedEditing, which is a user-specified function...
[14:51:30 EST(-0500)] <colinclark> this is, as you say, a holdover from the pre-event days.
[14:51:52 EST(-0500)] <ecochran> there is also a afterFinish event but that doesn't care whether the data has changed, only that editing is done
[14:51:55 EST(-0500)] <colinclark> Since we've got a responsibility to keep APIs relatively stable, I think we shouldn't remove it, but should deprecate it.
[14:52:02 EST(-0500)] <colinclark> finishedEditing, that is.
[14:52:07 EST(-0500)] <ecochran> modelChanged only fires if data has changed
[14:52:23 EST(-0500)] <ecochran> colinclark: that was my next question, remove or depricate
[14:52:30 EST(-0500)] <ecochran> deprecate it is
[14:52:38 EST(-0500)] <colinclark> ecochran: Deprecate, then remove during 0.9.
[14:52:43 EST(-0500)] <ecochran> cool
[14:52:45 EST(-0500)] <michelled> makes sense to me
[14:52:57 EST(-0500)] <ecochran> the next question is what data needs to be sent along with modelChanged
[14:53:05 EST(-0500)] <colinclark> anastasiac: Since there's essentially no way to formalize a deprecation in JS, that's largely a documentation thing.
[14:53:07 EST(-0500)] <michelled> I'd recommend opening a JIRA marked for 0.9 so we don't forget
[14:53:15 EST(-0500)] <anastasiac> colinclark, got it
[14:53:26 EST(-0500)] <colinclark> michelled: Good idea. I see 0.9 as our chance to purge deprecated APIs in advance of 1.0.
[14:53:42 EST(-0500)] <michelled> lightbox should be deprecated then too
[14:53:51 EST(-0500)] <michelled> I mean purged
[14:54:03 EST(-0500)] <colinclark> yep
[14:54:12 EST(-0500)] <ecochran> purging sounds so painful
[14:54:28 EST(-0500)] <ecochran> are we ready to move on?
[14:54:48 EST(-0500)] <ecochran> I am recommending newValue, editField, viewElement
[14:55:05 EST(-0500)] <ecochran> but perhaps I should back up...
[14:55:30 EST(-0500)] <colinclark> yeah, I'd back up
[14:55:35 EST(-0500)] <colinclark> tell us what you're actually trying to do. (smile)
[14:55:48 EST(-0500)] <ecochran> what I would want to do as a developer is one of two things, change the UI knowing that the data has changed, and/or send data back to the server
[14:55:56 EST(-0500)] <ecochran> the latter is the most likely
[14:56:09 EST(-0500)] <ecochran> but I like dicking around with UI so I'd do that too
[14:56:27 EST(-0500)] <ecochran> (right now I'm flashing up a little "data updated" message)
[14:56:56 EST(-0500)] <ecochran> I need editField so that I can get name data for the server
[14:57:06 EST(-0500)] <ecochran> I need the newValue so I can send that to the server
[14:57:22 EST(-0500)] <ecochran> and I need the viewElement so that I have a good reference into the UI
[14:57:52 EST(-0500)] <ecochran> the editField is an OK reference but the viewElement is better since once the model has changed the editField disappears
[14:58:02 EST(-0500)] <ecochran> following?
[14:58:24 EST(-0500)] <colinclark> gimme one sec to catch up
[14:59:08 EST(-0500)] * anastasiac reviews the code so she can understand the issues
[14:59:48 EST(-0500)] <michelled> it actually feels to me that the two events would give you different things
[14:59:57 EST(-0500)] <michelled> the modelChanged would give you the new value
[15:00:09 EST(-0500)] <michelled> and the afterFinish would give you the element
[15:00:31 EST(-0500)] <colinclark> Yeah, you're touching on an interesting point here, michelled.
[15:00:49 EST(-0500)] <colinclark> modelChanged can't possibly provide view-related arguments when fired.
[15:00:56 EST(-0500)] <anastasiac> that's what I was wondering about
[15:01:02 EST(-0500)] <colinclark> The reason is that anyone could fire modelChanged.
[15:01:18 EST(-0500)] <colinclark> InlineEdit's model is fully transparent, so someone can poke around with it directly in code...
[15:01:19 EST(-0500)] <ecochran> yes, Undo/Redo should
[15:01:23 EST(-0500)] <ecochran> but doesn't right now
[15:01:30 EST(-0500)] <colinclark> and then fire modelChanged to let the rest of the world know that it's happened.
[15:01:39 EST(-0500)] <colinclark> ecochran: Undo/Redo should... ?
[15:01:48 EST(-0500)] <ecochran> yes!
[15:02:02 EST(-0500)] <ecochran> otherwise, InlineEdit won't know to send data to the server
[15:02:09 EST(-0500)] <anastasiac> ecochran, are you saying that undo/redo doesn't edit the model?
[15:02:28 EST(-0500)] <ecochran> it does, but modelChanged doesn't fire
[15:02:32 EST(-0500)] <ecochran> or I think that it does
[15:02:35 EST(-0500)] <ecochran> I haven't looked
[15:02:45 EST(-0500)] <colinclark> ecochran: No, I think you're right...
[15:02:56 EST(-0500)] <ecochran> I know that the event doesn't fire
[15:03:18 EST(-0500)] <colinclark> It listens for InlineEdit's own modelChanged events, but never fires them when it mucks with the model itself.
[15:03:23 EST(-0500)] <anastasiac> that sounds like a bug to me
[15:03:55 EST(-0500)] <ecochran> it mucks with the model directly then... not going through InlineEdits own model changing methods
[15:04:07 EST(-0500)] <ecochran> which would fire the event
[15:04:26 EST(-0500)] <anastasiac> right
[15:04:36 EST(-0500)] * colinclark is taking a minute to look more closely at the implementation.
[15:04:37 EST(-0500)] <ecochran> colinclark: when you say that modelChanged can't know about the view, are you saying "can't" or "shouldn't"
[15:04:41 EST(-0500)] <ecochran> ?
[15:04:46 EST(-0500)] <colinclark> ecochran: Both.
[15:05:45 EST(-0500)] <colinclark> Okay, so here's what is happening between InlineEdit and Undo.
[15:06:20 EST(-0500)] <ecochran> it "can" in the case of a user edit, since a user edit changes values in the that, that.viewEl and that.editEl, that have the information that I need... but as you point out there may be other cases
[15:06:50 EST(-0500)] <colinclark> ecochran: Right, meaning in other cases it can't.
[15:06:56 EST(-0500)] <colinclark> And that's where "shouldn't" applies.
[15:07:02 EST(-0500)] <colinclark> (smile)
[15:07:06 EST(-0500)] <ecochran> problem is that I'd need that information in the case of Undo/Redo as well
[15:07:31 EST(-0500)] <colinclark> So InlineEdit's updateModel() method ultimately is the one that fires modelChanged events.
[15:08:00 EST(-0500)] <ecochran> yep
[15:08:04 EST(-0500)] <colinclark> However Undo, as ecochran mentioned, directly modifies InlineEdit's model.
[15:08:13 EST(-0500)] <ecochran> seems that way
[15:09:39 EST(-0500)] <anastasiac> so ecochran, when a modelChanged event fires, why do you need to be informed about the elements?
[15:09:44 EST(-0500)] <anastasiac> (forgive a silly question)
[15:10:21 EST(-0500)] <colinclark> updateModel() and refreshView() are slightly odd beasts, in that they define this "source" argument that is completely unused. But that is a digression.
[15:10:46 EST(-0500)] <ecochran> well, the reason that I'm tripping over at the moment is a UI driven desire to toss up a "data changed" message inline with the element changed
[15:11:23 EST(-0500)] <colinclark> anastasiac: Eli's use case is really simple and interesting.
[15:11:26 EST(-0500)] <anastasiac> but don't you know which element has changed? it's the element that the model is associated with
[15:11:36 EST(-0500)] <colinclark> He only wants to POST back to the server when the data has actually changed.
[15:11:49 EST(-0500)] <colinclark> And when he does so, he wants to provide cues back to the user.
[15:12:04 EST(-0500)] <colinclark> At the moment, afterFinish or finishedEditing fire all the time.
[15:12:06 EST(-0500)] <anastasiac> I think I understand the use case, I don't quite understand why he needs the event to tell him which item changed
[15:12:23 EST(-0500)] <ecochran> also as a developer need to be able to get a reference to which data has changed so that I know where to save the newValue on the server
[15:12:26 EST(-0500)] <colinclark> anastasiac: How else would he know when a change was made?
[15:12:29 EST(-0500)] <colinclark> (tongue)
[15:12:32 EST(-0500)] * anastasiac wonders how ecochran feels abut being talked about in the 3rd person
[15:12:43 EST(-0500)] <colinclark> he loves it
[15:12:47 EST(-0500)] <anastasiac> no, the modelChanged would tell him that the change was made
[15:13:05 EST(-0500)] <anastasiac> but why does he also need to know the element? wouldn't he already know that?
[15:13:07 EST(-0500)] <colinclark> indeed
[15:13:13 EST(-0500)] <colinclark> how would he know that?
[15:13:17 EST(-0500)] <anastasiac> since 'he' in this case is the inline edit in question?
[15:13:23 EST(-0500)] <colinclark> Aha!
[15:13:29 EST(-0500)] <colinclark> You hit the nail on the head... sort of.
[15:13:29 EST(-0500)] <colinclark> (smile)
[15:13:34 EST(-0500)] <ecochran> I'm lost
[15:13:35 EST(-0500)] <colinclark> So here's the thing:
[15:13:43 EST(-0500)] * anastasiac has been writing documentation instead of code for too long
[15:13:45 EST(-0500)] <colinclark> Eli's working in the Section Info example.
[15:13:49 EST(-0500)] <colinclark> Go look at it for a second...
[15:14:00 EST(-0500)] <colinclark> http://build.fluidproject.org/fluid/sample-code/inline-edit/section-info/section-info.html
[15:14:05 EST(-0500)] * anastasiac looks
[15:14:57 EST(-0500)] <ecochran> I still can't remember how to do that bullet name thing you guys do... I learn it but then forget it
[15:15:01 EST(-0500)] <colinclark> So he's instantiating a whole fleet of inlineEdits in one shot.
[15:15:05 EST(-0500)] <colinclark> "/me:
[15:15:08 EST(-0500)] <colinclark> sorry
[15:15:10 EST(-0500)] * ecochran gets it
[15:15:10 EST(-0500)] <colinclark> "/me"
[15:15:14 EST(-0500)] <ecochran> thanks
[15:15:20 EST(-0500)] <ecochran> I'm still lost
[15:15:32 EST(-0500)] <colinclark> ecochran: hang on. you're not the one who's lost. (wink)
[15:15:34 EST(-0500)] * anastasiac thinks she's starting to get it
[15:15:42 EST(-0500)] <colinclark> anastasiac: So if you're invoking a fleet of inlineEdits with one function call...
[15:15:50 EST(-0500)] <colinclark> and you want to share your event handlers with all of them...
[15:16:01 EST(-0500)] <colinclark> how do you know which particular inline editor changed?
[15:16:09 EST(-0500)] <anastasiac> yeah, ok - I think I'm seeing it
[15:16:20 EST(-0500)] <anastasiac> isn't there some currying magic that could help here?
[15:16:21 EST(-0500)] <colinclark> lemme grab some code
[15:17:21 EST(-0500)] <ecochran> if anyone would like to see what i'm trying to do in action:
[15:17:23 EST(-0500)] <ecochran> http://dhcp-169-229-212-12.lips.berkeley.edu/fluid/sample-code/inline-edit/section-info/section-info.html
[15:17:48 EST(-0500)] <ecochran> I pulled this off by hacking modelChanged
[15:18:20 EST(-0500)] <ecochran> no guarantees that it works anywhere but FF/Mac
[15:18:23 EST(-0500)] <colinclark> So, in the end, a model-related event really can't pass you view stuff.
[15:18:35 EST(-0500)] <colinclark> But I was thinking about it earlier, while buying a bag of chips.
[15:18:36 EST(-0500)] <colinclark> (smile)
[15:18:39 EST(-0500)] <ecochran> humph
[15:18:49 EST(-0500)] <ecochran> so where does that leave me?
[15:18:58 EST(-0500)] <ecochran> damn those chips!
[15:19:00 EST(-0500)] <colinclark> Well, I just gave the other half of the bag to anastasiac.
[15:19:07 EST(-0500)] <colinclark> Since I ate too much sodium at lunch.
[15:19:11 EST(-0500)] <ecochran> damn half those chips!
[15:19:19 EST(-0500)] <colinclark> If you were here, I would have given them to you, ecochran.
[15:19:28 EST(-0500)] <colinclark> Shipping is expensive.
[15:19:31 EST(-0500)] <ecochran> (wink)
[15:19:37 EST(-0500)] <ecochran> happiness
[15:19:39 EST(-0500)] <colinclark> Apparently they are even kosher.
[15:19:51 EST(-0500)] <ecochran> wow, kosher chips
[15:19:52 EST(-0500)] <colinclark> So now anastasiac has competition for the chips from jacobfarber!
[15:20:01 EST(-0500)] <colinclark> Ok, anyway.
[15:20:04 EST(-0500)] <colinclark> Chips.
[15:20:21 EST(-0500)] <ecochran> I am hungry and in need of useful events
[15:20:29 EST(-0500)] <colinclark> Yes, okay.
[15:20:36 EST(-0500)] <colinclark> So model events can't tell you about views.
[15:20:52 EST(-0500)] <colinclark> And there's this fundamental question:
[15:20:54 EST(-0500)] <ecochran> but the View has changed ...
[15:20:56 EST(-0500)] <colinclark> Which "that" is that?
[15:21:03 EST(-0500)] <ecochran> so there could be a veiw related event
[15:21:06 EST(-0500)] <anastasiac> can the model event tell you about the 'that' it is a model for?
[15:21:11 EST(-0500)] <anastasiac> it should...
[15:21:17 EST(-0500)] <colinclark> This is the tip of a bigger iceberg that Antranig are slowly chipping our way at.
[15:21:26 EST(-0500)] <colinclark> But in the meantime, I think anastasiac is right...
[15:21:31 EST(-0500)] <colinclark> We can do this:
[15:21:31 EST(-0500)] <ecochran> plural Antranigs?
[15:21:37 EST(-0500)] <colinclark> sorry
[15:21:41 EST(-0500)] <colinclark> "Antranig and I"
[15:21:49 EST(-0500)] <colinclark> Plural Antranigs is a frightening thought...
[15:21:54 EST(-0500)] <colinclark> I'd retire instantly. (tongue)
[15:21:54 EST(-0500)] <ecochran> OK, more than one is ...
[15:21:55 EST(-0500)] <ecochran> yes
[15:22:05 EST(-0500)] <colinclark> So, how about this:
[15:22:06 EST(-0500)] <ecochran> one is delightful though
[15:22:14 EST(-0500)] <colinclark> modelChanged(value, that)
[15:22:38 EST(-0500)] <colinclark> This would give you pointers to everything you need. It's not ideal, but would solve the shorter-term problem.
[15:22:58 EST(-0500)] <colinclark> Since you could grab references to the various View-related elements from the component.
[15:23:15 EST(-0500)] <colinclark> The problem is that this is brittle... we know that Inline Edit has yet to be View-ified, but it will be soon.
[15:23:19 EST(-0500)] <colinclark> And those references may change.
[15:23:26 EST(-0500)] <colinclark> It is not ideal.
[15:23:57 EST(-0500)] * colinclark is thinking...
[15:24:02 EST(-0500)] <ecochran> seems that having the developer have to know what's in that is problematic
[15:24:16 EST(-0500)] <colinclark> In a way, it is.
[15:24:29 EST(-0500)] <colinclark> On the other hand, once APIs stabilize a bit, it shouldn't be problematic.
[15:24:36 EST(-0500)] <ecochran> right now I have:
[15:24:36 EST(-0500)] <ecochran> that.events.modelChanged.fire(newValue, that.editField[0], that.viewEl[0]);
[15:24:48 EST(-0500)] <ecochran> which is explicit
[15:24:53 EST(-0500)] <ecochran> but not "pure"
[15:24:54 EST(-0500)] <anastasiac> wait, what is not ideal about this?
[15:25:02 EST(-0500)] <colinclark> Since, if stuff is publicly visible on the that, they form part of a defined contract, which users should be able to rely on.
[15:25:12 EST(-0500)] <colinclark> ecochran: I don't think you need the quotes there.
[15:25:19 EST(-0500)] <colinclark> It's just not workable. (wink)
[15:25:38 EST(-0500)] <ecochran> OK
[15:26:05 EST(-0500)] <colinclark> anastasiac: What's not ideal is that we know Inline Edit is going to change shortly...
[15:26:13 EST(-0500)] <michelled> who listens to our events? is it just fluid components and fluid framework?
[15:26:26 EST(-0500)] <colinclark> and Eli will suffer when we refactor InlineEdit if he relies on pointers within "that."
[15:26:36 EST(-0500)] <colinclark> That said, there's nothing wrong with this. We just screwed up our API. (smile)
[15:26:39 EST(-0500)] <ecochran> in this case I am listening as a developer of SectionInfo
[15:26:42 EST(-0500)] <colinclark> michelled: Anyone who wants to listen to them.
[15:26:59 EST(-0500)] <anastasiac> ok, I see - so passing 'that' isn't the problem, it's relying on knowing the contents of 'that'
[15:27:04 EST(-0500)] <colinclark> michelled: They form a very public API.
[15:27:15 EST(-0500)] <michelled> so, for example, an integrator would write event handlers, correct?
[15:27:34 EST(-0500)] <colinclark> anastasiac: Exactly. Which really shouldn't be a problem, except that in this particular case, our 'that' is changing soon.
[15:27:49 EST(-0500)] <colinclark> Presumably we're going to have to be more careful to ensure backwards compatibility when we do refactorings like this.
[15:28:03 EST(-0500)] <colinclark> Building code that other people use in their code is hard.
[15:28:11 EST(-0500)] <colinclark> michelled: Yes, sure.
[15:28:13 EST(-0500)] <michelled> it feels funny to ask our integrators to know about the internals of 'that'
[15:28:21 EST(-0500)] <colinclark> michelled: But we're not!
[15:28:21 EST(-0500)] <ecochran> yes
[15:28:30 EST(-0500)] <ecochran> we're not?
[15:28:36 EST(-0500)] <colinclark> We're talking about the externals of 'that.'
[15:28:42 EST(-0500)] <michelled> ha
[15:28:43 EST(-0500)] <colinclark> Do you see what I mean?
[15:28:52 EST(-0500)] * ecochran doesn't
[15:28:59 EST(-0500)] <michelled> are you suggesting a constant API on all thats?
[15:29:07 EST(-0500)] <colinclark> Anything visible on a pointer to one of our component instances is public.
[15:29:10 EST(-0500)] <anastasiac> so the issue here is that we need a public api on inline edit that allows access to the view, without knowing the internals
[15:29:16 EST(-0500)] <colinclark> Anything that is public is an API.
[15:29:33 EST(-0500)] <colinclark> anastasiac: Again, this isn't about the internals! (tongue)
[15:29:42 EST(-0500)] <colinclark> things are just hanging around on the that
[15:29:49 EST(-0500)] <colinclark> and thus they are externals
[15:30:09 EST(-0500)] <anastasiac> ok, sorry for my slowness
[15:30:15 EST(-0500)] <colinclark> No, not slow
[15:30:18 EST(-0500)] <anastasiac> the issue is not internals, it's backward compatibility
[15:30:22 EST(-0500)] <colinclark> You're pointing out something very important:
[15:30:35 EST(-0500)] <colinclark> If things are publicly visible, they should be reliable and stable.
[15:31:50 EST(-0500)] <ecochran> I'm not sure that I agree that even though that is "public" that it should be part of the API of the component. Yes, people can use it... but should we be telling people to use it?
[15:31:54 EST(-0500)] <ecochran> does that make sense?
[15:32:21 EST(-0500)] <colinclark> If it's public, people will use it. That's the thing. And then they'll get mad at us when we change it. (smile)
[15:32:31 EST(-0500)] <colinclark> Such is the life of a framework author.
[15:32:31 EST(-0500)] <ecochran> true
[15:32:41 EST(-0500)] <colinclark> And we're all framework authors here.
[15:32:52 EST(-0500)] <colinclark> Except Eli with his Section Info implementor hat on...
[15:33:09 EST(-0500)] <colinclark> and that Eli is saying "why the hell can't I just do this seemingly simple thing, already?"
[15:33:13 EST(-0500)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work
[15:33:18 EST(-0500)] <ecochran> well, yes
[15:34:20 EST(-0500)] <ecochran> and as that implementor, I'd rather get handed just the data that I need, not go fishing about in your that
[15:34:33 EST(-0500)] <ecochran> (my perspective only)
[15:34:54 EST(-0500)] <colinclark> I agree.
[15:34:58 EST(-0500)] <colinclark> Thoroughly.
[15:35:50 EST(-0500)] <colinclark> ecochran: Do you actually use the viewElement in your hacked up version of the event?
[15:37:19 EST(-0500)] <ecochran> I do, because it was much easier to manipulate the DOM from the viewElement than the editElement... I coulda pulled it off with the editEl but it would've been a little more code
[15:37:36 EST(-0500)] <colinclark> Ah, I see.
[15:37:50 EST(-0500)] <ecochran> I'm not even sure where the right place for an integrator to hang data for the server is... this is a problem
[15:37:52 EST(-0500)] <colinclark> So you're using the viewElement as a starting point for doing some DOM manipulation.
[15:37:57 EST(-0500)] <ecochran> yep
[15:38:05 EST(-0500)] <ecochran> actually just parsing
[15:38:08 EST(-0500)] <colinclark> "Hang data for the server?"
[15:38:10 EST(-0500)] <colinclark> Can you elaborate?
[15:38:42 EST(-0500)] <ecochran> well, usually when working with data, you attach an id or name to a form element that tells you where that data lives on the server
[15:38:52 EST(-0500)] <ecochran> so that the server knows which data to update
[15:39:02 EST(-0500)] <ecochran> this works pretty well in the AJAX world too
[15:39:04 EST(-0500)] <colinclark> Right. Data binding.
[15:39:08 EST(-0500)] <ecochran> data binding
[15:39:17 EST(-0500)] <anastasiac> yes, wouldn't the renderer's data binding be helpful here?
[15:39:21 EST(-0500)] <ecochran> I knew there was some fancy word for it (wink)
[15:39:27 EST(-0500)] <ecochran> oh yes
[15:39:32 EST(-0500)] <colinclark> anastasiac: Someday it will be helpful here, yes.
[15:39:41 EST(-0500)] * anastasiac (smile)
[15:39:42 EST(-0500)] <colinclark> Today, probably not quite there yet.
[15:40:14 EST(-0500)] <ecochran> so today... when I send the page down, I need to put my data binding references somewhere
[15:40:39 EST(-0500)] <ecochran> I might prerender the edit fields and attach ids
[15:40:49 EST(-0500)] <ecochran> but I could also let inlineEdit render my edit fields
[15:40:58 EST(-0500)] <ecochran> then I would have to put my data ... where?
[15:41:08 EST(-0500)] <ecochran> ids on the viewEl's might work
[15:41:14 EST(-0500)] <anastasiac> would 'view'ifying the inline edit help address this issue?
[15:41:22 EST(-0500)] <ecochran> would work
[15:41:36 EST(-0500)] <ecochran> but right now there is no proscribed way
[15:41:42 EST(-0500)] <colinclark> ecochran: That's what Nico often used to do in MyCamTools...
[15:41:43 EST(-0500)] <ecochran> and maybe there doesn't need to be
[15:41:55 EST(-0500)] <colinclark> I think since then he has built a data binding framework for himself.
[15:42:10 EST(-0500)] <colinclark> Everyone is writing one these days, since everyone is encountering this same problem.
[15:42:13 EST(-0500)] <ecochran> should we make up suggested ways to do this? and then have the component "help"
[15:42:51 EST(-0500)] <colinclark> "How do I correlate my stuff in the DOM with my data and stuff that the server understands."
[15:43:06 EST(-0500)] <ecochran> exactly
[15:43:16 EST(-0500)] <colinclark> ecochran: The Fluid Renderer provides a data binder that will make it gloriously simple to handle this glue.
[15:43:19 EST(-0500)] * Bosmon (n=Bosmon@87-194-196-18.bethere.co.uk) has joined #fluid-work
[15:43:27 EST(-0500)] <colinclark> Look, it's Boz!
[15:43:33 EST(-0500)] <Bosmon> Oh, not HUMP DAY again
[15:43:43 EST(-0500)] <Bosmon> Surely that only comes around once a year...
[15:43:45 EST(-0500)] <ecochran> I'm not going there
[15:43:56 EST(-0500)] <colinclark> We are just floating around many questions related to events and now data binder.
[15:44:00 EST(-0500)] <colinclark> You will be interested.
[15:44:01 EST(-0500)] <Bosmon> I see
[15:44:05 EST(-0500)] <Bosmon> I can't stay for too long
[15:44:06 EST(-0500)] <colinclark> Bosmon: Check the IRC room logs.
[15:44:10 EST(-0500)] <Bosmon> But perhaps long enough to be interested
[15:44:16 EST(-0500)] <colinclark> (smile)
[15:44:20 EST(-0500)] <colinclark> Did you get a nap yet?
[15:44:33 EST(-0500)] <colinclark> Bosmon was up celebrating Obama's victory.
[15:44:46 EST(-0500)] <Bosmon> BAMER
[15:44:49 EST(-0500)] * anastasiac was up painting a cieling
[15:44:53 EST(-0500)] <ecochran> I was too! And I need a nap!
[15:44:59 EST(-0500)] * anastasiac ceiling?
[15:45:04 EST(-0500)] * anastasiac needs a nap, too
[15:45:23 EST(-0500)] * ecochran wishes he could have celebrated with Bosmon
[15:45:50 EST(-0500)] <Bosmon> ecochran: Yes, what you say about modelChanged is very true, and goes along with a number of other issues I am working on at the moment
[15:46:03 EST(-0500)] <Bosmon> I don't have the numbers here to hand, but it might be 1661 and 1662
[15:46:22 EST(-0500)] * colinclark needs a nap.
[15:47:01 EST(-0500)] <colinclark> So, to step back a bit, there are a couple of problems we are batting around.
[15:47:17 EST(-0500)] <colinclark> At heart, Eli has an interesting use case.
[15:47:21 EST(-0500)] <Bosmon> ecochran: I imagine "where you might put your data" might be in a jQuery.data call, for the time being
[15:47:26 EST(-0500)] <Bosmon> What do you mean, "at heart" (tongue)
[15:47:34 EST(-0500)] <Bosmon> You mean, behind his crusty exteriour? (tongue)
[15:47:46 EST(-0500)] <colinclark> Who's crusty exterior?
[15:47:52 EST(-0500)] <ecochran> he meant me
[15:47:55 EST(-0500)] <colinclark> Oh
[15:48:09 EST(-0500)] <colinclark> I suffer from this problem that I've noticed jacobfarber also sort of shares...
[15:48:15 EST(-0500)] <ecochran> it's a pot calling the kettle thing
[15:48:23 EST(-0500)] <ecochran> (wink)
[15:48:26 EST(-0500)] <colinclark> where I prefix statements with unrelated statements.
[15:48:29 EST(-0500)] * jacobfarber is suffering from something
[15:48:39 EST(-0500)] <colinclark> Like "at heart" or "to be completely honest."
[15:48:41 EST(-0500)] <colinclark> Or whatever.
[15:48:42 EST(-0500)] <colinclark> (tongue)
[15:48:45 EST(-0500)] <Bosmon> (smile)
[15:49:04 EST(-0500)] <colinclark> So, at heart.
[15:49:09 EST(-0500)] <colinclark> I am crusty, and Eli is not.
[15:49:14 EST(-0500)] <colinclark> Or something like that.
[15:49:17 EST(-0500)] <Bosmon> We are all crusty
[15:49:30 EST(-0500)] <colinclark> So, Eli's use case is a good one...
[15:49:31 EST(-0500)] <Bosmon> Like Plum Duff
[15:49:31 EST(-0500)] * jacobfarber refuses the crusty label
[15:49:44 EST(-0500)] <colinclark> He wants to, whenever the text changes, do something,.
[15:49:51 EST(-0500)] <colinclark> And he wants to do something in the DOM.
[15:49:59 EST(-0500)] <Bosmon> I mean, "at heart", Eli's issue is really that our contract on modelChanged is just not entirely consistent
[15:50:10 EST(-0500)] <colinclark> Bosmon: Partly, yes.
[15:50:16 EST(-0500)] <Bosmon> Although, it does to some extent relate to this "backwash" problem, that so far we have shied away from
[15:50:23 EST(-0500)] <colinclark> That is true to.
[15:50:25 EST(-0500)] <colinclark> too
[15:50:26 EST(-0500)] <Bosmon> You remember I removed that code from our event framework prior to 0.5 (smile)
[15:50:34 EST(-0500)] <ecochran> not just in DOM, if it was a real app, I'd want to send data to the server too!
[15:50:37 EST(-0500)] <colinclark> Backwash is gross.
[15:50:39 EST(-0500)] <ecochran> don't forget the server!
[15:50:40 EST(-0500)] <colinclark> (tongue)
[15:50:50 EST(-0500)] <colinclark> haha
[15:50:55 EST(-0500)] <Bosmon> If we impose a completely consistent external contract on modelChanged, we run into the issue of remembering not to listen to our own events
[15:50:57 EST(-0500)] <colinclark> Usually it is Antranig who says that. (wink)
[15:51:12 EST(-0500)] <Bosmon> Which of course relies on putting back the "backwash" code
[15:51:26 EST(-0500)] <colinclark> Bosmon: Do you want to try to explain that to the others?
[15:51:28 EST(-0500)] <Bosmon> Not to say, getting it working
[15:51:34 EST(-0500)] <ecochran> I'm channeling Antranig through his inner 'mercan
[15:51:41 EST(-0500)] <Bosmon> The "undo" widget is both a generator and consumer of "modelChanged"-potential events
[15:51:50 EST(-0500)] <ecochran> yes
[15:51:57 EST(-0500)] <ecochran> that's part of what I want!
[15:51:59 EST(-0500)] <colinclark> Though it doesn't actually generate, yes.
[15:52:06 EST(-0500)] <Bosmon> It needs to be quite clear, that if it updates the model through its own efforts, it should not get in infinite regress trying to service them
[15:52:06 EST(-0500)] <Bosmon> Yes
[15:52:14 EST(-0500)] <Bosmon> currently it doesn't generate them
[15:52:21 EST(-0500)] <Bosmon> Which, whilst it is simple to implement, looks anomalous to our users
[15:52:31 EST(-0500)] <ecochran> ?
[15:53:00 EST(-0500)] <Bosmon> The simplest way to avoid getting into infinite regress trying to service a modelChanged event which you just generated, is not to generate one (tongue)
[15:53:05 EST(-0500)] <Bosmon> Opposite of showers, is no showers
[15:53:37 EST(-0500)] * ecochran thinks that he understands
[15:53:40 EST(-0500)] <Bosmon> The "event framework" which amongst other things, was largely ported "as is" from rsf.js, used to have a "backwash prevention scheme"
[15:53:46 EST(-0500)] <Bosmon> Each event could be labelled with a "source"
[15:54:03 EST(-0500)] <Bosmon> And the event firer will be intelligent enough only to "flood" events, and never "backwash" back to a source
[15:54:09 EST(-0500)] <ecochran> I wondered what source was
[15:54:19 EST(-0500)] <ecochran> makes sense
[15:54:22 EST(-0500)] <colinclark> See, backwash is gross.
[15:54:23 EST(-0500)] <colinclark> (tongue)
[15:54:25 EST(-0500)] <Bosmon> However, the code to maintain this was a bit fiddly, especially if the propagation could run over an AJAX cycle
[15:54:40 EST(-0500)] <Bosmon> So, in a rush for 0.5, not wanting to have any untestable and untried code in the framework, we just took it out
[15:55:02 EST(-0500)] <Bosmon> Perhaps I mean untested and untriable (tongue)
[15:55:08 EST(-0500)] <colinclark> (smile)
[15:56:22 EST(-0500)] <colinclark> So your point here is that we run the risk, if every part of our code does its civic duty and subscribes to the modelChanged event...
[15:56:39 EST(-0500)] <colinclark> that we are then in a situation where we'll be stuck in an infinite loop.
[15:56:45 EST(-0500)] <colinclark> Listening to our own changes.
[15:56:53 EST(-0500)] <Bosmon> Yes
[15:57:05 EST(-0500)] <colinclark> So, the event system needs a way of basically saying, "hey, this is your own doing, don't sweat it."
[15:57:05 EST(-0500)] <Bosmon> And really, unless the event framework solves this problem for us, it is very hard to solve by ourselves
[15:57:25 EST(-0500)] <colinclark> At that point, both Undo and InlineEdit can do their civic duty correctly.
[15:58:00 EST(-0500)] <colinclark> There's still the question of what arguments we supply to modelChanged.
[15:58:13 EST(-0500)] <colinclark> And presumably we'll need the new value and the component instance.
[15:58:19 EST(-0500)] <Bosmon> Well
[15:58:23 EST(-0500)] <Bosmon> Will we indeed need the latter
[15:58:24 EST(-0500)] * michelled (n=team@142.150.154.197) has left #fluid-work
[15:58:39 EST(-0500)] <Bosmon> I'm not quite sure our our yesterday discussion played out in the channel today....
[15:58:45 EST(-0500)] <colinclark> No, it didn't.
[15:58:47 EST(-0500)] <colinclark> Intentionally.
[15:58:53 EST(-0500)] <colinclark> We've still got quite a bit of thinking to do.
[15:58:54 EST(-0500)] <Bosmon> ah
[15:59:15 EST(-0500)] <Bosmon> Wasn't another thing we considered yesterday was that requirement for thinking did not preclude speaking? (tongue)
[15:59:16 EST(-0500)] <colinclark> In short, Bosmon and I were playing with the idea of adding a "roll your own event arguments" feature for the framework.
[15:59:35 EST(-0500)] <colinclark> Allowing users to ask for a particular set of arguments that they are interested when they attach their listeners.
[16:00:03 EST(-0500)] <colinclark> I need to learn how to type better.
[16:00:16 EST(-0500)] <colinclark> Bosmon: Yes, that's why I'm trying to explain.
[16:00:18 EST(-0500)] <colinclark> (tongue)
[16:00:22 EST(-0500)] <Bosmon> Yes
[16:00:29 EST(-0500)] <Bosmon> Perhaps you needed to put a "source" on that note to yourself
[16:00:34 EST(-0500)] <anastasiac> ooh, interesting
[16:00:35 EST(-0500)] * ecochran and colinclark had also spoken a bit about that, so I'm not completely confused
[16:00:37 EST(-0500)] <Bosmon> So you don't get caught in infinite regress (tongue)
[16:00:42 EST(-0500)] <colinclark> haha
[16:01:06 EST(-0500)] <colinclark> So this is a very strange concept.
[16:01:09 EST(-0500)] <Bosmon> Yes
[16:01:18 EST(-0500)] <colinclark> It's sort of an "a la carte" menu for events.
[16:01:30 EST(-0500)] <Bosmon> Obviously, the Level 1 answer is, "If our events or API can be considered 'incorrect', they should be fixed"
[16:01:35 EST(-0500)] <Bosmon> Which looks at least somewhat appropriate here
[16:01:42 EST(-0500)] <colinclark> "When you fire this event, please send me the following pieces of information: that, that.viewElement, that.editField."
[16:01:51 EST(-0500)] <colinclark> Bosmon: Yes, exactly.
[16:02:01 EST(-0500)] <Bosmon> But, ultimately, especially as a framework matures, you increasingly get into the situation where an API either should not or can not be changed, to meet all comers
[16:02:21 EST(-0500)] <colinclark> Yes, exactly.
[16:02:27 EST(-0500)] <colinclark> Eli and I were contemplating this issue the other day.
[16:02:34 EST(-0500)] <colinclark> It's hard to know exactly what people want.
[16:02:39 EST(-0500)] <Bosmon> One thing Colin and I considered yesterday, were cases were different users of the same component, would want different APIs under different situations
[16:02:59 EST(-0500)] <Bosmon> And what does this mean.... yet another required elaboration of the event framework (smile)
[16:03:00 EST(-0500)] <ecochran> hmm
[16:03:02 EST(-0500)] <colinclark> On the other hand, the risk is that we force them to understand yet another notation for asking about event arguments.
[16:03:10 EST(-0500)] <ecochran> agreed
[16:03:27 EST(-0500)] <ecochran> more power... more complexity...
[16:03:33 EST(-0500)] <ecochran> more confusion...
[16:03:35 EST(-0500)] <ecochran> ?
[16:03:39 EST(-0500)] <Bosmon> Yes
[16:03:41 EST(-0500)] <colinclark> Potentially, yes.
[16:03:43 EST(-0500)] <Bosmon> So this power is not to be used "lightly"
[16:03:48 EST(-0500)] <Bosmon> Should we eventually decide we want it
[16:03:56 EST(-0500)] <Bosmon> Level 1 is the appropriate answer wherever possible
[16:04:08 EST(-0500)] <Bosmon> A final part of our discussion was on how to potentially "hide" this complexity from end users
[16:04:21 EST(-0500)] <Bosmon> By allowing this "special event massaging notation" to be hidden inside the default options for a subcomponent
[16:04:31 EST(-0500)] <anastasiac> "with great power comes great responsibility"
[16:04:43 EST(-0500)] <Bosmon> That way, different "repackagings" of the same component via a decorator could each have their own unique characteristics
[16:04:44 EST(-0500)] <colinclark> Meaning we'd ship reasonable, useful defaults so users could generally be oblivious to its very existence.
[16:05:00 EST(-0500)] <Bosmon> We then looked at various cases where we'd already been forced to pervert our Reorderer "API" through lack of this capability
[16:05:13 EST(-0500)] <Bosmon> There is an "afterMoveCallbackUrl" property, or some such
[16:05:22 EST(-0500)] <ecochran> responsibility to us to design and document it well enough that it is usable by mere-mortals... meaning me
[16:05:42 EST(-0500)] <Bosmon> Which, as a result of not being able to be completely factored against the particular LayoutHandler which is attached to the Reorderer, ends up imputing an "overly specific" contract against it, and the Options
[16:05:55 EST(-0500)] <Bosmon> It, as it stands, looks, "hopefully" for a property called "getModel" in the layoutHandler
[16:06:01 EST(-0500)] <Bosmon> Which some layoutHandlers have the option not to implement
[16:06:08 EST(-0500)] <colinclark> ecochran: I think it's more than documentation... it has to not suck, too. (tongue)
[16:06:18 EST(-0500)] <Bosmon> If it doesn't find it, it then looks for a particularly named thing in the options, acquireModel, a function
[16:06:23 EST(-0500)] <Bosmon> Now this is all craziness
[16:06:41 EST(-0500)] <ecochran> ye
[16:06:41 EST(-0500)] <Bosmon> Since we have now had to "spend" two lots of user headspace and API space, just for one small case
[16:06:41 EST(-0500)] <colinclark> Many of us aren't as familiar with the Reorderer, but the InlineEditor highlights this issue, too...
[16:06:51 EST(-0500)] <Bosmon> Which, I have to notice has brought us full circle to Eli's original point
[16:07:05 EST(-0500)] <colinclark> Undo will eventually be the sort of "meta component" that can be used in coordination with many other components...
[16:07:23 EST(-0500)] <Bosmon> He wants, in his case, to write callbacks against a component, which are potentially flexible about the way in which they acquire a kind of "model" which is suitable to be serialised for sending upstairs to a server
[16:07:23 EST(-0500)] <colinclark> yet it's crucial that plays an active role in the life cycle of that component...
[16:07:38 EST(-0500)] <Bosmon> So, I think we can't avoid seeing all these issues as hopelessly interconnected
[16:07:42 EST(-0500)] <colinclark> yes
[16:07:44 EST(-0500)] <Bosmon> And all potentially as aspects of the same problem (tongue)
[16:07:47 EST(-0500)] <colinclark> but we need to break them apart a bit.
[16:07:50 EST(-0500)] <Bosmon> Yes
[16:07:55 EST(-0500)] <colinclark> So...
[16:08:02 EST(-0500)] <Bosmon> Firstly, I think we really do want to just solve Eli's level 1 issue
[16:08:05 EST(-0500)] <colinclark> Yes
[16:08:11 EST(-0500)] <Bosmon> Which is that the contract for modelChanged is externally inconsistent
[16:08:22 EST(-0500)] <Bosmon> Which means, resurrected backwash support
[16:08:44 EST(-0500)] <colinclark> Can we please call is something less gross?
[16:08:48 EST(-0500)] <colinclark> (tongue)
[16:08:54 EST(-0500)] <Bosmon> Then, "going forwards", I think we really do want to refactor InlineEdit so that it is more "view-oriented"
[16:08:54 EST(-0500)] <anastasiac> yes, please
[16:08:55 EST(-0500)] <colinclark> Anti-echo?
[16:09:20 EST(-0500)] <Bosmon> That is, organised around autonomous things which specify flexible ways of relating the acquisition of a "model" to something which may or may not be in the DOM
[16:09:23 EST(-0500)] <colinclark> Bosmon: Yes, Inline Edit 2 is on the horizon. Thankfully it's a fairly minor refactoring.
[16:09:26 EST(-0500)] <Bosmon> "views"
[16:09:48 EST(-0500)] <colinclark> Yes, exactly. This connects with my patch for rich text inline editing.
[16:09:57 EST(-0500)] <colinclark> Okay, so.
[16:10:00 EST(-0500)] <Bosmon> "Backwash (geography), the water that rolls back down a beach after a wave has broken"
[16:10:04 EST(-0500)] <anastasiac> ok, so I'm trying to do some planning for this iteration, and for the release
[16:10:06 EST(-0500)] <Bosmon> What could be gross about that (tongue)
[16:10:15 EST(-0500)] <anastasiac> are we settling on a bit of a to-do list
[16:10:30 EST(-0500)] <anastasiac> that could be expressed as JIRAs with time estimates and fix-for versions?
[16:10:34 EST(-0500)] <Bosmon> http://en.wikipedia.org/wiki/Backwash_(geography)
[16:10:46 EST(-0500)] <colinclark> "The filmy, cloudy residue at the bottom of a drink that you get when you pass a drink to someone else."
[16:10:50 EST(-0500)] <Bosmon> (tongue)
[16:11:23 EST(-0500)] <Bosmon> anastasiac: Yes, all this should be planned out
[16:11:23 EST(-0500)] <ecochran> can I get practical for one sec... one non-InlineEdit 2 second?
[16:11:32 EST(-0500)] <colinclark> hey
[16:11:37 EST(-0500)] <ecochran> sorry!
[16:11:52 EST(-0500)] <colinclark> (tongue)
[16:12:05 EST(-0500)] <colinclark> There are a couple of easy-to-address immediate solutions.
[16:12:20 EST(-0500)] <colinclark> 1. Let's adjust the arguments for modelChanged.
[16:12:20 EST(-0500)] <ecochran> I have some specific changes that I've made to InlineEdit which are very InlineEdit 1 that I'd like to check in for user testings
[16:12:25 EST(-0500)] <ecochran> ye
[16:12:27 EST(-0500)] <ecochran> yes
[16:12:44 EST(-0500)] <colinclark> 2. Let's make modelChanged() fire consistently by adding "backwash" support.
[16:12:52 EST(-0500)] <colinclark> 3. Let's deprecate finishedEditing.
[16:13:09 EST(-0500)] <colinclark> 4. Let's decide on the correct argument to pass to afterFinished.
[16:13:17 EST(-0500)] <Bosmon> ok
[16:13:18 EST(-0500)] <anastasiac> ok, so that's 4 JIRAs
[16:13:22 EST(-0500)] <Bosmon> I need to dash off now
[16:13:28 EST(-0500)] <colinclark> Bosmon: Sure, no problem.
[16:13:28 EST(-0500)] <Bosmon> But this has been very productive (tongue)
[16:13:29 EST(-0500)] <anastasiac> we already have FLUID-1769 for #3
[16:13:35 EST(-0500)] <ecochran> thanks!
[16:13:39 EST(-0500)] <anastasiac> Bosmon, thanks!
[16:13:46 EST(-0500)] <colinclark> anastasiac: Cool, thanks.
[16:13:53 EST(-0500)] <colinclark> So Eli, let's go with modelChanged(value, that);
[16:13:54 EST(-0500)] <Bosmon> I have my BAMER champagne....
[16:13:59 EST(-0500)] <ecochran> so afterFinished would still be the view change
[16:14:00 EST(-0500)] <colinclark> (smile)
[16:14:01 EST(-0500)] <ecochran> ?
[16:14:05 EST(-0500)] <colinclark> ecochran: Yes.
[16:14:13 EST(-0500)] <anastasiac> what is the priority for these fixes - 0.6 blocker?
[16:14:19 EST(-0500)] <colinclark> anastasiac: Yes.
[16:14:22 EST(-0500)] <Bosmon> I would think
[16:14:26 EST(-0500)] <ecochran> then I don't really care about the modelChanged
[16:14:31 EST(-0500)] <anastasiac> and colinclark, are any of these covered by your patch?
[16:14:34 EST(-0500)] <anastasiac> which already has a jira?
[16:14:36 EST(-0500)] <Bosmon> InlineEdit could be declared "unusable" in its current form
[16:14:42 EST(-0500)] <colinclark> anastasiac: Nope, unfortunately not.
[16:14:48 EST(-0500)] <colinclark> As for afterFinished...
[16:15:30 EST(-0500)] <colinclark> Have you changed it in your local repository?
[16:15:40 EST(-0500)] <colinclark> Or did you hack away at modelChanged?
[16:15:50 EST(-0500)] <ecochran> I did both
[16:15:53 EST(-0500)] <colinclark> Ok.
[16:15:58 EST(-0500)] <colinclark> So one question we should answer:
[16:16:04 EST(-0500)] <ecochran> started with afterFinished and then moved it all to modelChanged
[16:16:08 EST(-0500)] <ecochran> afterFinish
[16:16:13 EST(-0500)] <colinclark> Is the old value important for people in afterFinished?
[16:16:18 EST(-0500)] <ecochran> also fixed the bug in modelChanged
[16:16:25 EST(-0500)] <ecochran> where it fired on init
[16:16:27 EST(-0500)] <colinclark> At very least, we know we want newValue, editField, and viewElement.
[16:16:41 EST(-0500)] <colinclark> Ah, yes.
[16:16:52 EST(-0500)] <colinclark> anastasiac: One more bug: don't fire modelChanged on initialization.
[16:16:54 EST(-0500)] <ecochran> you have to use the oldVal in afterFinish since it fires whether the vals have changed
[16:17:01 EST(-0500)] <ecochran> or not
[16:17:14 EST(-0500)] <ecochran> that's why modelChanged was nicer
[16:17:15 EST(-0500)] <colinclark> So what was the signature we had talked about for afterFinished?
[16:17:21 EST(-0500)] <colinclark> I forget.
[16:17:36 EST(-0500)] <ecochran> that.events.afterFinish.fire(that.editField[0], afterValue, beforeValue, that.viewEl[0]);
[16:18:10 EST(-0500)] <ecochran> I hacked modelChanged to:
[16:18:11 EST(-0500)] <ecochran> that.events.modelChanged.fire(newValue, that.editField[0], that.viewEl[0]);
[16:18:12 EST(-0500)] <colinclark> And we had intuited this order by trying to prioritize the importance of each argument, right?
[16:18:25 EST(-0500)] <ecochran> and that 3 and 4 could be optional
[16:18:32 EST(-0500)] <colinclark> or, really
[16:18:34 EST(-0500)] <ecochran> but 1 and 2 were required
[16:18:37 EST(-0500)] <colinclark> 2, 3, and 4
[16:18:39 EST(-0500)] <colinclark> (tongue)
[16:18:48 EST(-0500)] <ecochran> probably
[16:18:51 EST(-0500)] <Bosmon> Yes
[16:19:01 EST(-0500)] <Bosmon> Methinks the virtue of pipe-cutting is proving itself under our eyes (tongue)
[16:19:12 EST(-0500)] <colinclark> Bosmon: indeed
[16:19:18 EST(-0500)] <colinclark> pipe cutting is also on the verge of lunacy
[16:19:19 EST(-0500)] <colinclark> (tongue)
[16:19:35 EST(-0500)] <colinclark> you should have seen the glee in anastasiac's eyes when the possibilities dawned on her.
[16:19:38 EST(-0500)] <Bosmon> "All progress depends on the unreasonable man"
[16:20:03 EST(-0500)] <colinclark> But she also mentioned the word "cool."
[16:20:03 EST(-0500)] <ecochran> I see that on Bosmon's grave stone
[16:20:03 EST(-0500)] <colinclark> (tongue)
[16:20:05 EST(-0500)] <Bosmon> "The reasonable man adapts himself to his event API ...."
[16:20:24 EST(-0500)] <Bosmon> "Whereas the unreasonable man forces the event API to conform to himself"
[16:20:39 EST(-0500)] <colinclark> "The reasonable man or woman retires to their yacht instead."
[16:20:59 EST(-0500)] <ecochran> I'd still like to be able to get some kind of reasonable event when Undo does its magic
[16:21:10 EST(-0500)] <ecochran> but that could wait
[16:21:14 EST(-0500)] <colinclark> ype
[16:21:15 EST(-0500)] <colinclark> one sec
[16:21:19 EST(-0500)] <ecochran> user testing can live without
[16:21:30 EST(-0500)] <Bosmon> I came back because I realised I needed to burn a CD of Easley to take with me this evening (smile)
[16:22:07 EST(-0500)] <ecochran> Easley?
[16:22:26 EST(-0500)] <Bosmon> http://en.wikipedia.org/wiki/Easley_Blackwood_Jr.
[16:22:40 EST(-0500)] <Bosmon> Colin caused me to "discover" him on our road trip down to Michigan (tongue)
[16:22:42 EST(-0500)] <ecochran> not Mike Easley, the Governer of North Carolina
[16:22:45 EST(-0500)] <colinclark> http://en.wikipedia.org/wiki/Easley_Blackwood_Jr.
[16:22:48 EST(-0500)] <colinclark> sorry
[16:23:22 EST(-0500)] <ecochran> nothing there
[16:23:36 EST(-0500)] <ecochran> http://en.wikipedia.org/wiki/Easley_Blackwood,_Jr.
[16:23:52 EST(-0500)] <ecochran> grumph, IRC swallows the underscore
[16:24:27 EST(-0500)] <Bosmon> Somehow you even have a comma in yours....
[16:24:29 EST(-0500)] <ecochran> I knew that this conversation wasn't just going to take 15 minutes
[16:24:33 EST(-0500)] <colinclark> that is very odd
[16:24:44 EST(-0500)] <Bosmon> "Blackwood is also known for his book, The Structure of Recognizable Diatonic Tunings, published 1986"
[16:24:56 EST(-0500)] <Bosmon> The unrecognizable ones, he clearly left to others of his contemporaries
[16:24:59 EST(-0500)] <colinclark> Bosmon: Well yours has a period. (tongue)
[16:25:22 EST(-0500)] <colinclark> Bosmon: There is a great book by John H. Chalmers...
[16:25:32 EST(-0500)] <ecochran> I'm listening to Twelve Microtonal Etudes for Electronic Music Media, op. 28
[16:25:43 EST(-0500)] <ecochran> not sure that I like it
[16:25:44 EST(-0500)] <colinclark> where he catalogues a vast array of tetrachordal tunings from ancient and modern times.
[16:25:57 EST(-0500)] <colinclark> Anyway, so.
[16:26:11 EST(-0500)] <anastasiac> yes, anyway...
[16:26:16 EST(-0500)] <colinclark> Is it reasonable to pass the old and new values to afterFinished?
[16:26:31 EST(-0500)] <colinclark> I mean, it is an event saying "hey, something important is happening with the component."
[16:26:37 EST(-0500)] <ecochran> it is fine by me
[16:26:41 EST(-0500)] <Bosmon> It seems a little reasonable, yes
[16:26:43 EST(-0500)] <colinclark> Works for me.
[16:26:52 EST(-0500)] <colinclark> So we have a decision for round one.
[16:27:00 EST(-0500)] <colinclark> modelChanged(value, that)
[16:27:17 EST(-0500)] <colinclark> afterFinished(newValue, editField, oldValue, viewElement)
[16:27:19 EST(-0500)] <colinclark> Yes?
[16:27:24 EST(-0500)] <Bosmon> They are certainly "esoteric values" in terms our our earlier discussion
[16:27:33 EST(-0500)] <Bosmon> Especially the "old value"
[16:28:05 EST(-0500)] <colinclark> anastasiac and I were just debating that, yes.
[16:28:12 EST(-0500)] <colinclark> I think, though, that it's perhaps appropriate.
[16:28:17 EST(-0500)] <ecochran> yes, although I will probably only use afterFinish unless Undo changes
[16:28:34 EST(-0500)] <colinclark> Ok, yes.
[16:28:38 EST(-0500)] <colinclark> So the issue of Undo.
[16:29:04 EST(-0500)] <ecochran> as I said, for my uses, that could wait
[16:29:19 EST(-0500)] <anastasiac> ok, so what about the order of arguments?
[16:29:25 EST(-0500)] <ecochran> my uses = user test
[16:29:30 EST(-0500)] <colinclark> I guess ultimately you'd like to bind to Undo's unique versions of onBeginEdit and afterFInish, right?
[16:30:02 EST(-0500)] <ecochran> only afterfinished
[16:30:20 EST(-0500)] <ecochran> I just need to know that the value has changed on a specific element
[16:32:36 EST(-0500)] <anastasiac> colin is distracted by a conversation with Jutta
[16:34:19 EST(-0500)] <colinclark> So I'm confused now.
[16:34:33 EST(-0500)] <colinclark> If Undo changes, what would you use instead?
[16:34:46 EST(-0500)] * colinclark is sorry for being slightly forgetful... super crazy day.
[16:35:02 EST(-0500)] <anastasiac> Jutta can have that effect (smile)
[16:35:07 EST(-0500)] <ecochran> colinclark said you'd like to bind to Undo's unique versions of onBeginEdit and afterFInish, right?
[16:35:28 EST(-0500)] <ecochran> I just care about Undo's afterFinish (for Undo)
[16:35:46 EST(-0500)] <ecochran> for Edit, I care about InlineEdit's afterFinish'
[16:35:53 EST(-0500)] <ecochran> am I making sense?
[16:36:04 EST(-0500)] <ecochran> I keep wanting to type afterFish
[16:36:14 EST(-0500)] <colinclark> afterFish
[16:36:32 EST(-0500)] <colinclark> let's just name it that
[16:36:33 EST(-0500)] <anastasiac> (for the record, JIRAs have been filed: 1769 through 1774. Feel free to sign up and estimate)
[16:36:39 EST(-0500)] <colinclark> and pass every argument we can imagine to it
[16:36:51 EST(-0500)] <colinclark> it will be the only event in the whole framework
[16:36:53 EST(-0500)] <anastasiac> but what would Fish think of that?
[16:37:06 EST(-0500)] <colinclark> i'm sure she'd be flattered, really
[16:37:07 EST(-0500)] <ecochran> honored, I hope
[16:39:52 EST(-0500)] <ecochran> I can work with what we've spec'd so far, and I've written most of it already in my local build
[16:40:02 EST(-0500)] <colinclark> k
[16:40:05 EST(-0500)] <colinclark> whip up a patch
[16:40:19 EST(-0500)] <ecochran> I have to run... but I'll come back and check the logs to see if there are any new decisions
[16:40:26 EST(-0500)] <ecochran> thx!
[16:40:29 EST(-0500)] <ecochran> bye
[16:40:30 EST(-0500)] <colinclark> This is the kind of thing I'd suggest you create a patch for, attach it the relevant JIRA, and get some feedback before committing.
[16:40:40 EST(-0500)] <ecochran> cool
[16:40:44 EST(-0500)] <colinclark> see you
[16:40:59 EST(-0500)] <ecochran> I'll be back in < 1 hour
[16:41:02 EST(-0500)] <ecochran> bye
[17:04:14 EST(-0500)] * theclown (n=theclown@guiseppi.atrc.utoronto.ca) has left #fluid-work
[19:22:17 EST(-0500)] * ptmahent (n=ptmahent@Bas21-toronto12-1242560193.dsl.bell.ca) has joined #fluid-work
[21:59:47 EST(-0500)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work
[22:50:08 EST(-0500)] * jacobfarber1 (n=Jacob@142.150.154.106) has joined #fluid-work
[23:22:56 EST(-0500)] * colinclark (n=colin@bas1-toronto09-1279721821.dsl.bell.ca) has joined #fluid-work