fluid-work IRC Logs-2013-09-23

[10:00:56 CDT(-0500)] <jessm> for a very meaningful use of eyebrows see: https://plus.google.com/photos/108097314255204250860/albums/5925096771476242417/5925096929167161874?banner=pwa&amp;authkey=CKaRh67H09zE5QE&amp;pid=5925096929167161874&amp;oid=108097314255204250860

[10:01:01 CDT(-0500)] <jessm> yay yzen!

[11:08:45 CDT(-0500)] <jhung> cindyli or Justin_o: can either of you check out my GPII-193 and see if vjoanna finds it a good solution for the hit area issue for the panel bar? https://github.com/jhung/prefsEditors/tree/GPII-193

[11:09:58 CDT(-0500)] <Justin_o> jhung: i can take a look

[11:13:30 CDT(-0500)] <Justin_o> jhung: is the head supposed to point down on hover?

[11:13:45 CDT(-0500)] <Justin_o> icon beside "doesn't make sense"

[11:14:23 CDT(-0500)] <jhung> Yes. It's supposed to rotate. vjonna can let me know if it's rotating the right way and if it's rotating enough or too much.

[11:14:28 CDT(-0500)] <jhung> ^Justin_o

[11:18:39 CDT(-0500)] <Justin_o> jhung: just showed vjoanna.. so generally looks good.. the border shouldn't show up on hover though.. and it seems that there is either a bottom border or something causing a line to show between the panel bar and the rest of the panel which shouldn't be there

[11:19:06 CDT(-0500)] <jhung> So the outline should go? Justin_o?

[11:19:23 CDT(-0500)] <Justin_o> jhung: yes

[11:19:41 CDT(-0500)] <vjoanna> orange outline just on focus state, not on hover

[11:20:23 CDT(-0500)] <jhung> Ok. I'll switch that to focus. Also please see contrast modes and see if it's acceptable vjoanna.

[11:28:40 CDT(-0500)] <vjoanna> jhung: contrast modes look good to me

[11:29:11 CDT(-0500)] <jhung> Thanks vjoanna! I'll fix that focus/hover style now.

[11:29:32 CDT(-0500)] <vjoanna> thank you!

[13:13:49 CDT(-0500)] <jessm> hey everyone: gmail is down

[13:13:52 CDT(-0500)] <jessm> DO NOT PANIC

[13:14:04 CDT(-0500)] <jessm> http://downrightnow.com/gmail

[13:36:02 CDT(-0500)] <Bosmon2> jessm - My suspicion is that it is in fact "downrightnow.com" which is down, rather than gmail itself : P

[13:36:34 CDT(-0500)] <jessm> i have confirmed reports of gmail in fact being down

[13:36:53 CDT(-0500)] <Bosmon2> But somehow it is not down for me ....

[13:36:59 CDT(-0500)] <jessm> http://thenextweb.com/google/2013/09/23/having-problems-with-gmail-today-dont-worry-its-not-just-you/

[13:37:04 CDT(-0500)] <jessm> spotty downage

[13:37:06 CDT(-0500)] <Bosmon2> Very strange

[13:37:14 CDT(-0500)] <jessm> http://www.google.com/appsstatus#hl=en&amp;v=issue&amp;ts=1379977199000&amp;sid=1&amp;iid=043f082bc7cd18e15458318035d9bc7a

[13:37:29 CDT(-0500)] <jessm> grammar error in the announcement

[13:37:41 CDT(-0500)] <jessm> "The email delays are affecting less than 50% of Gmail users."

[13:37:45 CDT(-0500)] <Justin_o> Bosmon2: hello.. you have some time to chat?

[13:38:36 CDT(-0500)] <Bosmon2> Justin_o - yes, I was expecting to chat with you : P

[13:38:46 CDT(-0500)] <Bosmon2> let me just give THER CATT his *CATT FFOOD* .....

[13:39:01 CDT(-0500)] <Justin_o> Bosmon2: okay.. i'll start typing in here while you do that

[13:39:46 CDT(-0500)] <Bosmon2> I did read your report from Friday, but needed some more details on your plan in order to understand it

[13:40:29 CDT(-0500)] <Justin_o> Bosmon2: thanks for looking it over.. i have something in the branch now, so that might help.

[13:40:31 CDT(-0500)] <Justin_o> https://github.com/jobara/infusion/blob/FLUID-5131/src/components/uiOptions/js/Panels.js

[13:40:46 CDT(-0500)] <Justin_o> more specifically

[13:40:52 CDT(-0500)] <Justin_o> https://github.com/jobara/infusion/blob/FLUID-5131/src/components/uiOptions/js/Panels.js#L97-L116

[13:41:10 CDT(-0500)] <Justin_o> so what i'd like to do is be able to use an expander to create the distributeOptions block

[13:42:03 CDT(-0500)] <Justin_o> the reason why is that i want to the combinedPanel to be able to automatically generate this itself, and it won't really know ahead of time what the sub panels all are.

[13:42:41 CDT(-0500)] <Justin_o> in my case i'm trying to distribute a gradeName that will have all of the settings needed.

[13:42:48 CDT(-0500)] <Bosmon> Justin_o - I think this issue is the reason that you would need to build a "grade-combining grade"

[13:43:08 CDT(-0500)] <Bosmon> But I guess another thing I meant by this at the time, was that you would write a grade which takes more of the approach similar to the "AuxBuilder"

[13:43:24 CDT(-0500)] <Bosmon> In that it violates our normal recommendation on not issuing a grade description dynamically

[13:43:31 CDT(-0500)] <Justin_o> Bosmon: the auxiliary builder actually creates the entire components block

[13:43:34 CDT(-0500)] <Bosmon> This is one of those situations where I think you can't really get away with it

[13:43:39 CDT(-0500)] <Bosmon> Justin_o - yes

[13:43:41 CDT(-0500)] <Justin_o>

[13:43:47 CDT(-0500)] <Bosmon> Or rather, "you can't get away without it"

[13:43:59 CDT(-0500)] <Justin_o> Bosmon: so we need to have another type of schema ?

[13:44:08 CDT(-0500)] <Bosmon> There is too much dynamism in the component to be able to expect to be able to issue its defaults block statically

[13:44:19 CDT(-0500)] <Bosmon> Justin_o - you ALREADY have the schema, luckily : P

[13:44:30 CDT(-0500)] <Justin_o> Bosmon: but it won't work for people who don't have the schema

[13:44:33 CDT(-0500)] <Bosmon> All the information you need can be discovered from i) the preferencesMap, and ii) the existing defaults block

[13:44:38 CDT(-0500)] <Justin_o> there will be a lot for them to do manually

[13:44:43 CDT(-0500)] <Bosmon> Justin_o ^

[13:45:03 CDT(-0500)] <Justin_o> Bosmon: that parts okay.. the problem is knowing which panels are the subpanels

[13:45:30 CDT(-0500)] <Justin_o> Bosmon: it would have been nice to have just been able to use the components block in the options..

[13:45:33 CDT(-0500)] <Bosmon> Justin_o - that can also be discovered from those sources

[13:45:37 CDT(-0500)] <Justin_o> it seems strange to have to have a different method

[13:45:47 CDT(-0500)] <Justin_o> Bosmon: how is that?

[13:46:02 CDT(-0500)] <Bosmon> By, as you say, inspecting the components block

[13:46:41 CDT(-0500)] <Bosmon> Actually, you CAN achieve the effect you want from your commented-out block right now

[13:46:48 CDT(-0500)] <Justin_o> Bosmon: really

[13:46:50 CDT(-0500)] <Justin_o> ?

[13:46:54 CDT(-0500)] <Justin_o> what am i missing?

[13:46:55 CDT(-0500)] <Bosmon> All you need to do is issue a dynamic grade, which adds an extra supergrade to the current component

[13:47:03 CDT(-0500)] <Bosmon> Which contains the distributeOptions block you need

[13:47:44 CDT(-0500)] <Justin_o> Bosmon: hmmm.. but i would still need a way to generate that distributeOptions blcok

[13:47:47 CDT(-0500)] <Justin_o> block

[13:47:53 CDT(-0500)] <Bosmon> Justin_o - sure, but you needed one anyway : P

[13:48:06 CDT(-0500)] <Justin_o> Bosmon: yes.. i just don't know how to do that still

[13:48:11 CDT(-0500)] <Bosmon> And as your expander shows, you already know that the information you need to generate it can be derived from the "components" block of this component

[13:48:16 CDT(-0500)] <Bosmon> Which can be discovered by inspecting its defaults

[13:48:42 CDT(-0500)]

[13:48:53 CDT(-0500)] <Bosmon> It's clear you were aware this is where the information you required was : P

[13:49:10 CDT(-0500)] <Justin_o> Bosmon: yes.. that parts okay.. i just don't know how to do the actually creation of the distributeOptions block.. since it can't take an expander

[13:50:27 CDT(-0500)] <Bosmon> Justin_o - probably best to write a function which creates a wholly new grade, and then returns the name of that grade

[13:50:42 CDT(-0500)] <Bosmon> I know this is something we don't normally recommend, but it is probably the best way out of this current situation

[13:50:59 CDT(-0500)] <Justin_o> Bosmon: okay.. and in this function i'll just create a simple json structure that gets passed into the call to fluid.defaults of the new grade

[13:51:08 CDT(-0500)] <Justin_o> Bosmon: okay

[13:51:54 CDT(-0500)] <Bosmon> This will all be "temporary infrastructure" in any case, since all of this requirement will go away once we have the "new renderer"

[13:51:55 CDT(-0500)] <Justin_o> Bosmon: i also had a question about the combining of templates

[13:52:08 CDT(-0500)] <Justin_o> Bosmon: yeah !!!

[13:52:14 CDT(-0500)] <Bosmon> But your implementation will be useful as a study for what the "new renderer" will need to do

[13:52:26 CDT(-0500)] <Justin_o> Bosmon: looking forward to having the declarative change applier listeners soon too

[13:52:45 CDT(-0500)] <Bosmon> Justin_o - that is now simply a matter of REVIEW : P

[13:53:18 CDT(-0500)] <Justin_o> Bosmon: yes.. i was taking a peek at your pull request this morning.. the syntax looked good

[13:54:34 CDT(-0500)] <Bosmon> I am now working at the next level of insanity - which is assimmillating the MODEL RELAY system

[13:54:45 CDT(-0500)] <Bosmon> For which cindyli's implementation in UIO is a helpful guide

[13:55:24 CDT(-0500)] <Bosmon> Unfortunately this will create a huge amount of disruption since it involves going back on an assumption we made almost on day 1 in Fluid... that the "model" reference of a component is stable

[13:55:52 CDT(-0500)] <Justin_o> Bosmon: so i was talking with cindyli a bit about the template combining stuff.. so the integrator will need to supply a template template which defines how all the templates for the sub panels are arranged.. as well as anything else that needs to be rendered for the parent panel.. the question for me is how to get those other templates into this.. i could just dump the resourceText into a jQuery and use that to insert the other pieces at

[13:55:52 CDT(-0500)] <Bosmon> My plan is to create a new base grade, "modelRelayComponent" that has the new semantic, and we will have to vet all of our components in Fluid 1 by 1 to make them ready for the new model

[13:55:53 CDT(-0500)] <Justin_o> the proper locations and get the html back out to put in the resourceText field.. or perhaps there is a better way.

[13:56:17 CDT(-0500)] <Bosmon> Justin_o - it would be very helpful to avoid round-tripping the template through the document

[13:56:26 CDT(-0500)] <Justin_o> Bosmon: sounds interesting.. is this going to be a 2.0 thing then

[13:56:28 CDT(-0500)] <Justin_o> ?

[13:56:38 CDT(-0500)] <Bosmon> There is still a "back door" in RendererComponent that accepts a "function returning some text" in the role of a template

[13:56:58 CDT(-0500)] <Justin_o> Bosmon: interesting.. how does that work?

[13:57:04 CDT(-0500)] <Bosmon> So I suggest you try to use this to see if it is good enough for you

[13:57:46 CDT(-0500)] <Bosmon> Justin_o - the option "templateSource"

[13:58:06 CDT(-0500)] <Justin_o> Bosmon: anyways.. i didn't mean to put it in the DOM exactly just to wrap the text in a jQuery.. like $("<div>…</div>)

[13:58:23 CDT(-0500)] <Bosmon> You might notice the following very dubious section in RendererUtilities.js

[13:58:24 CDT(-0500)] <Bosmon> if (typeof(source) === "function") { // TODO: make a better attempt than this at asynchrony

[13:58:24 CDT(-0500)] <Bosmon> source = source();

[13:58:24 CDT(-0500)] <Bosmon> }

[13:58:30 CDT(-0500)] <Bosmon> About line 102

[13:58:43 CDT(-0500)] <Bosmon> Justin_o - that will still unavoidably create DOM material for the template

[13:58:50 CDT(-0500)] <Bosmon> Even if it isn't put into the document's DOM

[13:59:01 CDT(-0500)] <Bosmon> You should really make sure you manipulate the templates as text until the final moment

[13:59:06 CDT(-0500)] <Justin_o> Bosmon: okay.. looking at your code above.. i remember that spot now

[13:59:34 CDT(-0500)] <Justin_o> Bosmon: so i'll have to do some string operations to combine the templates together from the various resourceText fields

[13:59:35 CDT(-0500)] <Bosmon> Given you are generating your own grade, to be honest, I'm not sure that this will be helpful

[13:59:37 CDT(-0500)] <Justin_o> does that sound about right?

[13:59:39 CDT(-0500)] <Bosmon> Justin_o - that's correct

[14:00:05 CDT(-0500)] <Bosmon> Unfortunately as the comment suggests, the implementation there doesn't really help you with the asynchrony angle

[14:00:26 CDT(-0500)] <Bosmon> You will still need to make sure that "somehow this has already been achieved" before the time anyone calls the "render" function

[14:00:47 CDT(-0500)] <Bosmon> And given you have achieved it, the fact that you can call a function to return the result doesn't really help you very much with the important problem : P

[14:01:21 CDT(-0500)] <Bosmon> So you may as well just stick the whole template itself into templateSource after all

[14:01:46 CDT(-0500)] <Bosmon> Until we have the "asynchronous ginger world", this kind of problem is going to keep recurring

[14:12:31 CDT(-0500)] <Justin_o> Bosmon: okay.. so i'll do that.. i'll just rewrite the resourceText for the template to include the sub panels templates as well

[14:12:45 CDT(-0500)] <Bosmon> Justin_o - cool!

[14:12:48 CDT(-0500)] <Bosmon> Should be interesting

[14:13:01 CDT(-0500)] <Justin_o> Bosmon: at the moment none of the panels are able to fetch there own templates anyways.. so this should be right in line with that

[14:13:16 CDT(-0500)] <Bosmon> Justin_o - yes

[14:13:22 CDT(-0500)] <Justin_o> Bosmon: hopefully.. we'll see how my string hacking skills go

[14:13:26 CDT(-0500)] <Bosmon> In theory you might use the renderer itself for this task

[14:14:03 CDT(-0500)] <Bosmon> Thankfully since we abolished the "rsf:id" system there is now no longer a difference in form between a renderer template and its rendered result

[14:14:07 CDT(-0500)] <Justin_o> Bosmon: interesting are there public functions i can borrow for that.. or will i need to make a call to the renderer itself and get it dump out the text

[14:14:19 CDT(-0500)] <Bosmon> And so fewer obstacles to creating a "renderer template-renderer"

[14:14:35 CDT(-0500)] <Bosmon> Justin_o - In theory all you would need is a use of the "UIVerbatim" component type

[14:15:05 CDT(-0500)] <Justin_o> Bosmon: which would return the markup to me as a string right?

[14:15:11 CDT(-0500)] <Bosmon> This has a member named "markup" holding the already-rendered markup

[14:15:16 CDT(-0500)] <Bosmon> Justin_o - the other way round

[14:15:21 CDT(-0500)] <Bosmon> You SUPPLY the markup as a string

[14:15:48 CDT(-0500)] <Bosmon> But the overall renderer action returns the markup as a string too, yes

[14:16:24 CDT(-0500)] <Bosmon> But you would do this as a "private" invocation of the renderer, rather than through using RendererComponent which isn't set up to put the markup anywhere but in the DOM

[14:17:35 CDT(-0500)] <Justin_o> Bosmon: so i could just make a call to fluid.renderer itself?

[14:17:40 CDT(-0500)] <Bosmon> Justin_o - yes

[14:18:02 CDT(-0500)] <Bosmon> On the other hand, you may decide that this is too much trouble, and just operate a giant instance of fluid.stringTemplate instead : P

[14:18:45 CDT(-0500)] <Bosmon> I guess this would still require you to somehow "parse" the outer template and then discover where all the "holes" are

[14:18:54 CDT(-0500)] <Bosmon> And so is not really advisable

[14:19:57 CDT(-0500)] <Bosmon> All the same, the kind of component tree you'll need to make this work will be something we have not seen for many moons

[14:20:22 CDT(-0500)] <Justin_o> Bosmon: i guess the integrator could supply a markup block in the options that contains the string template tokens which would correspond to templates, but i'll try to use the renderer first

[14:20:26 CDT(-0500)] <Bosmon> Something involving both UIJointContainer and UIVerbatim

[14:20:36 CDT(-0500)] <Justin_o> Bosmon: time to dig through the docs i guess

[14:20:49 CDT(-0500)] <Bosmon> The member "jointID" in a component is what signals to the renderer to make a jump from one template to another

[14:21:36 CDT(-0500)] <Bosmon> So the component tree for this rendering involves i) 1 UIJointContainer, with ii) a UIVerbatim inside it, for every subtemplate

[14:23:21 CDT(-0500)] <Bosmon> Justin_o - the only usage I can find of jointID in the whole image is in the manual tests

[14:23:26 CDT(-0500)] <Bosmon> "renderer-component-types.html"

[14:23:39 CDT(-0500)] <Bosmon> I guess we have anastasiac to thank for this, since without this we would have no examples at all : P

[14:24:05 CDT(-0500)] <Bosmon> Ironic that 5 years had to elapse before we had a use case for this

[14:24:14 CDT(-0500)] <Bosmon> When we were just on the point of abolishing the renderer anyway

[14:24:57 CDT(-0500)] <Justin_o> Bosmon: that is funny actually, you were very forward thinking

[14:25:05 CDT(-0500)] <Justin_o> Bosmon: i guess these are the docs http://wiki.fluidproject.org/display/Infusion13/Renderer+Component+Types

[14:25:09 CDT(-0500)] <Justin_o> and i'll take a look at that example

[14:26:05 CDT(-0500)] <Bosmon> Justin_o - actually in the "RSF Renderer" from which this was taken, this component was much more frequently used

[14:26:35 CDT(-0500)] <Bosmon> Since the system typically had to create the entire markup for a page in one pass on the server ...

[14:27:01 CDT(-0500)] <Bosmon> Given we never yet sorted out our infrastructure on the client for allowing one rendererComponent to be nested inside another, this component was hugely less useful

[14:27:26 CDT(-0500)] <Bosmon> But given you are now mocking up this infrastructure yourself with your "grade-combining grade", the use case for UIJointContainer reappears ahead of time

[14:27:37 CDT(-0500)] <Bosmon> But thankfully the "new renderer" will be free of such monstrosities

[14:28:39 CDT(-0500)] <Bosmon> The "joint" infrastructure will be moved inside the IoC system itself where the user won't be constantly stubbing their toe on it

[14:29:43 CDT(-0500)] <Justin_o> Bosmon: looking forward to the new system.. i guess it's a ways off, but things in general keep getting better everyday

[14:30:21 CDT(-0500)] <Bosmon> Yes

[14:30:35 CDT(-0500)] <Bosmon> We should have a meeting about the "new model infrastructure" soon, since it will involve big changes for all of us

[14:31:14 CDT(-0500)] <Bosmon> The central issue is that model references will no longer be shared i) between different components, and ii) between the users of components and the components

[14:32:13 CDT(-0500)] <Bosmon> And it will become possible for the model reference of a component to become "undefined"

[14:32:30 CDT(-0500)] <Bosmon> BIG CHANGES are afoot!

[14:32:37 CDT(-0500)] <Justin_o> Bosmon: whoa.. that's different.. did you want to have this talk before or after the 1.5 release?

[14:32:48 CDT(-0500)] <Bosmon> Justin_o - I guess it can happen concurrently or whenever

[14:32:58 CDT(-0500)] <Bosmon> You will need to "opt in" to the new system by using the new grade of "modelRelayComponent"

[14:33:07 CDT(-0500)] <Bosmon> So it shouldn't bother anyone who doesn't want to opt in to it

[14:33:11 CDT(-0500)] <Justin_o> Bosmon: ah okay..

[14:33:24 CDT(-0500)] <Bosmon> But for 2.0 this grade will become simply renamed to "modelComponent" and we will abolish the old one

[14:33:28 CDT(-0500)] <Justin_o> Bosmon: is there enough for a whole community meeting for this topic?

[14:33:55 CDT(-0500)] <Bosmon> Probably, yes

[14:34:16 CDT(-0500)] <Justin_o> Bosmon: did you want to lead one on Oct 9 for this topic?

[14:34:36 CDT(-0500)] <Bosmon> I guess that's conceivable, yes

[14:34:50 CDT(-0500)] <Bosmon> I should have something implemented by then

[14:36:13 CDT(-0500)] <Justin_o> Bosmon: cool.. i'll book one for then.. if you can't let me know and we can change it

[14:36:39 CDT(-0500)] <Bosmon> Justin_o - cool

[14:36:59 CDT(-0500)] <Justin_o> Bosmon: http://wiki.fluidproject.org/display/fluid/Community+workshops

[14:37:06 CDT(-0500)] <Bosmon> This will enable us to do a number of helpful things, for example not having to wrap every component's value in some stupid name such as "value"

[14:37:18 CDT(-0500)] <Bosmon> We realised we had to do this very early on, when InlineEdit was designed

[14:37:31 CDT(-0500)] <Bosmon> But it was an inevitable consequence of the "shared model reference" model we had started with

[14:38:06 CDT(-0500)] <Bosmon> And of course we continue to find ourselves doing this in situations such as UIOptions' panels etc.

[14:38:15 CDT(-0500)] <Justin_o> Bosmon: i have to run now, thanks for the chat.. i think i have enough to keep me going on FLUID-5131

[14:38:19 CDT(-0500)] <Justin_o> Bosmon: yes. that's true

[14:38:22 CDT(-0500)] <Bosmon> Justin_o - cool!

[14:38:23 CDT(-0500)] <Bosmon> Good luck

[14:38:24 CDT(-0500)] <Justin_o> we have a lot of those

[14:38:30 CDT(-0500)] <Justin_o> Bosmon: thanks