fluid-work IRC Logs-2008-11-03

[00:41:39 EST(-0500)] * ptmahent (n=ptmahent@74.12.29.122) has joined #fluid-work
[08:22:03 EST(-0500)] * Justin_o (n=Justin@142.150.154.101) has joined #fluid-work
[08:25:44 EST(-0500)] * athena7 (n=athena7@adsl-99-130-147-23.dsl.wlfrct.sbcglobal.net) has joined #fluid-work
[09:07:36 EST(-0500)] * jacobfarber (n=Jacob@142.150.154.106) has joined #fluid-work
[09:10:06 EST(-0500)] * lessthanzero (n=FatalRem@CPE001ff342457c-CM001ac352aefc.cpe.net.cable.rogers.com) has joined #fluid-work
[09:10:45 EST(-0500)] <lessthanzero> what types of licenses are compatible with fluid's?
[09:11:01 EST(-0500)] <lessthanzero> I've been looking at www.codeigniter.com which says it can be used with any BSD-Style license.
[09:11:16 EST(-0500)] <lessthanzero> its open source, and a wicked little lightweight MVC.
[09:35:22 EST(-0500)] * colinclark (n=colin@bas1-toronto09-1279721821.dsl.bell.ca) has joined #fluid-work
[09:56:06 EST(-0500)] * anastasiac (n=team@142.150.154.160) has joined #fluid-work
[09:57:51 EST(-0500)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined #fluid-work
[10:06:27 EST(-0500)] * theclown (n=theclown@guiseppi.atrc.utoronto.ca) has joined #fluid-work
[10:11:22 EST(-0500)] * anastasiac (n=team@142.150.154.160) has joined #fluid-work
[10:11:22 EST(-0500)] * jacobfarber (n=Jacob@142.150.154.106) has joined #fluid-work
[10:11:22 EST(-0500)] * Justin_o (n=Justin@142.150.154.101) has joined #fluid-work
[10:11:22 EST(-0500)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work
[10:12:23 EST(-0500)] * colinclark (n=colin@bas1-toronto09-1279721821.dsl.bell.ca) has joined #fluid-work
[10:14:55 EST(-0500)] <Justin_o> colinclark: lessthanzero had a question about licenses that are compatible with fluid
[10:15:11 EST(-0500)] <lessthanzero> Justin_o: thanks! yeah, colin. I had a question.
[10:15:22 EST(-0500)] <lessthanzero> colinclark: codeigniter.com
[10:15:23 EST(-0500)] <colinclark> lessthanzero: Haven't seen you around in awhile. How are things going?
[10:15:43 EST(-0500)] <lessthanzero> colinclark: not bad, I've had some keychain issues (mac osx) so I've been hating irc.
[10:15:43 EST(-0500)] <Justin_o> lessthanzero: np
[10:15:58 EST(-0500)] <lessthanzero> (having your passwords not save is very annoying)
[10:16:00 EST(-0500)] <lessthanzero> anyway
[10:16:03 EST(-0500)] <colinclark> lessthanzero: That sucks.
[10:16:07 EST(-0500)] <colinclark> Ok, shoot.
[10:16:07 EST(-0500)] <lessthanzero> www.codeigniter.com
[10:16:13 EST(-0500)] <lessthanzero> you farmilar?
[10:16:25 EST(-0500)] <lessthanzero> its a cakePHP type framework, except very lightweight.
[10:16:40 EST(-0500)] <lessthanzero> says it can be used with any BSD-Style compatible licenses.
[10:17:03 EST(-0500)] * lessthanzero is hates rewriting code that exists in a open-source fashion.
[10:17:13 EST(-0500)] <lessthanzero> other guys are always going to do it better then me.
[10:18:38 EST(-0500)] <colinclark> BSD is just fine.
[10:18:38 EST(-0500)] <colinclark> Fluid is dual licensed, ECL 2 and BSD.
[10:18:38 EST(-0500)] <colinclark> The reason we chose BSD is that it is hugely compatible.
[10:19:03 EST(-0500)] <lessthanzero> seriously??
[10:19:15 EST(-0500)] <lessthanzero> yeah, the license says Any "BSD-Style" License.
[10:19:33 EST(-0500)] <lessthanzero> WOW.
[10:19:40 EST(-0500)] <lessthanzero> I've been working with vulab, and...
[10:19:50 EST(-0500)] <lessthanzero> its just going to be too much work to swap out the old stuff.
[10:20:45 EST(-0500)] <colinclark> I really wish people wouldn't invent their own licenses like this, though.
[10:20:45 EST(-0500)] <colinclark> I'll have to take a bit of time to look at it more closely.
[10:20:50 EST(-0500)] <colinclark> But you should be just fine.
[10:20:56 EST(-0500)] <lessthanzero> http://www.hopstudios.com/blog/is_codeigniter_actually_open_source/
[10:20:58 EST(-0500)] <lessthanzero> great article.
[10:21:11 EST(-0500)] * michelled (n=team@142.150.154.197) has joined #fluid-work
[10:22:25 EST(-0500)] <lessthanzero> outlines alot.
[10:22:48 EST(-0500)] <lessthanzero> I'm going to be working with that pretty soon.
[10:23:32 EST(-0500)] <lessthanzero> will make VULab a truly extensible archetexture, and the plugin/library/helper style of MVC that CI uses, would be VERY easy to document where VULab starts and CI ends.
[10:24:25 EST(-0500)] <colinclark> lessthanzero: It looks pretty good, from a cursory glance.
[10:24:31 EST(-0500)] <lessthanzero> yeah.
[10:24:34 EST(-0500)] <colinclark> A bit of structure is really nice to code within.
[10:24:47 EST(-0500)] <lessthanzero> YEAH, and I find myself just building it.
[10:24:53 EST(-0500)] <colinclark> Interestingly, their description of Code Igniter reminds me a lot of what we've been saying about Fluid Infusion...
[10:25:07 EST(-0500)] <colinclark> A lightweight framework, with a bit of MVC to help make your app easier to write.
[10:25:18 EST(-0500)] <lessthanzero>
[10:25:21 EST(-0500)] <lessthanzero> i LOVE it.
[10:26:05 EST(-0500)] <lessthanzero> I've used cakePHP before.
[10:26:12 EST(-0500)] <lessthanzero> but documentation is horrible, and its a little bulky.
[10:26:26 EST(-0500)] <colinclark> What do you think of Cake?
[10:26:33 EST(-0500)] <lessthanzero> I dunno.
[10:26:36 EST(-0500)] <lessthanzero> too bloated.
[10:26:41 EST(-0500)] <lessthanzero> and I actually don't like the automagic stuff.
[10:29:16 EST(-0500)] <colinclark> Automagic is only good if it scales... if it retains its magic even when you want to do something a bit more complex.
[10:29:27 EST(-0500)] <lessthanzero> yeah, well..
[10:29:39 EST(-0500)] <lessthanzero> I find cakePHP (to me) is more of a..
[10:29:43 EST(-0500)] <lessthanzero> make it and then cache it.
[10:29:56 EST(-0500)] <lessthanzero> speed = cache, not runtime.
[10:30:16 EST(-0500)] <lessthanzero> which is, I guess, where alot of php platforms are going.
[10:34:51 EST(-0500)] * colinclark (n=colin@bas1-toronto09-1279721821.dsl.bell.ca) has joined #fluid-work
[10:34:51 EST(-0500)] * anastasiac (n=team@142.150.154.160) has joined #fluid-work
[10:34:51 EST(-0500)] * jacobfarber (n=Jacob@142.150.154.106) has joined #fluid-work
[10:34:51 EST(-0500)] * Justin_o (n=Justin@142.150.154.101) has joined #fluid-work
[11:49:30 EST(-0500)] * ecochran (n=ecochran@dhcp-169-229-212-33.LIPS.Berkeley.EDU) has joined #fluid-work
[12:13:48 EST(-0500)] * apetro (n=apetro@wsip-98-174-242-39.ph.ph.cox.net) has joined #fluid-work
[12:18:15 EST(-0500)] * Bosmon (n=Antranig@ginger.caret.cam.ac.uk) has joined #fluid-work
[13:19:02 EST(-0500)] * lessthanzero (n=lessthan@CPE001ff342457c-CM001ac352aefc.cpe.net.cable.rogers.com) has joined #fluid-work
[13:23:30 EST(-0500)] <ecochran> michelled: gotta minute to chat about inline edit?
[13:24:53 EST(-0500)] <anastasiac> ecochran, michelled is at a lunch meeting with davidb talking jquery
[13:27:37 EST(-0500)] <anastasiac> lessthanzero, the vulab demo email did reach the list
[13:27:37 EST(-0500)] <lessthanzero> anastasiac: sweet! thanks.
[13:50:26 EST(-0500)] <michelled> ecochran: I'm back now
[13:50:39 EST(-0500)] <ecochran> michelled: great
[13:51:02 EST(-0500)] <ecochran> michelled: 2 minutes?, I have to finish what I'm in the middle of
[13:51:07 EST(-0500)] <michelled> sure
[13:53:30 EST(-0500)] <ecochran> michelled: I'm ready... you?
[14:06:14 EST(-0500)] * athena7 (n=athena7@adsl-99-130-147-23.dsl.wlfrct.sbcglobal.net) has joined #fluid-work
[15:00:10 EST(-0500)] <michelled> Bosmon, Justin_o is looking at 1321, he thinks there are related bugs that are still open. He's going to take a look
[15:00:59 EST(-0500)] <Bosmon> I have assembled a collection of new targets
[15:01:15 EST(-0500)] <Bosmon> In particular, FLUID-1661, FLUID-1662
[15:02:13 EST(-0500)] <Bosmon> Then there are a large number of bugs related to "typing special characters"
[15:02:23 EST(-0500)] <Bosmon> Which are all either easily resolvable, or impossible
[15:02:54 EST(-0500)] * lessthanzero (n=lessthan@CPE001ff342457c-CM001ac352aefc.cpe.net.cable.rogers.com) has joined #fluid-work
[15:03:32 EST(-0500)] <Justin_o> Bosmon: FLUID-1661, FLUID-1662 were the ones I was going to mention to you
[15:04:06 EST(-0500)] <Justin_o> There are a few other issues with undo/redo that I may not necessarily be caused by the undo/redo component
[15:04:27 EST(-0500)] <Justin_o> FLUID-1607, FLUID-1600
[15:04:51 EST(-0500)] <Justin_o> also the one that ecochran wrote, FLUID-1764
[15:05:21 EST(-0500)] <Bosmon> FLUID-1600 is ridiculous
[15:05:24 EST(-0500)] <Bosmon> Sorry
[15:05:28 EST(-0500)] <Bosmon> FLUID-1607
[15:05:41 EST(-0500)] <Bosmon> FLUID-1600 is one I just commented
[15:05:51 EST(-0500)] <Bosmon> It will require a very entrenched effort to resolve
[15:07:00 EST(-0500)] <Justin_o> just read your comment
[15:07:15 EST(-0500)] <Justin_o> sounds difficult
[15:07:25 EST(-0500)] <Bosmon> It is another "concrete eggcup" solution
[15:07:47 EST(-0500)] <Bosmon> But faced with awful and intractable malignancies in browser tab order support, it starts to become hard to think of other options
[15:09:13 EST(-0500)] <Justin_o> I wonder if it is worth the trouble... maybe this could be investigated in the user testing to see if people really navigate in this fashion
[15:09:38 EST(-0500)] <Bosmon> Using tab?
[15:09:53 EST(-0500)] <Bosmon> I would consider it at the bedrock of accessibility....
[15:10:03 EST(-0500)] <Justin_o> no... sorry... using tab to close the editable field
[15:10:10 EST(-0500)] <Justin_o> they may just hit enter and then it won't matter
[15:11:10 EST(-0500)] <Bosmon> If we were to resolve FLUID-1764, then our fix to FLUID-1594 becomes moot
[15:11:14 EST(-0500)] <Bosmon> Probably no bad thing
[15:11:54 EST(-0500)] <Justin_o> true... i seem to agree with that...
[15:28:18 EST(-0500)] <Bosmon> Hi ecochran, are you living?
[15:28:34 EST(-0500)] <ecochran> Bosmon: I am living... and you?
[15:28:45 EST(-0500)] <ecochran> I'm not breathing tho'
[15:28:45 EST(-0500)] <Bosmon> Yes, somewhat
[15:28:48 EST(-0500)] <Bosmon> Glarg!
[15:28:49 EST(-0500)] <ecochran> not until after the election
[15:28:52 EST(-0500)] <Bosmon> Hah
[15:28:57 EST(-0500)] <Bosmon> 'BAMER is going from height to height
[15:29:11 EST(-0500)] <Bosmon> He just broke 4 lifetime records in an hour this morning...
[15:29:25 EST(-0500)] <ecochran> ?
[15:29:33 EST(-0500)] <Bosmon> I have bought some 'BAMER shares
[15:29:38 EST(-0500)] <ecochran> nice
[15:29:41 EST(-0500)] <Bosmon> At one point today he hit 92.7%
[15:29:41 EST(-0500)] <ecochran> thank you
[15:29:59 EST(-0500)] <ecochran> the entire country thanks you... or I like to think that the entire country thanks you
[15:30:09 EST(-0500)] <ecochran> at least the rest of the world thanks you
[15:30:21 EST(-0500)] <ecochran> but anyway... how may I be of service to you this morning?
[15:30:29 EST(-0500)] <Bosmon> Well, as I reckon it, around 56% of the country thanks me
[15:30:55 EST(-0500)] <Bosmon> Could you elaborate a little more on FLUID-1764?
[15:31:00 EST(-0500)] <Bosmon> I can fix the underlying issue quite easily
[15:31:16 EST(-0500)] <Bosmon> But perhaps you could say what more you want to see from the event framework itself
[15:31:45 EST(-0500)] <ecochran> ah...
[15:32:53 EST(-0500)] <ecochran> it's tricky
[15:32:55 EST(-0500)] <Bosmon> Sorry, 51.5% of the country
[15:34:58 EST(-0500)] <ecochran> but I think that the right solution is that components that are decorators, or that will be used as decorators, need to be able to have a way for their options (specifically their listener options) to be exposed threw the component that initializes them.
[15:35:03 EST(-0500)] <ecochran> does that make any sense at all
[15:35:10 EST(-0500)] <Bosmon> Hmm
[15:35:11 EST(-0500)] <ecochran> Colin could explain it much better
[15:35:42 EST(-0500)] <Bosmon> Well, as it stands, the undo decorator itself doesn't actually seem to hold responsibility for any events....
[15:35:43 EST(-0500)] <ecochran> so in InlineEdit, I want to be able to say to Undo, you need to handle these events, in this way
[15:35:55 EST(-0500)] <Bosmon> I mean, it listens to them
[15:35:59 EST(-0500)] <Bosmon> But it doesn't originate any
[15:36:24 EST(-0500)] <Bosmon> Ah, wait, I guess it does have a few internally
[15:36:28 EST(-0500)] <Bosmon> But they are just "direct"
[15:36:34 EST(-0500)] <Bosmon> I mean, they are "real events", not "Fluid model events"
[15:36:52 EST(-0500)] <ecochran> actually I misspoke ...
[15:37:00 EST(-0500)] <Bosmon> We could "donate" it events
[15:37:19 EST(-0500)] <ecochran> because what I really need is a way for Undo to be aware of Inline Edit events and do something accordingly
[15:37:21 EST(-0500)] <Bosmon> That is, the "undoControl" and "redoControl" click bindings could be decoupled, and become "preventable" Fluid model events
[15:37:33 EST(-0500)] <Bosmon> Well, but it is
[15:37:47 EST(-0500)] <Bosmon> that.returnedOptions = {
[15:37:48 EST(-0500)] <Bosmon> listeners: listeners
[15:37:48 EST(-0500)] <Bosmon> };
[15:37:56 EST(-0500)] <Bosmon> This bit here at the base of Undo is its "returned listeners"
[15:38:07 EST(-0500)] <Bosmon> These become its "request for subscription" to base Inline Edit events
[15:39:13 EST(-0500)] <ecochran> so while instantiating an Undo, I could tell it to listen to one of my events, and do something custom when it hears the event?
[15:39:29 EST(-0500)] <Bosmon> Well...
[15:39:46 EST(-0500)] <Bosmon> The point is, "while instantiating an Undo", you are also at the same time supplying options to an Inline edit
[15:39:58 EST(-0500)] <ecochran> yes
[15:40:01 EST(-0500)] <Bosmon> That is, the way you "instantiate an undo" is as an options block passed into the base Inline Edit
[15:40:11 EST(-0500)] <ecochran> yes
[15:40:15 EST(-0500)] <Bosmon> So any event subscriptions that you want, would better be done out there, at the base level?
[15:40:29 EST(-0500)] <Bosmon> I mean, are there any particular events you want to subscribe to, that we don't have yet?
[15:40:36 EST(-0500)] <Bosmon> It sounds like that is what you are asking
[15:41:13 EST(-0500)] <ecochran> well, let's go back to the usecase...
[15:41:42 EST(-0500)] <ecochran> the usecase is that I want the Undo and Redo icons to be hidden while editing
[15:41:49 EST(-0500)] <Bosmon> yes
[15:42:10 EST(-0500)] <Bosmon> It is rather tricky, to get this done, "at initialisation time"
[15:42:18 EST(-0500)] <Bosmon> Since these icons may well not even exist yet
[15:42:19 EST(-0500)] <ecochran> so the suggested way to do that would be that I could tell Undo, watch for the onBeginEdit and on afterFinish events
[15:43:06 EST(-0500)] <ecochran> stray comma in there
[15:43:16 EST(-0500)] <Bosmon> I actually like stray commas
[15:43:27 EST(-0500)] <Bosmon> These things are grievously underused
[15:43:36 EST(-0500)] <ecochran> commas rule!
[15:43:55 EST(-0500)] <Bosmon> Well... it's hard to think of a model where you could tell "Undo" anything
[15:44:02 EST(-0500)] <Bosmon> Since it, itself, is largely just a bunch of event handlers
[15:44:20 EST(-0500)] <Bosmon> You could quite easily come along "afterwards", and register the event handlers you want yourself
[15:44:33 EST(-0500)] <Bosmon> Well ok, I guess the DOM binder architecture helps
[15:44:40 EST(-0500)] <Bosmon> And gives you a way to talk about things that don't exist yet
[15:45:20 EST(-0500)] <Bosmon> Uncharacteristically, the undo decorator has its own DOM binder, which is not shared with that of the base InlineEdit control
[15:45:27 EST(-0500)] <ecochran> I was going to do this by just having my listeners in the InlineEdit but Colin convinced me that the InlineEdit should have to know about the internal markup of the Undo
[15:45:38 EST(-0500)] <Bosmon> Well, that is correct
[15:45:44 EST(-0500)] <Bosmon> But the real hazard here is the initialisation order
[15:46:04 EST(-0500)] <Bosmon> There is a kind of "private contract" between the InlineEdit and the Undo decorators that it is quite hard to "get in the way of"
[15:46:54 EST(-0500)] <Bosmon> Whatever event handler you write, has to become registered after the Undo decorator has been fully constructed
[15:47:04 EST(-0500)] <Bosmon> Otherwise it cannot get access to its DOM binder, container, and other things
[15:48:04 EST(-0500)] <Bosmon> So, I can't off the top of my head think of a very clean way of expressing this declaratively
[15:48:27 EST(-0500)] <Bosmon> You could right now, come along after this entire tree of stuff is constructed, and just manually add in an event handler
[15:48:58 EST(-0500)] <Bosmon> That is, as the user, attach an event handler to the base inlineEdit, that goes and frobs with any undo decorator it can find hanging off it
[15:49:59 EST(-0500)] <Bosmon> OK
[15:50:12 EST(-0500)] <Bosmon> Well, I guess that itself suggests the way how to write this thing in the options...
[15:51:19 EST(-0500)] <ecochran> I'm still here... just trying to grok it all
[16:03:18 EST(-0500)] <michelled> Bosmon, can you give an example of what the options would look like? would there be a listener passed in to the inline edit creator that would get attached to undo after undo was completely constrcuted?
[16:04:33 EST(-0500)] * colinclark (n=colin@bas1-toronto09-1279721821.dsl.bell.ca) has joined #fluid-work
[16:05:04 EST(-0500)] * Justin_o (n=Justin@142.150.154.101) has left #fluid-work
[16:05:32 EST(-0500)] * apetro_ (n=apetro@12.164.139.7) has joined #fluid-work
[16:07:24 EST(-0500)] <Bosmon> Well.... I think, in practice, we can't achieve this ordering
[16:07:34 EST(-0500)] <Bosmon> The only way I can think of, is to write a kind of "search" into the event handler
[16:07:43 EST(-0500)] <Bosmon> That is, if you want to register it as part of the initial options
[16:08:00 EST(-0500)] <Bosmon> You can go through the decorator list to "find" the undo decorator, and then do the relevant stuff with it
[16:08:13 EST(-0500)] <Bosmon> It's not ideal, but its the only way I can think of making this kind of thing declarative
[16:13:49 EST(-0500)] <colinclark> Bosmon: I have been thinking about this whole InlineEdit/Undo issue, but need some time to sort out my thoughts here.
[16:14:07 EST(-0500)] <colinclark> Undo feels slightly "underhanded" in the sort of contract it defines.
[16:15:11 EST(-0500)] <colinclark> It's almost as if there needs to be a better definition of the life cycle of undo, and then the ability wire these listeners up to different events, depending on the component.
[16:15:30 EST(-0500)] <colinclark> But I'm just back from sawing innumerable lengths of ABS pipe, so let me get my head back into the code.
[16:16:56 EST(-0500)] <Bosmon> Well
[16:17:01 EST(-0500)] <Bosmon> I'm not sure its "underhanded" as such
[16:17:11 EST(-0500)] <Bosmon> In general, subcomponents will be instantiated at a "private" lifecycle point
[16:17:29 EST(-0500)] <colinclark> No, it's not the instantiation that I think is underhanded...
[16:17:50 EST(-0500)] <colinclark> It's the fact that it relies on "afterEditFinished."
[16:19:23 EST(-0500)] <Bosmon> !
[16:19:31 EST(-0500)] <Bosmon> What could be wrong with that?
[16:20:42 EST(-0500)] <colinclark> well, undo is essentially defined a contract that says "all components must implement an afterEditFinished event."
[16:21:13 EST(-0500)] <colinclark> I'm actually thinking that the behaviour inside this listener... the "hey, I did something with my model, pay attention" code, may need to be bound to a variety of events depending on the component.
[16:22:43 EST(-0500)] <colinclark> My sense is actually that the decorated component's events should potentially show through the decorator, if that makes sense.
[16:23:05 EST(-0500)] <colinclark> Since what Eli ultimately wants is to affect the behaviour of Undo based on a couple of life cycle points within Inline Edit.
[16:24:09 EST(-0500)] <Bosmon> OK
[16:24:11 EST(-0500)] <Bosmon> I see what you mean...
[16:24:19 EST(-0500)] <colinclark> It's actually quite an interesting problem.
[16:24:20 EST(-0500)] <Bosmon> We need a kind of "event pipecutter service"
[16:24:34 EST(-0500)] <colinclark> That's a funny sort of metaphor...
[16:24:47 EST(-0500)] <colinclark> Since I seemed to provide such a pipe cutting service today at the boat.
[16:24:47 EST(-0500)] <colinclark>
[16:24:56 EST(-0500)] <colinclark> It is an unenviable job.
[16:24:58 EST(-0500)] <Bosmon> maybe it was just lodged in my subconscious
[16:25:23 EST(-0500)] <colinclark> I was thinking more along the lines of a certain kind of "see-through-ness..."
[16:25:33 EST(-0500)] <colinclark> You know, like that semi-transparent wrapping paper.
[16:26:13 EST(-0500)] <Bosmon> aha
[16:26:15 EST(-0500)] * colinclark wonders where jessm is when we need dorky analogies.
[16:26:31 EST(-0500)] <Bosmon> Well, what we sort of need is "relabelling", rather than "transparency"
[16:26:51 EST(-0500)] <Bosmon> Since clearly the "functional purpose" of the event wrt. Undo may not entirely agree with what the base component thinks it is
[16:27:00 EST(-0500)] <colinclark> Ah, yes
[16:27:12 EST(-0500)] <Bosmon> It will be a bit like what we already do with selectors
[16:27:22 EST(-0500)] <Bosmon> There will be a default bind, which is overrideable
[16:27:27 EST(-0500)] <Bosmon> But that only solves half of the issue
[16:27:58 EST(-0500)] <Bosmon> I was reading your JIRAs about "models for rich text" controls also
[16:28:05 EST(-0500)] <colinclark> ah, yes
[16:28:06 EST(-0500)] <Bosmon> Which I feel is somewhat aligned with this issue
[16:28:11 EST(-0500)] <colinclark> Hmm.
[16:28:18 EST(-0500)] <Bosmon> But I'm not quite sure I understood what it was you wanted
[16:28:23 EST(-0500)] <Bosmon> But it sounds like the same
[16:28:32 EST(-0500)] <colinclark> I get the feeling that Inline Edit needs to be View-ified, in part.
[16:28:32 EST(-0500)] <Bosmon> You wanted better abstraction in "how to find the model"
[16:28:51 EST(-0500)] <colinclark> "how to find the model" is actually only half of the issue...
[16:29:09 EST(-0500)] <colinclark> I mean, the model is ultimately still the same in most cases...
[16:29:14 EST(-0500)] <colinclark> A chunk of text.
[16:29:20 EST(-0500)] <Bosmon> Yes
[16:29:25 EST(-0500)] <colinclark> Though, in other cases, it may not just be a chunk of text.l
[16:29:25 EST(-0500)] <Bosmon> So, what is the other half, for your case
[16:29:33 EST(-0500)] <Bosmon> And then let us see whether it is related to the other half of Eli's issue
[16:30:00 EST(-0500)] <colinclark> Let me try to describe what I found...
[16:30:16 EST(-0500)] <Bosmon>
[16:30:23 EST(-0500)] <Bosmon> This sounds very archaeological
[16:30:44 EST(-0500)] <colinclark> Well, given my memory, it is kind of archaeological.
[16:31:32 EST(-0500)] <colinclark> So, working with an Inline Edit that handles rich text...
[16:31:38 EST(-0500)] <colinclark> The model, at heart, was roughly the same. Text.
[16:32:27 EST(-0500)] <colinclark> The work of "synchronizing" our model's value with its views varied, though.
[16:32:42 EST(-0500)] <Bosmon> I see
[16:32:47 EST(-0500)] <colinclark> So if we think of Inline Edit as having two Views: the "View View" and "Edit View."
[16:32:57 EST(-0500)] <colinclark> Apologies for the ridiculous terminology.
[16:32:59 EST(-0500)] <colinclark> But you get what I mean.
[16:33:21 EST(-0500)] <Bosmon> Yes
[16:33:26 EST(-0500)] <colinclark> Setting the view was different... in the plain text mode, we can just do this: viewElement.text(value)
[16:33:40 EST(-0500)] <Bosmon> So, there needs to be "greater formality" in how to extract and transfer the "model value" from view to view
[16:33:45 EST(-0500)] <colinclark> Exactly.
[16:33:54 EST(-0500)] <colinclark> I had imagined that this was actually the responsibility of the Views.
[16:33:59 EST(-0500)] <Bosmon> It's possible we could also deal with some of our "unexpected character" encoding issues these ways
[16:34:12 EST(-0500)] <colinclark> Yes, definitely.
[16:34:30 EST(-0500)] * michelled (n=team@142.150.154.197) has left #fluid-work
[16:34:33 EST(-0500)] <colinclark> I had intended simply to refactor InlineEdit to have a DisplayView and an EditView...
[16:34:42 EST(-0500)] <colinclark> The defaults of both would be the "plain text" Views.
[16:35:37 EST(-0500)] <Bosmon> Yes
[16:35:44 EST(-0500)] <colinclark> But I'm not sure this would have any impact on Eli's particular issue.
[16:35:45 EST(-0500)] <Bosmon> I see what you mean
[16:35:47 EST(-0500)] <Bosmon> No
[16:35:50 EST(-0500)] <Bosmon> I was just going to say
[16:35:53 EST(-0500)] <colinclark>
[16:35:58 EST(-0500)] <Bosmon> It seems that the "other halves" of these issues are unrelated
[16:36:54 EST(-0500)] <colinclark> So again, I had imagined that the Undo issue was, in part, a task of "passing through" events from the decoratee to the decorator.
[16:38:12 EST(-0500)] <colinclark> But you're right that Undo may have to extend or redefine the exact meaning of these events.
[16:38:18 EST(-0500)] <colinclark> Which is worrisome.
[16:39:54 EST(-0500)] <Bosmon> Well
[16:40:05 EST(-0500)] <Bosmon> Part of it is simply ascribing a "standard name" to them
[16:40:10 EST(-0500)] <colinclark> Hmm.
[16:40:13 EST(-0500)] <colinclark> Elaborate.
[16:40:20 EST(-0500)] <Bosmon> But more problematic is the issue of whether we really want to solve Eli's problem, in the terms he has stated it...
[16:40:33 EST(-0500)] <Bosmon> That is, whether we want the actual binding structure itself to be part of the configuration somehow
[16:40:38 EST(-0500)] <Bosmon> Rather than simply the "plumbing" of it
[16:41:47 EST(-0500)] <Bosmon> I mean, "afterEditFinished" I think is a pretty good name for whatever event this is
[16:42:14 EST(-0500)] <Bosmon> And we can just have a "event name map" structure configured into a subcomponent, that allows it to reexpress whatever event it thinks it does bind to
[16:42:25 EST(-0500)] <colinclark> yes
[16:42:37 EST(-0500)] <colinclark> That's, I think, roughly what I was imagining.
[16:42:47 EST(-0500)] <Bosmon> But that, by itself, wouldn't allow us to solve the issue of a person who wants to write, declaratively, a binding to an event, which gets passed a particular piece of the subcomponent structure as an argument
[16:42:59 EST(-0500)] <Bosmon> All things being equal, it really should be his job to go and find whatever it is
[16:43:23 EST(-0500)] <Bosmon> The best help we could be is actually to retrieive the particular subcomponent "that" in question
[16:43:33 EST(-0500)] <Bosmon> Perhaps by means of a syntax a bit like COMPONENT_OPTIONS
[16:43:34 EST(-0500)] <colinclark> I have been playing around with the idea of an event "autobinder" that would inevitably have to wire up events after both components have been initialized.
[16:43:44 EST(-0500)] <Bosmon> But it doesn't yet sound like an enormously general use case
[16:43:47 EST(-0500)] <colinclark> I feel like returnedOptions is still not quite it.
[16:43:50 EST(-0500)] <Bosmon> Or does it?
[16:43:54 EST(-0500)] <colinclark> Hmm
[16:44:02 EST(-0500)] <Bosmon> Well, "returnedOptions" is "infrastructure"
[16:44:06 EST(-0500)] <Bosmon> It is never intended to be user-facing
[16:44:20 EST(-0500)] <colinclark> Yet, in a sense, Undo exposes it fairly publicly.
[16:44:29 EST(-0500)] <Bosmon> I am sure, whatever we implement, will just end up feeding into whatever structure is returned in "returnedOptions"
[16:44:32 EST(-0500)] <Bosmon> In what way?
[16:46:08 EST(-0500)] <colinclark> Well, when Eli first brought his issue to me, I looked at the relationship between Undo and its decoratee, and immediately encountered this as the primary mechanism for decorators to pass options back up to their parent.
[16:46:18 EST(-0500)] <colinclark> Presumably anyone writing a decorator must confront this idiom.
[16:46:19 EST(-0500)] <Bosmon> Yes
[16:46:28 EST(-0500)] <Bosmon> Yes, an implementor would use this idiom
[16:46:30 EST(-0500)] <colinclark> And I imagine decorators are the sort of thing people might well want to write themselves.
[16:46:33 EST(-0500)] <Bosmon> But here we are talking about end-users
[16:46:41 EST(-0500)] <colinclark> Well, sort of.
[16:46:50 EST(-0500)] <colinclark> Eli is in a position where is an active "implementor user."
[16:46:55 EST(-0500)] <Bosmon> Well
[16:46:58 EST(-0500)] <Bosmon> We have to be utterly careful here
[16:47:01 EST(-0500)] <colinclark> He wants to customize the behaviour of what we ship out of the box.
[16:47:13 EST(-0500)] <Bosmon> Not to create a framework which is harder to understand and use than the problems it solves
[16:47:21 EST(-0500)] <colinclark> indeed
[16:47:24 EST(-0500)] <Bosmon> I feel we are dangerously close to crossing a line here
[16:47:28 EST(-0500)] <colinclark> That is our primary concern here.
[16:47:37 EST(-0500)] <Bosmon> Eli could write his binder by means of the "search" I mentioned
[16:47:44 EST(-0500)] <Bosmon> Especially if we implemented a few helpful utility functions
[16:48:06 EST(-0500)] <Bosmon> Each decorator, for a start, should be "branded" with its concrete type, in the way that we have temporarily lost through non-prototypalism
[16:48:54 EST(-0500)] <Bosmon> So, we could simply make a utility getSubcomponentForType("fluid.undo", decoratorlist)
[16:49:17 EST(-0500)] <Bosmon> Well
[16:49:20 EST(-0500)] <Bosmon> I guess we can do better than that
[16:49:23 EST(-0500)] <Bosmon> It is a bit crappy
[16:49:23 EST(-0500)] <colinclark> I am slightly distracted here...
[16:49:27 EST(-0500)] <Bosmon> Gah
[16:49:28 EST(-0500)] <colinclark> Give me a moment.
[16:49:29 EST(-0500)] <Bosmon> Stop that
[16:49:35 EST(-0500)] <colinclark> Can't.
[16:50:37 EST(-0500)] <Bosmon> OK, I am dimly seeing the shadows of a kind of "eventual pipecutter box"
[16:50:44 EST(-0500)] <ecochran> I'm enjoying this conversation... I'm sorry that I don't have that much to add
[16:50:46 EST(-0500)] <Bosmon> There is another related problem that we bumped into before
[16:50:55 EST(-0500)] <colinclark> I wish I had had such a pipecutter box today at the boat.
[16:50:59 EST(-0500)] <colinclark> The ground was sort of wet.
[16:51:00 EST(-0500)] <Bosmon> Which is "how do you write an event handler which knows WHICH bloody object it is binding against"
[16:51:13 EST(-0500)] <Bosmon> That is, when the underlying signature has not already provided for it
[16:51:26 EST(-0500)] <Bosmon> I can't remember the use case now
[16:51:28 EST(-0500)] <Bosmon> Do you remember it?
[16:51:32 EST(-0500)] <Bosmon> We were at a very similar point
[16:51:45 EST(-0500)] <Bosmon> And saying, "Well, how could we mandate a particular signature for all events"?
[16:51:57 EST(-0500)] <Bosmon> "Wouldn't it be useful if the object instance itself were passed as the first event argument"
[16:52:15 EST(-0500)] <Bosmon> And I said, yes, it would be useful, but could never be a thing we could lay down as a general policy
[16:52:34 EST(-0500)] <Bosmon> Just simply because there are so many people who would have a perfectly good purpose for their first event argument that they don't want messed with
[16:53:41 EST(-0500)] <colinclark> That is at the heart of the issue in many ways.
[16:53:49 EST(-0500)] <Bosmon> Yes
[16:53:51 EST(-0500)] <Bosmon> SO!
[16:54:00 EST(-0500)] <Bosmon> We require the "EVENT DEFUNNELLING RESHAPER"
[16:54:32 EST(-0500)] <Bosmon> Declarative syntax for not only RELABELLING, but also RESHAPING the argument payload of events whilst in transit
[16:56:43 EST(-0500)] <Bosmon> so....
[16:56:49 EST(-0500)] <Bosmon> with the registration for a listener
[16:56:55 EST(-0500)] <Bosmon> may also follow an "optional reshaping syntax"
[17:17:09 EST(-0500)] * apetro (n=apetro@wsip-98-174-242-39.ph.ph.cox.net) has joined #fluid-work
[17:49:24 EST(-0500)] * theclown_afk (n=theclown@guiseppi.atrc.utoronto.ca) has left #fluid-work
[18:10:43 EST(-0500)] * lessthanzero (n=lessthan@CPE001ff342457c-CM001ac352aefc.cpe.net.cable.rogers.com) has joined #fluid-work
[19:14:09 EST(-0500)] * colinclark (n=colin@bas1-toronto09-1279721821.dsl.bell.ca) has joined #fluid-work
[19:49:22 EST(-0500)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work
[20:40:28 EST(-0500)] * ptmahent (n=ptmahent@bas21-toronto12-1279687981.dsl.bell.ca) has joined #fluid-work
[21:11:32 EST(-0500)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work
[21:17:04 EST(-0500)] * colinclark (n=colin@bas1-toronto09-1279721821.dsl.bell.ca) has joined #fluid-work
[23:26:57 EST(-0500)] * ptmahent (n=ptmahent@kb-v832-130-63-234-225.airyork.yorku.ca) has joined #fluid-work