fluid-work IRC Logs-2008-11-11

[09:57:04 EST(-0500)] * JASIGLogBot (i=jasigch@jasigch.Princeton.EDU) has joined #fluid-work
[09:57:04 EST(-0500)] * Topic is 'Remembrance Day' set by Justin_o on 2008-11-11 08:43:26 EST(-0500)
[09:57:09 EST(-0500)] <EricDalquist> there we go
[09:57:17 EST(-0500)] <anastasiac> thanks!
[09:57:18 EST(-0500)] <Justin_o> EricDalquist: thank you
[09:57:21 EST(-0500)] <colinclark> Welcome back, JASIGLogBot!
[09:57:25 EST(-0500)] <colinclark> EricDalquist: You rule, thanks.
[10:17:51 EST(-0500)] * Bosmo1 (n=Antranig@ginger.caret.cam.ac.uk) has joined #fluid-work
[10:27:01 EST(-0500)] * colinclark (n=colin@bas1-toronto09-1279721821.dsl.bell.ca) has joined #fluid-work
[10:37:09 EST(-0500)] <jacobfarber> could anyone point out what im doing wrong with this syntax? $('*:not(img, script, noscript, iframe, param, option)','body')
[10:39:37 EST(-0500)] <jacobfarber> turns out it should look like: $('*:not(img):not(script):not(noscript):not(iframe):not(param):not(option)','body')
[10:59:57 EST(-0500)] <jacobfarber> here's another one: any way to parse a classname or id's css info?
[11:02:21 EST(-0500)] <jacobfarber> ping?
[11:14:42 EST(-0500)] * apetro (n=apetro@wsip-98-174-242-39.ph.ph.cox.net) has joined #fluid-work
[11:28:08 EST(-0500)] * colinclark (n=colin@142.150.154.101) has joined #fluid-work
[11:31:46 EST(-0500)] * anastasiac (n=team@142.150.154.160) has left #fluid-work
[11:31:53 EST(-0500)] * anastasiac (n=team@142.150.154.160) has joined #fluid-work
[11:52:34 EST(-0500)] * colinclark (n=colin@142.150.154.101) has joined #fluid-work
[11:58:32 EST(-0500)] <anastasiac> Bosmo1, do you have a moment for a question about the Fluid event system?
[11:59:47 EST(-0500)] <Bosmo1> Go ahead
[11:59:55 EST(-0500)] <anastasiac> Technically, a component implementor could override an event's multicast/unicast/preventable setting by including an 'events' object in the user options.
[12:00:04 EST(-0500)] <anastasiac> my question is: is this reasonable?
[12:00:08 EST(-0500)] <anastasiac> is there a use case for this?
[12:00:11 EST(-0500)] <Bosmo1> Well no, it is not
[12:00:16 EST(-0500)] <anastasiac> or would we discourage this?
[12:00:17 EST(-0500)] <Bosmo1> This relates to an earlier discussion we had
[12:00:32 EST(-0500)] <anastasiac> it's not possible? or not reasonable?
[12:00:35 EST(-0500)] <Bosmo1> About a potential for some "that" properties to be really truly "private" or at the very least unmergable
[12:00:40 EST(-0500)] <Bosmo1> It is possible, but very unreasonable
[12:00:44 EST(-0500)] <anastasiac> ok, that's what I suspected
[12:00:56 EST(-0500)] <anastasiac> the events are there, but not really 'public'
[12:01:31 EST(-0500)] <Bosmo1> Well, it is good that the actual firer is public
[12:01:37 EST(-0500)] <Bosmo1> But it shouldn't be "easy" for it to be displaced
[12:01:42 EST(-0500)] <Bosmo1> It's a hard issue in Javascript
[12:01:48 EST(-0500)] <anastasiac> no, I was referring to the 'events' object in the defaults
[12:01:52 EST(-0500)] <Bosmo1> It is essentially impossible to forbid anything, very reasonably
[12:01:53 EST(-0500)] <Bosmo1> Yes
[12:02:04 EST(-0500)] <anastasiac> ok, cool - thanks for the confirmation
[12:02:21 EST(-0500)] <Bosmo1> OK... but it is sort of the same issue relating to simply scrawling over the "events" object once the component has fired up
[12:02:45 EST(-0500)] <anastasiac> the issue being we don't want this to happen?
[12:03:20 EST(-0500)] <Bosmo1> Well, yes
[12:03:28 EST(-0500)] <Bosmo1> But also, that we don't really want to pay the costs of forbidding it
[12:03:42 EST(-0500)] <Bosmo1> In theory, you can just overwrite anything, anywhere
[12:03:48 EST(-0500)] <Bosmo1> That isn't hidden behind a closure
[12:04:08 EST(-0500)] <Bosmo1> It is one of the standing risks of "declarative programming"
[12:04:17 EST(-0500)] <Bosmo1> That someone, some time later, may just decide to "declare" something else
[12:51:42 EST(-0500)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work
[13:31:59 EST(-0500)] <jessm> towhomitmayconcern – i'll be back in 30
[14:08:58 EST(-0500)] <Bosmo1> Hoorah
[14:09:05 EST(-0500)] <Bosmo1> I have broken InlineEdit beyond recognition
[14:09:19 EST(-0500)] <Justin_o> is that a good thing?
[14:10:46 EST(-0500)] <Bosmo1> I'm not convinced
[14:10:51 EST(-0500)] <Bosmo1> It has a much better structure now
[14:11:03 EST(-0500)] <Bosmo1> It just doesn't work worth a damn...
[14:11:29 EST(-0500)] <Bosmo1> No, wait... it did pass one test
[14:11:43 EST(-0500)] <Justin_o> so it's better just as long as you don't want to edit things
[14:12:26 EST(-0500)] <Bosmo1> Yes, it is that kind of control now
[14:13:12 EST(-0500)] <Bosmo1> It is probably best not to edit things anyway
[14:13:18 EST(-0500)] <Bosmo1> Editing stuff can lead to conflict
[14:40:10 EST(-0500)] <Bosmo1> OK
[14:40:17 EST(-0500)] <Bosmo1> There is less destruction now
[14:40:36 EST(-0500)] <Bosmo1> The "novel stuff" in my branch is moving InlineEdit over to our standard IoC framework for its "views"
[14:40:38 EST(-0500)] <Bosmo1> Which is now has some of
[14:40:54 EST(-0500)] <Justin_o> are you completely remaking inline edit like you did with reorderer
[14:40:55 EST(-0500)] <Bosmo1> In particular we have these two new options in the structure:
[14:40:57 EST(-0500)] <Bosmo1>
[14:40:57 EST(-0500)] <Bosmo1> displayView: "fluid.inlineEdit.standardDisplayView",
[14:40:57 EST(-0500)] <Bosmo1>
[14:40:57 EST(-0500)] <Bosmo1> editView: "fluid.inlineEdit.standardEditView",
[14:41:05 EST(-0500)] <Bosmo1> No, it is much less awful than that
[14:41:14 EST(-0500)] <Bosmo1> InlineEdit is sort of 80% right already
[14:41:23 EST(-0500)] <Bosmo1> Reorderer was something like 20% right
[14:41:34 EST(-0500)] <Bosmo1> And it was far more complex
[14:41:37 EST(-0500)] <Justin_o> oh that's a lot better then
[14:41:43 EST(-0500)] <Bosmo1> I am really just "modernising" InlineEdit
[14:41:51 EST(-0500)] <Bosmo1> To use our stupendous initSubcomponents framework
[14:42:00 EST(-0500)] <Justin_o> i see
[14:42:02 EST(-0500)] <Bosmo1> Which is the way that people will customise it for different cases of inline-editability
[14:42:12 EST(-0500)] <Bosmo1> Such as rich text, drop-downs, etc.
[14:42:20 EST(-0500)] <Justin_o> okay... i was just going to ask that
[14:42:28 EST(-0500)] <Bosmo1> I have also upgraded initSubcomponents a little to accept "direct function"
[14:42:29 EST(-0500)] <Justin_o> this will make those other forms of inline edit possible
[14:42:32 EST(-0500)] <Bosmo1> "direct functions"
[14:42:41 EST(-0500)] <Bosmo1> For those who don't like or want String-based IoC
[14:42:52 EST(-0500)] <Bosmo1> Or don't want to set up a global namespace
[14:43:17 EST(-0500)]

[14:43:34 EST(-0500)] <Bosmo1> The downside of this, from the users point of view, is that you cannot take advantage of any options default system for your particular "creator"
[14:43:40 EST(-0500)] <Bosmo1> Since you have not supplied a name for it
[14:43:46 EST(-0500)] <Bosmo1> But I can imagine some people may want to do it this way
[14:43:59 EST(-0500)] <Bosmo1> Troglodytes and other simians
[14:44:40 EST(-0500)] <Bosmo1> If I get time before the summit, I will also "modernise" Pager, which is at least 3 generations behind now in framework terms
[14:44:46 EST(-0500)] <Bosmo1> It doesn't even use the DOM binder
[14:44:51 EST(-0500)] <Bosmo1> Colin and I have a pact
[14:45:03 EST(-0500)] <Bosmo1> That at least one of us will see to Pager within the next week
[14:45:15 EST(-0500)] <Justin_o> oh that's good... it's been dormant for a while
[14:45:23 EST(-0500)] <Bosmo1> Yes
[14:45:27 EST(-0500)] <Bosmo1> It is really pretty crusty
[14:45:36 EST(-0500)] <Bosmo1> Anyway, inlineEdit is now based around a fairly clear contract on "views"
[14:45:40 EST(-0500)] <Bosmo1> Which each have a "mini-that"
[14:45:50 EST(-0500)] <Bosmo1> It has two methods, value(), and refreshView()
[14:46:07 EST(-0500)] <Bosmo1> value is both a getter and setter, JQuery-style
[14:46:34 EST(-0500)] <Bosmo1> refreshView has the same contract that our single "fused" refreshView method used to have
[14:47:02 EST(-0500)] <Bosmo1> The style of creating these also shows how we can incorporate "inheritance" in our new "that-ist" scheme
[14:47:14 EST(-0500)] <Bosmo1> Since both of these view classes "descend from a common parent", in old-speak
[14:47:25 EST(-0500)] <Bosmo1> "fluid.inlineEdit.standardAccessor"
[14:47:36 EST(-0500)] <Bosmo1> Holds the common implementation of their "value" methods, which by default is the same for each
[14:47:56 EST(-0500)] <Bosmo1> For a rich text control, both of the "value" methods would diverge from the default
[14:48:19 EST(-0500)] <Bosmo1> The display view would set the html rather than the text, and the edit view would do whatever weird malarky is required for the particular flavour of rich text control
[14:49:16 EST(-0500)] <Bosmo1> The contract probably still needs to be shaped up a bit
[14:49:26 EST(-0500)] <Bosmo1> We don't really want to pass the entire top-level component to the individual refreshView
[14:49:34 EST(-0500)] <Justin_o> interesting
[14:49:56 EST(-0500)] <Bosmo1> Anyway, there is a very interesting and clear distinction which has arisen in this work
[14:50:18 EST(-0500)] <Bosmo1> Which is the separation in responsibility for rendering the markup for a view, and the responsibility for maintining it
[14:50:32 EST(-0500)] <Bosmo1> I looked at our old "editModeRenderer" call, and decided that we probably wanted to retain it for now
[14:50:48 EST(-0500)] <Bosmo1> Although we could think about folding this in as a "render" call on the "sub-that"
[14:50:49 EST(-0500)] <Bosmo1> BUT
[14:51:03 EST(-0500)] <Justin_o> what does maintaining it mean
[14:51:17 EST(-0500)] <Bosmo1> There is an interesting issue that there is a whole lot of centralised logic inside "renderEditContainer" function in the base InlineEdit
[14:51:40 EST(-0500)] <Bosmo1> Maintaining it means, being responsible for ferrying updates in value to and from the model
[14:51:54 EST(-0500)] <Bosmo1> Now, there are some things we simply don't want to allow the user to customise
[14:52:26 EST(-0500)] <Bosmo1> For example, there must remain the base contract that we can discover particular DOM nodes, which we call viewEl, editField, editContainer, by means of a particular algorithm based on the supplied selectors
[14:52:43 EST(-0500)] <Bosmo1> And in a particular combination of these, we only conditionally invoke the editModeRenderer
[14:52:54 EST(-0500)] <Bosmo1> The details of this algorithm are not something we want the user to be able to change
[14:53:07 EST(-0500)] <Bosmo1> Since for a start, they are pretty subtle
[14:53:20 EST(-0500)] <Bosmo1> And secondly, they will simply create an InlineEdit that doesn't obey its basic contract
[14:53:41 EST(-0500)] <Bosmo1> So, this is the reason I have kept "editModeRenderer" as a standalone configuration as it was before
[14:53:46 EST(-0500)] <Bosmo1> As well as for backwards compatibility
[14:53:48 EST(-0500)] <Bosmo1> SO
[14:54:02 EST(-0500)] <Bosmo1> A "view" is handed, as if by magic, an already constructed viewEl or editField
[14:54:07 EST(-0500)] <Bosmo1> And it is not really to know how it got there
[14:54:20 EST(-0500)] <Bosmo1> It is only to have a general idea what type of node it is, and how to frob it to get at its value
[14:54:41 EST(-0500)] <Bosmo1> Clearly there will need to be a bit more "side contract" in the case that the DOM node itself is not necessarily enough starting info
[14:54:56 EST(-0500)] <Bosmo1> But I am imagining we might do this with something like jQuery.data if necessary
[14:55:04 EST(-0500)] <Bosmo1> Anyway, this is my thinking to date
[14:55:28 EST(-0500)] <Justin_o> seems like you've put a lot of work into it...
[14:56:17 EST(-0500)] <Bosmo1> Well, thankfully not too much of the code has changed
[14:56:27 EST(-0500)] <Bosmo1> Some of the issues surrounding display padding, etc. are a bit unclear
[14:56:41 EST(-0500)] <Bosmo1> It's not quite clear how much of this might want or make sense to reuse in different kinds of view
[14:57:52 EST(-0500)] <Bosmo1> I guess if you don't want them, you will make your own "view" completely
[14:58:15 EST(-0500)] <Bosmo1> If you want some of the existing behaviour, such as the accessor, but not the padding, you could do the same "derivation" trick that the standard views do
[14:59:32 EST(-0500)] <Justin_o> Bosmo1: sorry.. i have to go now.. thanks for all the info
[15:06:43 EST(-0500)] * colinclark (n=colin@142.150.154.101) has joined #fluid-work
[15:14:23 EST(-0500)] * colinclark_ (n=colin@142.150.154.153) has joined #fluid-work
[23:15:44 EST(-0500)] * theclown (n=theclown@bas1-cooksville17-1279414139.dsl.bell.ca) has joined #fluid-work
[23:24:13 EST(-0500)] * theclown (n=theclown@bas1-cooksville17-1279414139.dsl.bell.ca) has left #fluid-work