/
fluid-work IRC Logs-2008-12-11

fluid-work IRC Logs-2008-12-11

Dec 11, 2008

[07:50:34 EST(-0500)] * EricDalquist (n=EricDalq@adsl-76-208-68-161.dsl.mdsnwi.sbcglobal.net) has joined #fluid-work
[08:05:11 EST(-0500)] * jessm (n=Jess@c-24-34-214-137.hsd1.ma.comcast.net) has joined #fluid-work
[08:53:53 EST(-0500)] * Justin_o (n=Justin@142.150.154.101) has joined #fluid-work
[09:25:27 EST(-0500)] * anastasiac (n=team@142.150.154.160) has joined #fluid-work
[09:27:49 EST(-0500)] * jacobfarber (n=Main@CPE00095bc35ea1-CM001692f5798c.cpe.net.cable.rogers.com) has joined #fluid-work
[09:28:52 EST(-0500)] * fj4000 (n=Main@CPE00095bc35ea1-CM001692f5798c.cpe.net.cable.rogers.com) has joined #fluid-work
[09:29:23 EST(-0500)] <anastasiac> Justin_o, I will have a look at Bosmon's fix for FLUID-1944
[09:29:39 EST(-0500)] <Justin_o> anastasiac: thank you
[09:29:56 EST(-0500)] <Justin_o> i think there may still be that extra comma problem... i'll let you know the line number if i find it
[09:31:49 EST(-0500)] <anastasiac> line 48, Justin_o
[09:32:12 EST(-0500)] <Justin_o> oh you found it okay.. thanks
[09:32:21 EST(-0500)] <anastasiac> yes - gotta love Aptana
[09:32:27 EST(-0500)] <anastasiac> big red X in the margin
[09:32:33 EST(-0500)] <Justin_o> oh.. that will help
[09:38:37 EST(-0500)] * jessm (n=Jess@c-24-34-214-137.hsd1.ma.comcast.net) has joined #fluid-work
[09:38:54 EST(-0500)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined #fluid-work
[09:43:12 EST(-0500)] * anastasiac (n=team@142.150.154.160) has joined #fluid-work
[09:43:23 EST(-0500)] * colinclark (n=colin@bas1-toronto09-1279621564.dsl.bell.ca) has joined #fluid-work
[09:53:23 EST(-0500)] <colinclark> Justin_o: You saw my FLUID-1768 patch last night?
[09:53:40 EST(-0500)] <Justin_o> I am updating the daily build now
[09:53:54 EST(-0500)] <Justin_o> colinclark: i believe i saw the commit
[09:54:13 EST(-0500)] <Justin_o> or the comment of fluid-work
[09:54:19 EST(-0500)] <colinclark>
[09:54:24 EST(-0500)] * clown (n=clown@guiseppi.atrc.utoronto.ca) has joined #fluid-work
[09:54:43 EST(-0500)] <colinclark> Cool. It hasn't been reviewed yet, I guess, but if you want to get started early with testing SWFUpload 2.2.0, feel free to give it a shot.
[09:55:04 EST(-0500)] <colinclark> I'm finding the VM juggling process a bit of a challenge, balancing different browsers alongside different Flash versions.
[09:55:25 EST(-0500)] <Justin_o> yes.. it can be
[09:56:25 EST(-0500)] <Justin_o> also i was speaking to bosmon about fluid-1830... he's not sure the appropriate way to do the unit tests because the editors
[09:56:37 EST(-0500)] <Justin_o> namely they aren't included in our source
[09:56:43 EST(-0500)] <Justin_o> colinclark: ^
[09:56:48 EST(-0500)] <EricDalquist> CSS question, is it better to target CSS to elements via IDs or named classes?
[09:57:26 EST(-0500)] <colinclark> EricDalquist: fj4000 can probably give you a much better answer...
[09:57:29 EST(-0500)] <colinclark> but it depends.
[09:57:49 EST(-0500)] <colinclark> IDs are going to be more specific than classes, which can sometimes be a benefit.
[09:58:00 EST(-0500)] <colinclark> We've been building our skinning system almost entirely with classes...
[09:58:22 EST(-0500)] <EricDalquist> that's what I thought
[09:58:23 EST(-0500)] <colinclark> feeling like it was better for a solution where assumptions about the whole document can be risky.
[09:58:49 EST(-0500)] <colinclark> fj4000: Any thoughts?
[09:58:51 EST(-0500)] <fj4000> you should really try to stick to classes if possible
[09:59:13 EST(-0500)] <fj4000> ids are great for use as hooks and the occasional override
[09:59:36 EST(-0500)] <fj4000> but they can make you css britle
[10:00:04 EST(-0500)] <fj4000> just my 2c
[10:00:49 EST(-0500)] <EricDalquist> thanks for the input
[10:01:02 EST(-0500)] <EricDalquist> we have some folks new to doing UI development in a portal
[10:01:36 EST(-0500)] <EricDalquist> and trying to convince them that they need to do things via classes since the IDs generally contain the dynamically generated portlet namespace key
[10:02:02 EST(-0500)] <fj4000> your going to find the power of classname combinations can help keep you css and markup very very clean
[10:02:06 EST(-0500)] <fj4000> and flexible
[10:02:16 EST(-0500)] <fj4000> yes, absolutely
[10:03:09 EST(-0500)] <fj4000> IDs as namespaces and classnames for presentation data sounds like a great strategy
[10:04:04 EST(-0500)] <EricDalquist> thanks for the conformation as well
[10:04:14 EST(-0500)] <fj4000>
[10:04:56 EST(-0500)] <EricDalquist> at first they came to me yesterday asking how to generate the CSS from a jsp so they could target it to the namespaced IDs
[10:06:13 EST(-0500)] <fj4000> you mean like #namespace .myClass {} ?
[10:06:42 EST(-0500)] <EricDalquist> like generating a CSS class like #elementId_namespace {}
[10:07:25 EST(-0500)] <EricDalquist> lots of the ids look like id="filterDiv_filterKey_fitlerOpt_portletNamespace" where filterKey, filterOpt and portletNamespace are dynamic
[10:07:25 EST(-0500)] <fj4000> yech
[10:07:29 EST(-0500)] <EricDalquist> yup
[10:07:43 EST(-0500)] <EricDalquist> the ids work very well like that for doing JS callbacks
[10:08:01 EST(-0500)] <EricDalquist> you can find exactly the element you want and your ensured there aren't conflicts on the page via the portletNamespace
[10:08:35 EST(-0500)] <EricDalquist> I just have a few more emails worth of convincing that styling of an element like that should all be done via class=""
[10:09:01 EST(-0500)] <fj4000> just show them how LITTLE code they would need to write
[10:09:31 EST(-0500)] <fj4000> when you can recycle combinations to create the layout your after!
[10:10:35 EST(-0500)] <EricDalquist>
[10:15:23 EST(-0500)] <colinclark> Justin_o: Sorry, I missed your comment. Let me check.
[10:16:17 EST(-0500)] <Justin_o> colinclark: that's okay, i believe bosmon is still on his way into work
[10:16:37 EST(-0500)] <colinclark> Justin_o: He's so generous to describe FCKEditor as having a "Christmas tree of decorations."
[10:16:45 EST(-0500)] <colinclark> I might have put it differently.
[10:17:10 EST(-0500)] <Justin_o> he's very festive
[10:19:29 EST(-0500)] <colinclark>
[10:20:17 EST(-0500)] <Justin_o> colinclark: i'm starting to slim down the bug parade... how do you think it is looking for uploader related issues
[10:20:57 EST(-0500)] <colinclark> Lemme take a look, on second.
[10:21:19 EST(-0500)] <Justin_o> sure
[10:22:21 EST(-0500)] <colinclark> Justin_o: The Uploader blockers are all on their way, assuming fj4000 is going to work with Eli sometime today to deal with the CSS.
[10:22:45 EST(-0500)] <Justin_o> yep...
[10:22:52 EST(-0500)] <Justin_o> i'll check in with them on that
[10:23:31 EST(-0500)] <Justin_o> have you taken a look at the patch for Fluid-1948
[10:23:33 EST(-0500)] * Bosmon (n=Antranig@ginger.caret.cam.ac.uk) has joined #fluid-work
[10:23:48 EST(-0500)] <anastasiac> hi, Bosmon
[10:24:11 EST(-0500)] <Bosmon> Hi
[10:24:13 EST(-0500)] <colinclark> Justin_o: It's on my list.
[10:24:14 EST(-0500)] <anastasiac> colinclark and I were just having an IM discussion about the global FCKeditor_OnComplete function
[10:24:20 EST(-0500)] <Bosmon> Ah yes
[10:24:20 EST(-0500)] <Justin_o> colinclark: thanks
[10:24:26 EST(-0500)] <Bosmon> It is actually no longer 100% necessary
[10:24:39 EST(-0500)] <Bosmon> Since I discovered last night a simpler way of getting the initial value into FCKEditor
[10:24:46 EST(-0500)] <colinclark> Bosmon: how?
[10:24:59 EST(-0500)] <Bosmon> Ah well, you see
[10:25:08 EST(-0500)] <Bosmon> It was suggested by an analogous problem with TinyMCE
[10:25:16 EST(-0500)] <Bosmon> These pieces of code really are incredibly shitty
[10:25:24 EST(-0500)] <colinclark> No kidding.
[10:25:39 EST(-0500)] <Bosmon> It seems that during initialisation, there is a moment that they claim to exist but nonetheless do not honour changes to values made via their APIs
[10:25:55 EST(-0500)] <colinclark> oh god
[10:25:56 EST(-0500)] <Bosmon> I write for posterity that the developers of TinyMCE and FCKEditors are shitheads
[10:26:01 EST(-0500)] <Bosmon> Anyway
[10:26:22 EST(-0500)] <colinclark> I'd like to add the SWFUpload developer to that list, but I had to be mean.
[10:26:24 EST(-0500)] <Bosmon> It seems that, if you fail to get sense out of them in one angle, if you instead still go back to the "in process of destruction" textarea they are based on
[10:26:25 EST(-0500)] <colinclark> hate
[10:26:32 EST(-0500)] <Bosmon> And set the value on that
[10:26:42 EST(-0500)] <Bosmon> Then generally they will pick up the value from there "in time"
[10:26:47 EST(-0500)] <colinclark> wow
[10:26:54 EST(-0500)] <colinclark> odd and frightening
[10:27:00 EST(-0500)] <Bosmon> Yes, it really is
[10:27:10 EST(-0500)] <colinclark> So are you considering modifying your implementation?
[10:27:18 EST(-0500)] <Bosmon> I found with some testing that my complex event-based thing would not work for the SECOND FCKEditor of a set
[10:27:21 EST(-0500)] <Bosmon> I fixed it already
[10:27:27 EST(-0500)] <colinclark> Where?
[10:27:36 EST(-0500)] <Bosmon> That is, the event is only delivered ONCE, for the all-time loading of the FCKeditor code
[10:27:51 EST(-0500)] <Bosmon> Nonetheless, it can still be possible for the SECOND FCKEditor you try to invoke to be "not ready"
[10:28:01 EST(-0500)] <Bosmon> Well, I mean, that global callback is now disused in trunk
[10:28:03 EST(-0500)] <Bosmon> If you notice
[10:28:11 EST(-0500)] <Bosmon> Both of the "accessors" now use this trick I just mentioned
[10:28:36 EST(-0500)] <anastasiac> so - the global function is not used, and can be deleted??
[10:28:38 EST(-0500)] <colinclark> So anastasiac can just hose this global callback/
[10:28:43 EST(-0500)] <colinclark> beat me to it
[10:28:52 EST(-0500)] <Bosmon> Well, I left it there
[10:28:54 EST(-0500)] <Bosmon> "For a convenience"
[10:29:04 EST(-0500)] <anastasiac> whose convenience??
[10:29:07 EST(-0500)] <Bosmon> As it stands, there is no way that more than one person can register as a listener for this event
[10:29:14 EST(-0500)] <Bosmon> Because of the way it is structured
[10:29:20 EST(-0500)] <Bosmon> The convenience of the PUBLICK!
[10:29:40 EST(-0500)] <colinclark> Bosmon: So are you advocating leaving it?
[10:29:50 EST(-0500)] <Bosmon> Yes
[10:29:55 EST(-0500)] <Bosmon> Do you think it should go?
[10:30:05 EST(-0500)] <colinclark> So then there is the natural ambiguity of "which fluid?"
[10:30:24 EST(-0500)] <Bosmon> Well, to be sure
[10:30:33 EST(-0500)] <colinclark> Since this is a global callback, we'll have to be content with it being ambiguous.
[10:30:49 EST(-0500)] <Bosmon> But that is elegance itself, compared to contemplating the phenomenon of a man engaged in the act of cutting off his own head
[10:30:59 EST(-0500)] <colinclark> wow
[10:31:08 EST(-0500)] <colinclark> that's a slightly disturbing analogy
[10:31:08 EST(-0500)] <colinclark>
[10:31:34 EST(-0500)] <anastasiac> indeed :-/
[10:31:41 EST(-0500)] <colinclark> what is it a reference to?
[10:32:18 EST(-0500)] <colinclark> Ok, so anastasiac, you're find to add fluid to the list of declared globals, and perhaps a comment saying, "this global function will refer to whichever version of Fluid Infusion was first loaded.
[10:32:32 EST(-0500)] <Bosmon> Isn't it the last loaded?
[10:32:49 EST(-0500)] <Bosmon> Here we go:
[10:32:55 EST(-0500)] <Bosmon> "My good sir, the awkwardness of your position is grace itself compared with that of a man engaged in the act of cutting off his own head."
[10:33:00 EST(-0500)] <Bosmon> http://math.boisestate.edu/GaS/mikado/libretto.txt
[10:33:02 EST(-0500)] <colinclark> var fluid = fluid || fluid_0_6;
[10:33:18 EST(-0500)] <Bosmon> Right
[10:33:28 EST(-0500)] <Bosmon> But the actual ENTRY of the callback is achieved by simple file inclusion
[10:33:35 EST(-0500)] <Bosmon> Hmm...
[10:33:36 EST(-0500)] <colinclark> aha, haven't you been quoting a lot of William Gilbert librettos recently?
[10:33:54 EST(-0500)] <Bosmon> OK, I see
[10:33:59 EST(-0500)] <colinclark> yes
[10:34:04 EST(-0500)] <Bosmon> Each included file will simply rebind the callback to the "same thing"
[10:34:38 EST(-0500)] <Bosmon> At least it does something that is consistent with something else
[10:34:53 EST(-0500)] <colinclark> yeah, it's fine
[10:35:12 EST(-0500)] <colinclark> it should just be clear what the consequence of being this horribly global is.
[10:35:29 EST(-0500)] <colinclark> the comment above it is pretty sufficient
[10:35:53 EST(-0500)] <colinclark> So Bosmon, anastasiac has a small patch of tweaks to InlinEditIntegrations.js
[10:36:08 EST(-0500)] <Bosmon> cool
[10:36:17 EST(-0500)] <Bosmon> Including the comma?
[10:36:20 EST(-0500)] <anastasiac> actually, they've been committed (all save this last)
[10:36:22 EST(-0500)] <anastasiac> yes, including the comma
[10:36:24 EST(-0500)] <colinclark> ok
[10:36:28 EST(-0500)] <Bosmon>
[10:36:36 EST(-0500)] <anastasiac> I'll commit this last, then someone can review
[10:36:45 EST(-0500)] <colinclark> It includes a few name changes, and the addition of an inlineEditDropdown() creator function.
[10:36:51 EST(-0500)] <Bosmon> I realised in talking to Justin_o that I must have left out some of the vital files from TinyMCE
[10:36:55 EST(-0500)] <Bosmon> Some that contain some of the icons
[10:36:57 EST(-0500)] <colinclark> aha
[10:37:01 EST(-0500)] <Bosmon> I assumed that lower panel was meant to be blank
[10:37:09 EST(-0500)] <Bosmon> But apparently it has functional, but invisible icons in it
[10:37:28 EST(-0500)] <Bosmon> Cool, what name changes do we have
[10:37:33 EST(-0500)] <colinclark> I like how you've kept track of these various configurations by storing them in fluid.defaults()
[10:37:43 EST(-0500)] <colinclark> "fluid.inlineTinyMCE"
[10:37:50 EST(-0500)] <colinclark> "fluid.inlineFCKEditor"
[10:37:59 EST(-0500)] <colinclark> I think that's it, right anastasiac?
[10:38:08 EST(-0500)] <anastasiac> I was wondering about that! I hover over the bar, and get the tooltips
[10:38:14 EST(-0500)] <anastasiac> colinclark, yes
[10:38:39 EST(-0500)] <Bosmon> Well, you have renamed all of the other namespaces to match?
[10:38:53 EST(-0500)] <colinclark> anastasiac: indeed
[10:39:21 EST(-0500)] <anastasiac> only the names of the defaults were changed
[10:39:28 EST(-0500)] <colinclark> These guys should match:
[10:39:28 EST(-0500)] <Bosmon> That doesn't seem very sensible
[10:39:29 EST(-0500)] <colinclark> fluid.tinyMCE = {};
[10:39:39 EST(-0500)] <Bosmon> The names of the defaults used to match the names of the creator function namespaces
[10:39:55 EST(-0500)] <anastasiac> right, gotcha
[10:39:58 EST(-0500)] <Justin_o> fj4000: is Fluid-1901 finished, and if not will you have time to before the end of the week. I'm thinking about pulling it from the bug parade
[10:40:15 EST(-0500)] <fj4000> let me take a look
[10:40:20 EST(-0500)] <colinclark> So I was wrangling with SWFUpload and Flash 10 until 1 am last night...
[10:40:28 EST(-0500)] <Bosmon> And if you are going to rename those, to something longer, I would prefer you did something regular
[10:40:34 EST(-0500)] <Bosmon> Like fluid.inlineEdit.tinyMCE
[10:40:42 EST(-0500)] <colinclark> that would be fine
[10:40:51 EST(-0500)] <fj4000> Justin_o there are some basics there....
[10:41:05 EST(-0500)] <fj4000> i was hoping to get some more time to make more demos, but the core ideas are there
[10:41:07 EST(-0500)] <Bosmon> Although that does now create a file inclusion order risk
[10:41:30 EST(-0500)] <colinclark> Bosmon: well, it's safe to assume that this should go after InlineEdit.js, isn't it?
[10:41:39 EST(-0500)] <colinclark> Since it depends on it.
[10:41:41 EST(-0500)] <Bosmon> Well, is it?
[10:42:01 EST(-0500)] <Justin_o> fj4000: i'll try to take a look at your patch then and make a decesion later... thanks
[10:42:05 EST(-0500)] <colinclark> I'd say so, yes.
[10:42:06 EST(-0500)] <fj4000> Justin_o: could you take a look at fluid-components/html/FSS.html and let me know if you think it needs more demos to be considered "done" ?
[10:42:12 EST(-0500)] <fj4000> yes, thanks
[10:42:26 EST(-0500)] <Bosmon> Well, without this change, it would be possible for them to be included in an arbitrary order
[10:42:42 EST(-0500)] <Bosmon> And as I think as we have discovered, under some loading models, some browsers do not guarantee to respect a particular order
[10:42:55 EST(-0500)] <colinclark> Bosmon: Then you'll have to live with non-regular naming here.
[10:43:06 EST(-0500)] <Bosmon> Why is that?
[10:43:19 EST(-0500)] <colinclark> Well, you can have one or the other, it appears.
[10:43:24 EST(-0500)] <Bosmon> I see no justification for non-regular naming
[10:43:51 EST(-0500)] <colinclark> So then you are stuck with a specific inclusion order.
[10:44:12 EST(-0500)] <Bosmon> Well, how about calling the defaults "fluid.tinyMCE.inlineEdit"
[10:44:21 EST(-0500)] <Bosmon> etc.
[10:44:58 EST(-0500)] <colinclark> Fine by me.
[10:45:03 EST(-0500)] <Bosmon> ok, cool
[10:45:09 EST(-0500)] <colinclark> anastasiac: Cool?
[10:45:38 EST(-0500)] <anastasiac> I don't mind renaming, but I'm not quite clear on why?
[10:45:50 EST(-0500)] <Bosmon> Well, I wasn't quite clear on why you renamed them to start with
[10:45:57 EST(-0500)] * anastasiac hasn't had her second cup of coffee yet)
[10:46:00 EST(-0500)] <colinclark>
[10:46:05 EST(-0500)] <Bosmon> But, based on some assumptions about why you did it, I think this proposal is better
[10:46:16 EST(-0500)] <anastasiac> the defaults were for a flavour of inline edit, but made no mention of inline edit in their name
[10:46:24 EST(-0500)] <Bosmon> Right
[10:46:27 EST(-0500)] <colinclark>
[10:46:44 EST(-0500)] <Bosmon> But as they were, they matched a particular namespace regularly, which meant that in the future, it might be possible to locate them automatically
[10:46:58 EST(-0500)] <colinclark> right
[10:47:00 EST(-0500)] <Bosmon> In the way that we have in the past for various flavours of "defaults"
[10:47:04 EST(-0500)] <anastasiac> ?
[10:47:06 EST(-0500)] <Bosmon> For example, those for subcomponents or components
[10:47:13 EST(-0500)] <colinclark> Since, anastasiac, you've seen that we often refer to things by their names...
[10:47:32 EST(-0500)] <colinclark> Subcomponents instantiated as "fluid.fileQueueView," for example.
[10:48:05 EST(-0500)] <colinclark> If defaults and creators remain totally consistent, it means that we would be able to, with a name, be able to both look up its defaults and instantiate
[10:48:07 EST(-0500)] <colinclark> For example.
[10:48:07 EST(-0500)] * anastasiac is sure there's still something she's not getting
[10:48:28 EST(-0500)] * anastasiac sees a light!
[10:48:41 EST(-0500)] <anastasiac> ok, you're talking about having the defaults have the same name as the creator
[10:48:47 EST(-0500)] <colinclark> anastasiac: you got it
[10:48:57 EST(-0500)] <anastasiac> so that would be fluid.inlineEditFCK ?
[10:49:03 EST(-0500)] <anastasiac> which is the name of the creator?
[10:49:44 EST(-0500)] * anastasiac hears crickets
[10:49:48 EST(-0500)] <anastasiac> am I still not getting it?
[10:50:48 EST(-0500)] <Bosmon> Well, we don't actually have a specific component hierarchy in this area yet
[10:50:53 EST(-0500)] <Bosmon> But that doesn't mean we won't someday
[10:50:58 EST(-0500)] <Bosmon> In fact, we probably should
[10:51:26 EST(-0500)] <colinclark> anastasiac: You're definitely right here. The creators and the defaults need to match.
[10:51:36 EST(-0500)] <colinclark> Then Bosmon is wondering about the whole hierarchy of the name space.
[10:52:05 EST(-0500)] <anastasiac> start with fluid.inlineEdit, move to fluid.inlineEdit.tinyMCE, fluid.inlineEdit.dropdown ?
[10:52:17 EST(-0500)] <Bosmon> Well, we have a problem with that approach, as I mentioned before
[10:52:30 EST(-0500)] <Bosmon> Since this relies on access to the name "fluid.inlineEdit" which is declared in another file
[10:52:34 EST(-0500)] <anastasiac> yes
[10:52:39 EST(-0500)] <colinclark> I think we probably just need to suck it up and force an order.
[10:52:43 EST(-0500)] <colinclark> It's unavoidable.
[10:52:47 EST(-0500)] <Bosmon> Which is why I proposed organising around these names around the names we do have control over
[10:52:52 EST(-0500)] <Bosmon> fluid.tinyMCE.inlineEdit
[10:52:53 EST(-0500)] <Bosmon> etc.
[10:52:59 EST(-0500)] <anastasiac> there are lots of other cases in which we force an order
[10:53:02 EST(-0500)] <anastasiac> we're already doing it
[10:53:04 EST(-0500)] <Bosmon> Are there?
[10:53:06 EST(-0500)] <Bosmon> Such as where?
[10:53:11 EST(-0500)] <colinclark> jQuery before Fluid
[10:53:19 EST(-0500)] <colinclark> Fluid before any other component
[10:53:32 EST(-0500)] <Bosmon> Oh well
[10:53:33 EST(-0500)] <colinclark> These things break if the order is not correct.
[10:54:38 EST(-0500)] <colinclark> And I believe we can be confident that inclusion order will always be respected in all browsers.
[10:54:52 EST(-0500)] <Bosmon> Yes, for files that are written "physically"
[10:55:13 EST(-0500)] <colinclark> As opposed to injected later? Yes, you're right.
[10:57:04 EST(-0500)] <anastasiac> Bosmon, colinclark: a double-check about this renaming:
[10:57:17 EST(-0500)] <anastasiac> the objects containing the accessors (e.g. fluid.tinyMCE.inlineEditViewAccessor)
[10:57:28 EST(-0500)] <anastasiac> they can't be renamed to fluid.inlineTinyMCE, right?
[10:57:47 EST(-0500)] <colinclark> no
[10:59:23 EST(-0500)] <colinclark> So the thing to do is to move everything into second-tier namespace...
[10:59:33 EST(-0500)] <colinclark> which we have sort of not quite decided on.
[10:59:43 EST(-0500)] <colinclark> But taking Bosmon's suggestion...
[11:00:09 EST(-0500)] <colinclark> you'd be moving the creator function for the tinymce rich editor into the tinyMCE object
[11:00:54 EST(-0500)] <Bosmon> Or you could do it the other way
[11:00:55 EST(-0500)]

<colinclark> fluid.tinyMCE.inlineEdit = function (container, options)

Unknown macro: { ... }

;


[11:00:58 EST(-0500)] <Bosmon> So long as there is some regular rule
[11:01:05 EST(-0500)] <Bosmon> fluid.inlineEdit.tinyMCE =
[11:01:12 EST(-0500)] <Bosmon> If you think that would be clearer for external users
[11:01:14 EST(-0500)] <colinclark> right
[11:01:20 EST(-0500)] <colinclark> and then the defaults would similarly reflect this structure.
[11:01:26 EST(-0500)] <anastasiac> what is fluid.inlineEdit.tinyMCE equal to??
[11:01:32 EST(-0500)] <anastasiac> the creator function?
[11:01:39 EST(-0500)] <anastasiac> or the object containing the accessors?
[11:01:43 EST(-0500)] <colinclark> the former
[11:01:46 EST(-0500)] <colinclark> sorry
[11:01:55 EST(-0500)] <anastasiac> ok, right
[11:02:28 EST(-0500)] <colinclark> Bosmon: We'd actually need another name here for the creator function in this case.
[11:02:46 EST(-0500)] <colinclark> no, wait, now i'm being the idiot
[11:03:11 EST(-0500)] <fj4000> does anyone else think it odd that the UIOptions.html file contain all the js files for itself, as opposed to the host page containing those js files?
[11:03:32 EST(-0500)] <colinclark> fj4000: What host page?
[11:03:34 EST(-0500)] <colinclark>
[11:03:43 EST(-0500)] <fj4000> in my case, the sakai page
[11:03:56 EST(-0500)] <fj4000> shouldnt that page have all the js files? jquery and the like?
[11:04:20 EST(-0500)] <fj4000> and uioptions.html hold very little?
[11:04:43 EST(-0500)] <fj4000> *sorry - uioptions.html shouldnt include those files, right?
[11:05:21 EST(-0500)] <colinclark> fj4000: You're making a distinction that is slightly problematic, but understandable.
[11:05:29 EST(-0500)] <fj4000> thing is, Michelle said she could see a situation where its used standalone
[11:05:35 EST(-0500)] <colinclark> Right.
[11:05:39 EST(-0500)] <fj4000> whereas im using is as a peice of a bigger page
[11:05:45 EST(-0500)] <colinclark> I mean, you could make the same argument about any one of our template pages.
[11:05:52 EST(-0500)] <fj4000> thing is
[11:06:00 EST(-0500)] <fj4000> this is a MUCH biiger template
[11:06:15 EST(-0500)] <fj4000> sort of
[11:06:31 EST(-0500)] <colinclark> The point being that, today, we don't have a fully-prepped template renderer.
[11:06:39 EST(-0500)] <colinclark> This is exactly the case where it will help.
[11:06:52 EST(-0500)] <fj4000> so you think i should forget using an ajax call and just embed the template?
[11:08:31 EST(-0500)] <colinclark> fj4000: Here's what I did in the case the Uploader on the server.
[11:08:37 EST(-0500)] <colinclark> It wasn't ideal, but it made life a bit easier.
[11:08:45 EST(-0500)] <colinclark> Cutting and pasting markup really sucks horribly.
[11:08:59 EST(-0500)] <jessm> no cut n' paste!
[11:09:01 EST(-0500)] <colinclark> Back in the old days of the Uploader, we had three different HTML files, all with exactly the same markup.
[11:09:05 EST(-0500)] <colinclark> For roughly this reason.
[11:09:24 EST(-0500)] <colinclark> And we found that changes would get committed in one place, and people would naturally forget to do it in the other places.
[11:09:40 EST(-0500)] <colinclark> So, what I did with Uploader still sucked, but hopefully a bit less so.
[11:09:54 EST(-0500)] <colinclark> I loaded the contents of the template page via Ajax.
[11:10:07 EST(-0500)] <colinclark> So there was still a small amount of duplicated code: the JavaScript file imports in the head.
[11:10:22 EST(-0500)] <colinclark> But then at least I wasn't duplicating the markup wholesale.
[11:10:31 EST(-0500)] <colinclark> fj4000: Can you do that, perhaps?
[11:11:18 EST(-0500)] <colinclark> Again, all of this pain will go away when the renderer is done. There's still some work to be done in terms of determining how templates will be sourced, but it means you'll be able to easily ask for a particular component and have it rendered into your page without cutting and pasting all its markup.
[11:11:26 EST(-0500)] <Bosmon> We do so have a darn fully prepped renderer
[11:11:41 EST(-0500)] <colinclark> Not by my reckoning.
[11:11:48 EST(-0500)] <colinclark> It's a hot and very promising renderer.
[11:11:50 EST(-0500)] <fj4000> thats what im doing now
[11:11:54 EST(-0500)] <colinclark> But it's going to take a bit more time.
[11:12:00 EST(-0500)] <fj4000> ajax loading the body of the html file, not the head
[11:12:05 EST(-0500)] <fj4000> but for some reason
[11:12:20 EST(-0500)] <fj4000> there are 2 copies of most of the js files
[11:12:46 EST(-0500)] <fj4000> and I think it might be messing up the preview, i think
[11:13:02 EST(-0500)] <fj4000> or it could be something else im missing
[11:13:23 EST(-0500)] <colinclark> ?
[11:13:54 EST(-0500)] <colinclark> fj4000: If it helps any, I was using jQuery's very helpful .load() function.
[11:14:21 EST(-0500)] <colinclark> jQuery(elementToFill).load("url selector", ...);
[11:14:40 EST(-0500)] <fj4000> yes [11:14:43 EST(-0500)] <fj4000> ^ [11:14:57 EST(-0500)] <fj4000> i was already doing that to load a div [11:15:11 EST(-0500)] <fj4000> but i think it was firebug blinding me with science [11:15:24 EST(-0500)] <fj4000> its showing duplicates, but i dont think they're really there [11:15:56 EST(-0500)] <fj4000> since they're not loaded twice, just available in 2 different places in the script dropdown menu....argh!! [11:16:36 EST(-0500)] * fj4000 hating firebug these days...but is still in love it....but wants to kill it...with love [11:20:58 EST(-0500)] <fj4000> AHAH - I forgot to add the preview selector... [11:21:15 EST(-0500)] * fj4000 feeling so stupid.... [11:23:42 EST(-0500)] <colinclark> fj4000: You're not stupid. It happens to everyone! [11:29:20 EST(-0500)] * jessm routinely forgets the mute button [11:30:57 EST(-0500)] <fj4000> ok, so now FLUID-1875 should be good to go, Justin_o [11:31:07 EST(-0500)] <colinclark> Justin_o: How come my bug didn't get included in your "REVIEW" section in the bug parade? I feel left out. [11:31:20 EST(-0500)] <Justin_o> fj4000: thanks [11:31:32 EST(-0500)] <Justin_o> colinclark: sorry... oversite [11:31:41 EST(-0500)] <colinclark> Just teasing you. [11:31:52 EST(-0500)] <colinclark> I will ask Bosmon to review it, since it is a bit of a hairy fix. [11:31:57 EST(-0500)] <anastasiac> fj4000, I've been confused by the duplicate files in the firebug menu [11:32:06 EST(-0500)] <Justin_o> thanks [11:33:26 EST(-0500)] <Justin_o> colinclark: your patch uses the swf file in the flash folder? [11:34:00 EST(-0500)] <fj4000> anastasiac: yeah, it was redonkulous [11:34:21 EST(-0500)] <fj4000> i dont know why it feels the need to show me the same file in the same place in 2 different ways [11:36:24 EST(-0500)] <Justin_o> i'm updating the daily build site [11:36:46 EST(-0500)] <colinclark> fj4000: Ah! [11:36:58 EST(-0500)] <colinclark> You reminded me that this patch doesn't include the updated version of the .swf file. [11:39:17 EST(-0500)] * Bosmo1 (n=Antranig@ginger.caret.cam.ac.uk) has joined #fluid-work [11:40:27 EST(-0500)] <anastasiac> Bosmo1, question for you? [11:40:41 EST(-0500)] <Bosmo1> Hi, sorry [11:40:45 EST(-0500)] <Bosmo1> I got knocked off the net briefly [11:40:54 EST(-0500)] <fj4000> colinclark: ? [11:41:01 EST(-0500)] <anastasiac> the inline edit integrations, in the editModeRenderers, use that.options.TinyMCE and that.options.FCKEditor [11:41:14 EST(-0500)] <colinclark> fj4000: Shoot [11:41:23 EST(-0500)] <fj4000> your comment ^^ [11:41:26 EST(-0500)] <anastasiac> I'm not clear on what those refer to.. [11:43:26 EST(-0500)] <Bosmo1> Those are a set of "pass-through options" [11:43:33 EST(-0500)] <Bosmo1> You can see some of them in the default options set [11:43:54 EST(-0500)] <Bosmo1> But these are parcelled off unchanged (apart from merging) on to the "end component" in whatever proprietary way it accepts them [11:44:04 EST(-0500)] <Bosmo1> For example, FCKEditor accepts them, mysteriously, in two places [11:44:19 EST(-0500)] <colinclark> fj4000: Oh. Yes. My patch is slightly broken. [11:44:46 EST(-0500)] <anastasiac> ah, ok - so they're options for the actual third-party objects, not for us [11:44:58 EST(-0500)] <Bosmo1> yes [11:45:10 EST(-0500)] <anastasiac> no, I don't see any in the defaults [11:45:13 EST(-0500)] <Bosmo1> It means we can make each "instance" of the rich text control, or whatever, that we host, fully configurable [11:45:16 EST(-0500)] <anastasiac> am I missing somethign?? [11:45:22 EST(-0500)] <Bosmo1> Oh wait, they are not in the defaults, but in the manual tests file [11:45:42 EST(-0500)] <Bosmo1> Look at "richEditor2" for example [11:45:48 EST(-0500)] <anastasiac> ah! right, got it [11:45:51 EST(-0500)] <anastasiac> cool, thanks [11:45:54 EST(-0500)] <Bosmo1> It merges in a specific width directive, targetted at the downstream TinyMCE control [11:45:55 EST(-0500)] <anastasiac> much clearer now [11:47:23 EST(-0500)] * Justin_o (n=Justin@142.150.154.101) has left #fluid-work [11:51:18 EST(-0500)] * fj4000 (n=Main@CPE00095bc35ea1-CM001692f5798c.cpe.net.cable.rogers.com) has joined #fluid-work [11:53:25 EST(-0500)] <anastasiac> Bosmo1, Justin_o: I've finished the review and associated changes to FLUID-1944. [11:53:39 EST(-0500)] <anastasiac> It should undergo another review - Bosmo1, could you do that? [11:53:44 EST(-0500)] <Bosmo1> OK, cool [11:53:48 EST(-0500)] <Bosmo1> You want me to review your review? [11:53:56 EST(-0500)] <anastasiac> yes, please [11:54:09 EST(-0500)] <anastasiac> I've committed all the changes we've talked about [11:54:12 EST(-0500)] <colinclark> Bosmo1, anastasiac: So I just did some API "user testing." [11:54:13 EST(-0500)] <Bosmo1> OK, I will look [11:54:25 EST(-0500)] <colinclark> The results were unanimous. [11:54:32 EST(-0500)] <colinclark> Though you could argue with my Science. [11:54:42 EST(-0500)] <anastasiac> what was your n? [11:55:06 EST(-0500)] <Bosmo1> You mean, you asked some guys? [11:55:09 EST(-0500)] <colinclark> hahaha [11:55:15 EST(-0500)] <colinclark> That was my Science, yes. [11:55:33 EST(-0500)] <anastasiac> and what was the unanimous verdict? [11:55:56 EST(-0500)] <colinclark> I prefer to call it a Lightweight, Lowcost, Agile User Testing methodology recommended by Jared Spool (tm). [11:55:57 EST(-0500)] <colinclark> [11:56:03 EST(-0500)] <Bosmo1> SPOOL! [11:56:03 EST(-0500)] <colinclark> Hence it is Science. [11:56:27 EST(-0500)] * anastasiac is still waiting for the results [11:56:46 EST(-0500)] <colinclark> I am keeping you in suspense by making riveting and witty methodology jokes. [11:56:56 EST(-0500)] <Bosmo1> "I will not keep you in unnecessary suspense" [11:56:59 EST(-0500)] <colinclark> So, anastasiac are you curious about the results? [11:57:00 EST(-0500)] <anastasiac> oh, I didn't catch that [11:57:02 EST(-0500)] <Bosmo1> So it says in your Book of Etiquette [11:57:03 EST(-0500)] <colinclark> [11:57:14 EST(-0500)] <colinclark> damn [11:57:18 EST(-0500)] <colinclark> you guys are a tough crowd [11:57:38 EST(-0500)] <colinclark> I flew all the way here from Toronto, and, boy, are my arms tired. [11:57:59 EST(-0500)] <colinclark> Ok. [11:58:06 EST(-0500)] * anastasiac is surprisingly amused by that [11:58:23 EST(-0500)] <colinclark> Everyone felt that fluid.inlineEdit.tinyMCE() felt like a more natural instantiation, since it obviously conveys it as a "type" of inline editor. [11:58:27 EST(-0500)] <Bosmo1> KENT, you are a nitwit [11:58:34 EST(-0500)] <colinclark> [11:58:34 EST(-0500)] <jessm> lol [11:59:37 EST(-0500)] <colinclark> So anastasiac does this user research help you with your code? [11:59:51 EST(-0500)] <anastasiac> yes, thanks [11:59:59 EST(-0500)] <anastasiac> Bosmo1 is reviewing it now [12:00:03 EST(-0500)] <Bosmo1> Well, if we are going with this depth, we can certainly clean up this [12:00:04 EST(-0500)] <Bosmo1> fluid.inlineEdit.FCKEditor.inlineEditViewAccessor = function (editField) { [12:00:16 EST(-0500)] <anastasiac> ack! [12:00:20 EST(-0500)] <anastasiac> good catch, thanks [12:00:44 EST(-0500)] <colinclark> ok [12:00:47 EST(-0500)] * anastasiac loves pair programming [12:01:11 EST(-0500)] <colinclark> So Bosmo1, when you are done review the review, I'm wondering if you'd grace my patch with your reviewing prowess. [12:01:21 EST(-0500)] <colinclark> Except that I need to tweak it slightly, because it is broken. [12:01:35 EST(-0500)] <Bosmo1> ok [12:01:40 EST(-0500)] <Bosmo1> It will be a Graced Patch [12:01:56 EST(-0500)] * jessm (n=Jess@c-24-34-214-137.hsd1.ma.comcast.net) has joined #fluid-work [12:02:17 EST(-0500)] <anastasiac> Bosmo1, do you want to commit that fix, or shall I? [12:02:26 EST(-0500)] <Bosmo1> Well, why don't you [12:02:49 EST(-0500)] <anastasiac> was there anything else, or are you still looking? [12:03:13 EST(-0500)] <Bosmo1> fluid.inlineEdit.dropdown = function (container, options) { [12:03:14 EST(-0500)] <Bosmo1> return configureInlineEdit("fluid.inlineEdit.dropdown", container, options); [12:03:14 EST(-0500)] <Bosmo1> }; [12:03:21 EST(-0500)] <Bosmo1> We could now economise on all these functions [12:03:23 EST(-0500)] <Bosmo1> [12:03:44 EST(-0500)] <anastasiac> go on... [12:03:46 EST(-0500)] * Justin_o (n=Justin@142.150.154.101) has joined #fluid-work [12:03:49 EST(-0500)] <Bosmo1> Well, you know [12:03:51 EST(-0500)] <Bosmo1> The way JQuery does [12:03:55 EST(-0500)] <Bosmo1> They all do the same thing [12:04:31 EST(-0500)] <Bosmo1> We could just say, makeInlineEditConstructors("dropdown", "tinyMCE", "FCK") [12:04:32 EST(-0500)] <Bosmo1> [12:05:15 EST(-0500)] <anastasiac> I think there's economizing, and then there's economizing [12:06:35 EST(-0500)] <Bosmo1> Yes, maybe [12:06:45 EST(-0500)] <Bosmo1> We will wait for Renfro to criticise us [12:06:49 EST(-0500)] <Bosmo1> And then we will do it [12:08:16 EST(-0500)] <anastasiac> ok, I've committed the fix to the edit accessor name [12:08:41 EST(-0500)] <anastasiac> I think we're good to hand this one over to Justin_o - would you concur, Bosmo1? [12:08:59 EST(-0500)] <Bosmo1> Well, let me see if I can discover the missing TinyMCE icons first [12:09:05 EST(-0500)] <anastasiac> ah, right [12:09:47 EST(-0500)] <Bosmo1> You have not chosen the right name for these functions [12:09:54 EST(-0500)] <Bosmo1> You have left the "edit" of "inlineEdit" [12:10:07 EST(-0500)] <Bosmo1> Not noting that what they actually are are a "viewAccessor" [12:10:12 EST(-0500)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined #fluid-work [12:12:06 EST(-0500)] <anastasiac> ah - I looked at the defaults, and it says editAccessor: [12:12:09 EST(-0500)] <anastasiac> so... [12:12:12 EST(-0500)] <anastasiac> is that wrong? [12:12:48 EST(-0500)] <Bosmo1> Wel [12:12:54 EST(-0500)] <Bosmo1> It is a thing of type "viewAccessor" [12:13:00 EST(-0500)] <Bosmo1> The full name for it might be "editModeViewAccessor" [12:13:52 EST(-0500)] <anastasiac> so the 'view' here is view as in MVC view? [12:14:11 EST(-0500)] <Bosmo1> yes [12:14:25 EST(-0500)] <anastasiac> hm [12:14:31 EST(-0500)] * anastasiac ponders [12:15:14 EST(-0500)] <anastasiac> if someone has a GidgetRichTextEditor, and wants to plug it in, they're have to write their own edit mode view accessor function, right? [12:15:19 EST(-0500)] <Bosmo1> yes [12:15:29 EST(-0500)] * anastasiac continues to ponder [12:20:18 EST(-0500)] <anastasiac> ok, how about editViewAccessor? [12:20:30 EST(-0500)] <anastasiac> for the actual function, not the name of the option [12:25:01 EST(-0500)] <Bosmo1> What's wrong with "viewAccessor" [12:25:08 EST(-0500)] <Bosmo1> It is entirely unambiguous [12:25:16 EST(-0500)] <Bosmo1> Since you are dealing with something which is already implicitly an "editor" [12:25:23 EST(-0500)] <Bosmo1> It could only possible be referring to the bloody edit view! [12:25:24 EST(-0500)] <Bosmo1> [12:26:58 EST(-0500)] <Bosmo1> ok [12:27:04 EST(-0500)] <Bosmo1> I have located the elusive "icons"... [12:27:09 EST(-0500)] <Bosmo1> I do wonder how I managed to detacth them... [12:27:41 EST(-0500)] <Bosmo1> The "simple" configuration of TinyMCE is actually quite stylish [12:28:02 EST(-0500)] <Bosmo1> Seems to work fine in Opera now [12:28:37 EST(-0500)] <Justin_o> Bosmo1: that's good to hear [12:29:25 EST(-0500)] <anastasiac> doesn't the inline editor also have a display view? [12:29:53 EST(-0500)] <anastasiac> with its associated displayAccessor? [12:30:04 EST(-0500)] <Bosmo1> EricDalquist: Sorry to miss your age-old query [12:30:20 EST(-0500)] <Bosmo1> My first preference is for ISO-8601 dates [12:30:26 EST(-0500)] <Bosmo1> For which I have a little library, that almost works [12:30:27 EST(-0500)] <Bosmo1> [12:30:51 EST(-0500)] <Bosmo1> anastasiac: Yes, but those can never be specfic to a particular editor technology [12:31:23 EST(-0500)] <anastasiac> ok, yes, I can see that. I'm convinced [12:31:33 EST(-0500)] <anastasiac> sorry if I'm being difficult, it's just my nature [12:31:46 EST(-0500)] <Bosmo1> Yes, I'm sure it works well for you when you are carrying a sword [12:32:24 EST(-0500)] <anastasiac> or wearing boxing gloves [12:32:33 EST(-0500)] <Bosmo1> Yes [12:32:40 EST(-0500)] <Bosmo1> But this time, THE ADVANTAGE IS MINE [12:32:43 EST(-0500)] <Bosmo1> FOR YOU DO NOT HAVE A PLANE! [12:33:05 EST(-0500)] <anastasiac> LOL [12:33:44 EST(-0500)] <Bosmo1> Petro always flees when the Bullshot quotes start flying [12:33:55 EST(-0500)] <anastasiac> ah, but I'm deathless, which lends a certain advantage [12:34:31 EST(-0500)] <Bosmo1> Quite [12:34:45 EST(-0500)] <Bosmo1> You would probably survive an assault by a giant octopus [12:35:15 EST(-0500)] <Bosmo1> ICH BIN MIT PETRO NICHT VERMESSEN [12:36:29 EST(-0500)] <Bosmo1> As a side-note to all, in my refactoring I also removed our older, "DOM-based" implementation of the InlineEditor "isEditing" function [12:36:47 EST(-0500)] <Bosmo1> This is an example of the sort of thing of which these days we do "Not Approve" (TM) [12:36:53 EST(-0500)] <anastasiac> ok, I think FLUID-1944 is finally ready for final QA now that I've committed the fix to the viewAccessor name [12:37:03 EST(-0500)] <anastasiac> and Bosmo1 has restored the icons [12:37:13 EST(-0500)] <anastasiac> and yes, it looks much nicer now [12:37:24 EST(-0500)] <Bosmo1> It now has an implementation of this sort, based around a "micro-that" [12:37:31 EST(-0500)] <Bosmo1> var makeIsEditing = function (that) { [12:37:31 EST(-0500)] <Bosmo1> var isEditing = false; [12:37:31 EST(-0500)]