fluid-work IRC Logs-2012-07-24

Owned by Fluid IRC Log Bot
Last updated: Jul 24, 2012Version comment
19 min read

[08:52:34 CDT(-0500)] <Justin_o> anastasiac: do you know if you use a guard to validate changes to an autobound input field, can i get it to revert the inputed value back if the guard prevents the change?

[08:54:08 CDT(-0500)] <anastasiac> Justin_o, I believe a guard guards the model, so it would prevent changes to the model. But I'm not sure what would happen to the content of the input field if the change failed… that's a good question

[08:55:22 CDT(-0500)] <Justin_o> anastasiac: okay.. thanks.. so far i'm not seeing it change, but wasn't sure if that was expected or if i was doing something wrong

[08:55:48 CDT(-0500)] <anastasiac> Justin_o, I'm not entirely surprised that the filed is not affected. I suppose that's not really the guard's job

[08:56:40 CDT(-0500)] <Justin_o> anastasiac: okay.. do you know if there are any events fired or anything if it fails.. or is that something i'll have to manage myself?

[08:57:06 CDT(-0500)] <anastasiac> hm

[08:58:27 CDT(-0500)] <anastasiac> Justin_o, I don't think so, but there's no reason you couldn't define your own event, and have your guard file it if the validation failes

[09:00:57 CDT(-0500)] <Justin_o> anastasiac: okay thanks.. seems reasonable

[10:13:01 CDT(-0500)] * Topic is 'This channel is logged – for details see: http://wiki.fluidproject.org/display/fluid/IRC+Channel' set by jessm on 07:30:00 CST(-0600)

[10:19:37 CDT(-0500)] <alexn> Bosmon2: ayt ?

[13:03:56 CDT(-0500)] <Bosmon2> Hi there alexn1

[13:04:36 CDT(-0500)] <Bosmon2> michelled tells me that there are remaining issues with the IE9 rendering issue with CSPACE-5387?

[13:05:07 CDT(-0500)] <Bosmon2> You sent a mail on the 12th saying that JURA's approach seemed to be working?

[13:05:54 CDT(-0500)] <alexn1> Bosmon2: well Yura gave some suggestions and his way kinda gives some results although I was unable to setup a proper template using a produceTree

[13:06:07 CDT(-0500)] <alexn1> the thing that the issue still remains

[13:06:27 CDT(-0500)] <alexn1> if the AutoBind is been used in that particular case of a cspace component

[13:07:00 CDT(-0500)] <alexn1> and I thought that we would be able to fix the code with any major changes but taking a closer look at why the template is broken for IE9

[13:07:59 CDT(-0500)] <alexn1> (smile)

[13:08:05 CDT(-0500)] <Bosmon2> Could you express the issue more clearly? (smile)

[13:08:20 CDT(-0500)] <Bosmon2> I mean, I think it is reasonably obvious why the template breaks... and it is because of the Pager's use of "selfRender"

[13:08:43 CDT(-0500)] <Bosmon2> So the strategy was to use JURA's "hot patch" in order to remove this last use of selfRender for this use of the pager, in favour of setting up a genuine template that did not pass through the document

[13:08:59 CDT(-0500)] <Bosmon2> The autobind issue sounds like it is a completely separate issue, but perhaps you could say more about this problem?

[13:09:07 CDT(-0500)] <Bosmon2> Is it just an API issue with dealing with the renderer?

[13:09:24 CDT(-0500)] <alexn1> well I assumed that it is an autoBind issue since JURA's patch is a removal an autobind property

[13:09:39 CDT(-0500)] <alexn1> for the pager

[13:10:08 CDT(-0500)] <Bosmon2> !!!

[13:10:13 CDT(-0500)] <Bosmon2> Are we looking at the same patch?

[13:10:59 CDT(-0500)] <alexn1> to be sure that we are looking at the same patch I will resend you an email which Yura sent few days ago about this problem

[13:11:01 CDT(-0500)] <Bosmon2> Can you give me a link to the one you are looking at?

[13:11:26 CDT(-0500)] <Bosmon2> Thanks

[13:11:58 CDT(-0500)] <Bosmon2> I see the mail he sent

[13:12:03 CDT(-0500)] <Bosmon2> Which contains a link to this diff:

[13:12:03 CDT(-0500)] <Bosmon2> https://github.com/collectionspace/ui/blob/master/src/main/webapp/defaults/js/SearchToRelateDialog.js#L78-82

[13:12:10 CDT(-0500)] <Bosmon2> This looks like the appropriate thing to do

[13:12:17 CDT(-0500)] <Bosmon2> Which is to explicitly supply a template in the options

[13:12:27 CDT(-0500)] <Bosmon2> Which makes use of the "hot patch" he has already issued to CSpace's copy of Infusion

[13:13:05 CDT(-0500)] <alexn1> well I tried that but not sure what to do from here, since the template differs significantly depending on who instantiates pager

[13:13:29 CDT(-0500)] <alexn1> there are multiple places to display rows of data consisting of different columns and it varies from case to case

[13:13:42 CDT(-0500)] <Bosmon2> I see

[13:13:43 CDT(-0500)] <alexn1> passing one template will cause in loss of data in some cases

[13:13:48 CDT(-0500)] <Bosmon2> Who is responsible for writing this template right now?

[13:13:54 CDT(-0500)] <Bosmon2> That is, whose markup does it appear as part of....

[13:14:19 CDT(-0500)] <alexn1> let me double check this

[13:14:57 CDT(-0500)] <alexn1> I think it is a listView in different places

[13:15:06 CDT(-0500)] <Bosmon2> Yes

[13:15:06 CDT(-0500)] <alexn1> for example there is a listView in admin

[13:15:13 CDT(-0500)] <alexn1> or there is a listView in recordEditor

[13:15:21 CDT(-0500)] <Bosmon2> But in this sense, it is no different to the searchToRelate dialog which he shows as the successful case

[13:16:01 CDT(-0500)] <alexn1> well SearchTo Relate dialog utilizes the same set of columns all the time

[13:16:09 CDT(-0500)] <alexn1> therefore the template has those columns

[13:16:13 CDT(-0500)] <Bosmon2> ok

[13:16:18 CDT(-0500)] <alexn1> in case of pager, columns vary from place to place

[13:17:08 CDT(-0500)] <Bosmon2> I'm actually a bit puzzled at how he gets away with using such a huge template in searchToRelate.....

[13:17:31 CDT(-0500)] <alexn1> to be honest I'm a bit puzzled by the most code source (smile)

[13:17:52 CDT(-0500)] <alexn1> what is the template name ?

[13:18:00 CDT(-0500)] <Bosmon2> searchToRelate.html

[13:18:16 CDT(-0500)] <alexn1> thx!

[13:18:18 CDT(-0500)] <Bosmon2> I am starting to have an uneasy feeling that he is somehow abusing the fact that the pager still uses old-fashioned templates using rsf:id values

[13:18:32 CDT(-0500)] <Bosmon2> Since this is really a template for the entire dialog, not just the pager portion

[13:18:52 CDT(-0500)] <alexn1> you see the part

[13:18:52 CDT(-0500)] <alexn1> <td rsf:id="summary"></td>

[13:18:52 CDT(-0500)] <alexn1> <td rsf:id="recordtype"></td>

[13:18:52 CDT(-0500)] <alexn1> <td rsf:id="summarylist.updatedAt"></td>

[13:18:56 CDT(-0500)] <Bosmon2> But buried in amongst it are templated elements for "header:" and "row:"

[13:19:09 CDT(-0500)] <Bosmon2> Yes

[13:19:13 CDT(-0500)] <Bosmon2> It is all packed with rsf:ids

[13:19:23 CDT(-0500)] <Bosmon2> So I wonder whether this template is somehow used TWICE

[13:19:31 CDT(-0500)] <Bosmon2> Once for the dialog, and once for the pager within it

[13:19:41 CDT(-0500)] <alexn1> those <td> and <th> tags have all those ids hardocded. I cannot do the same thing with Pager in ListView

[13:19:54 CDT(-0500)] <alexn1> and not sure how to make it work (sad)

[13:19:58 CDT(-0500)] <Bosmon2> Well, you can do it

[13:20:04 CDT(-0500)] <Bosmon2> But you just need to be able to figure out how to deliver the right template

[13:20:19 CDT(-0500)] <Bosmon2> Where are these ListViews currently used from?

[13:21:30 CDT(-0500)] <alexn1> from my search I see that they are used from: Admin.js, RelatedRecordsList.js and RelatedRecordsTab.js

[13:21:53 CDT(-0500)] <alexn1> but in some cases as RelatedRecordsList there multiple of those with different set of columns

[13:22:01 CDT(-0500)] <alexn1> hence different templates should be used

[13:22:39 CDT(-0500)] <Bosmon2> Ok - where are the current templates for these views?

[13:22:53 CDT(-0500)] <Bosmon2> I looked in RelatedRecordListTemplate.html but saw no pager template there

[13:22:56 CDT(-0500)] <alexn1> well the main template is ListViewTemplate

[13:23:01 CDT(-0500)] <Bosmon2> aha

[13:23:05 CDT(-0500)] <alexn1> and it is been inserted everywhere I think

[13:23:48 CDT(-0500)] <alexn1> Before I tried to insert columns into this pager template and it would work… but only for few cases since some of those listViews use different columns

[13:24:46 CDT(-0500)] <alexn1> https://github.com/anvk/ui/tree/CSPACE-5387

[13:24:57 CDT(-0500)] <alexn1> this was an attempt to do this

[13:25:05 CDT(-0500)] <alexn1> you can see it in my second last commit

[13:25:07 CDT(-0500)] <Bosmon2> bugger it.... my version of the master branch doesn't agree with the real one

[13:25:10 CDT(-0500)] <Bosmon2> Give me a few seconds...

[13:25:17 CDT(-0500)] <alexn1> https://github.com/anvk/ui/commit/a008b249a42fbd68ee0aaec6e1a85869f47ef9ed

[13:25:22 CDT(-0500)] <Bosmon2> I guess JURA at some point "de-black-lined" the master branch...

[13:28:08 CDT(-0500)] <Bosmon2> ok

[13:28:11 CDT(-0500)] <Bosmon2> I've got the listview template up

[13:28:19 CDT(-0500)] <Bosmon2> it seems to be mysteriously devoid of rsf:ids

[13:28:36 CDT(-0500)] <Bosmon2> And also... any columns

[13:28:37 CDT(-0500)] <Bosmon2> So!

[13:28:40 CDT(-0500)] <Bosmon2> Where do the columns come from?

[13:29:04 CDT(-0500)] <alexn1> let me find this for you

[13:29:12 CDT(-0500)] <alexn1> they are scattered

[13:29:54 CDT(-0500)] <alexn1> Demand.js - line 1334

[13:30:01 CDT(-0500)] <alexn1> line 702

[13:30:23 CDT(-0500)] <alexn1> I'm pretty sure I saw few other places

[13:30:27 CDT(-0500)] <Bosmon2> Well ok

[13:30:31 CDT(-0500)] <Bosmon2> But where does the markup for them come from?

[13:30:33 CDT(-0500)] <alexn1> SideBar.js line 143

[13:31:19 CDT(-0500)] <alexn1> from my understanding ListView.js line 595 till the end

[13:31:44 CDT(-0500)] <Bosmon2> That's still just the component tree

[13:31:45 CDT(-0500)] <alexn1> I might be wrong but columns and headers components would somehow repeat and bind data

[13:31:47 CDT(-0500)] <Bosmon2> Where is the actual markup?

[13:31:59 CDT(-0500)] <alexn1> well before it was AutoBind

[13:32:03 CDT(-0500)] <alexn1> so not really sure

[13:32:17 CDT(-0500)] <Bosmon2> Oh I see... this is the markup

[13:32:23 CDT(-0500)] <Bosmon2> Well, this seems fine

[13:32:30 CDT(-0500)] <Bosmon2> You don't need to deliver a different template at all

[13:32:32 CDT(-0500)] <alexn1> if you make Yura's change then it would be using something what I tried to do before https://github.com/anvk/ui/commit/a008b249a42fbd68ee0aaec6e1a85869f47ef9ed

[13:32:43 CDT(-0500)] <Bosmon2> ListViewTemplate.html genuinely contains the correct template for every use of the ListView

[13:33:12 CDT(-0500)] <Bosmon2> Yes, you don't need to do what you did there

[13:33:20 CDT(-0500)] <alexn1> sounds good

[13:33:36 CDT(-0500)] <alexn1> sounds like a good start (smile)

[13:33:50 CDT(-0500)]

<Bosmon2> Just start with this line for now: template: "

Unknown macro: {cspace.listView}

.options.resources.template.resourceText"

[13:33:58 CDT(-0500)] <Bosmon2> This should be pretty much all you need

[13:34:10 CDT(-0500)] <Bosmon2> I don't know why your diff removed the bodyRenderer type field

[13:34:26 CDT(-0500)] <Bosmon2> Just do what JURA did in the searchToRelate and it should mostly work

[13:34:27 CDT(-0500)] <alexn1> oh it added later in the next commit I think

[13:34:33 CDT(-0500)] <Bosmon2> plus or minus dealing with autobind

[13:34:40 CDT(-0500)] <alexn1> I think I tried

[13:34:46 CDT(-0500)] <Bosmon2> Well, try again (smile)

[13:34:49 CDT(-0500)] <Bosmon2> And see what you observe....

[13:34:49 CDT(-0500)] <alexn1> but it would complain that resources is not found

[13:34:54 CDT(-0500)] <alexn1> ok will do

[13:35:01 CDT(-0500)] <Bosmon2> Well, perhaps you need to load it

[13:35:29 CDT(-0500)] <Bosmon2> It does seem to be loaded correctly

[13:35:41 CDT(-0500)] <Bosmon2> In the category of "fastTemplates", in ListView.js line 156

[13:37:24 CDT(-0500)] <alexn1> I'm not seeing me removing bodyRenderer...

[13:37:34 CDT(-0500)] <alexn1> just on a side note :S

[13:37:39 CDT(-0500)] <Bosmon2> It's in that diff you pasted

[13:37:53 CDT(-0500)] <Bosmon2> On line 123, you removed the type field

[13:38:19 CDT(-0500)] <alexn1> type: "fluid.pager.selfRender" ?

[13:38:33 CDT(-0500)] <Bosmon2> yes, that

[13:39:09 CDT(-0500)] <alexn1> oh I was following Yura's instructions he sent in email

[13:39:15 CDT(-0500)] <alexn1> https://github.com/collectionspace/ui/blob/master/src/main/webapp/defaults/js/SearchToRelateDialog.js#L78-82

[13:39:20 CDT(-0500)] <alexn1> this block does not have type either

[13:39:35 CDT(-0500)] <alexn1> one mystery after another (smile)

[13:39:57 CDT(-0500)] <Bosmon2> Oh, I see

[13:40:01 CDT(-0500)] <Bosmon2> It's probably just the default

[13:41:07 CDT(-0500)] <alexn1> so I tried and I observer the same thing when I tried to play around those code changes Yura suggested. The lists do not render

[13:41:13 CDT(-0500)] <alexn1> there are no rows

[13:41:33 CDT(-0500)] <Bosmon2> Does the column render?

[13:41:40 CDT(-0500)] <Bosmon2> Also, does the template appear to have text in it?

[13:42:06 CDT(-0500)] <alexn1> http://pastie.org/4325636

[13:42:37 CDT(-0500)] <alexn1> here is how template looks when it is rendered

[13:42:49 CDT(-0500)] <alexn1> so in the end there is one header and one columns with not content

[13:42:53 CDT(-0500)] <alexn1> *no content

[13:43:50 CDT(-0500)] <alexn1> I think that <a> wraping is a part of another functionality which is been executed right after the rendering is done

[13:43:51 CDT(-0500)] <Bosmon2> Ok

[13:44:08 CDT(-0500)] <Bosmon2> It appears that the header hasn't rendered at all - since it just consists of the template material copied out

[13:44:09 CDT(-0500)] <alexn1> it would go through every row and wrap it into anchor tag to be clickable

[13:44:37 CDT(-0500)] <Bosmon2> Ok

[13:44:46 CDT(-0500)] <Bosmon2> So that markup manipulation is not done by the renderer

[13:44:51 CDT(-0500)] <Bosmon2> So, it appears that there has been no rendering

[13:46:17 CDT(-0500)] <alexn1> I'm not quiet sure how to proceed from here

[13:48:23 CDT(-0500)] <Bosmon2> I'm not actually seeing yura's "hot patch" in the CSpaceInfusion file

[13:48:33 CDT(-0500)] <Bosmon2> Could it be that he never committed it to trunk?

[13:48:39 CDT(-0500)] <Bosmon2> At least, it is not in v2.5

[13:48:43 CDT(-0500)] <Bosmon2> I will check master...

[13:48:56 CDT(-0500)] <alexn1> 2.5 should be === master

[13:49:15 CDT(-0500)] <alexn1> master.equal(2.5) === true

[13:49:29 CDT(-0500)] <Bosmon2> Ok

[13:49:30 CDT(-0500)] <Bosmon2> I see it now

[13:49:35 CDT(-0500)] <Bosmon2> I was looking at the wrong copy of the source

[13:49:42 CDT(-0500)] <Bosmon2> So, you should have a look in there to see what is going on during the rendering

[13:50:00 CDT(-0500)] <alexn1> where is it, Antranig ?

[13:50:07 CDT(-0500)] <Bosmon2> The relevant point is around line 16924 of CSpaceInfusion.js

[13:50:16 CDT(-0500)] <Bosmon2> His patch occupies the next 4 lines

[13:50:28 CDT(-0500)] <Bosmon2> But setting a breakpoint just before there should allow you to see what the inputs are to the rendering process

[13:51:28 CDT(-0500)] <Bosmon2> Although the actual rendering happens on line 26956

[13:51:36 CDT(-0500)] <Bosmon2> Sorry, I gave the wrong line number before

[13:51:39 CDT(-0500)] <Bosmon2> I meant to say 26924

[13:51:59 CDT(-0500)] <Bosmon2> But setting a breakpoint on line 26956 should be a good start

[13:52:01 CDT(-0500)] <Bosmon2> This line: fluid.reRender(template, root, fullTree, options.renderOptions);

[13:52:08 CDT(-0500)] <Bosmon2> You should be able to see everything that's going on there

[13:53:42 CDT(-0500)] <Bosmon2> This produceTree method seems to involve terrible abuse of the renderer (sad)

[13:53:45 CDT(-0500)] <Bosmon2> In ListView...

[13:55:20 CDT(-0500)] <alexn1> *looking at the code and trying to grasp on what is going on

[13:56:03 CDT(-0500)] <Bosmon2> Oh crikey (sad)

[13:56:04 CDT(-0500)] <Bosmon2> I see it now

[13:56:14 CDT(-0500)] <Bosmon2> He has dedicated renderer components for rendering the columns and headers

[13:56:43 CDT(-0500)] <Bosmon2> We are doomed

[13:56:53 CDT(-0500)] <alexn1> I do not have much of infusion expereince but I thought that expanders should be used instead

[13:57:03 CDT(-0500)] <Bosmon2> Yes

[13:57:06 CDT(-0500)] <Bosmon2> That would have been preferable

[13:57:09 CDT(-0500)] <Bosmon2> Although very messy

[13:57:18 CDT(-0500)] <Bosmon2> At least it would have meant that we were not doomed (smile)

[13:57:25 CDT(-0500)] <alexn1> can I ask a question ? (smile)

[13:57:33 CDT(-0500)] <Bosmon2> Sure, go ahead : P

[13:57:44 CDT(-0500)] <alexn1> just out of curiosity - what do you you think about moustache/handlebar templating ?

[13:57:48 CDT(-0500)] <alexn1> (smile)

[13:57:57 CDT(-0500)] <Bosmon2> I think it is awful

[13:58:01 CDT(-0500)] <Bosmon2> Because it is not HTML (smile)

[13:58:26 CDT(-0500)] <alexn1> what about dom-templating ?

[13:58:29 CDT(-0500)] <alexn1> (smile)

[13:58:37 CDT(-0500)] <alexn1> like batman.js or angular.js

[13:58:41 CDT(-0500)] <alexn1> just curious

[13:58:55 CDT(-0500)] <Bosmon2> I haven't actually seen another pure HTML templating engine other than ours

[13:59:24 CDT(-0500)] <alexn1> well angular and batman use attributes in html templates

[13:59:39 CDT(-0500)] <alexn1> or as angular - sometimes creating custom html tags

[13:59:53 CDT(-0500)] <Bosmon2> Yes - this renders the templates impure, given that the templates now have a binding onto the model layer of the application

[14:00:12 CDT(-0500)] <Bosmon2> It implies that a designer then needs to have domain-level knowledge

[14:01:02 CDT(-0500)] <Bosmon2> And yes, both of those involve creating strange new attribute or tag types that are meaningless within HTML

[14:01:03 CDT(-0500)] <alexn1> designers who create websites?

[14:01:08 CDT(-0500)] <Bosmon2> Which means that normal HTML design tools are not usable

[14:01:10 CDT(-0500)] <Bosmon2> Yes, those

[14:01:29 CDT(-0500)] <alexn1> I see (smile)

[14:01:33 CDT(-0500)] <Bosmon2> Of course, the fact that all existing normal HTML design tools are actually rubbish is a completely separate issue (smile)

[14:02:11 CDT(-0500)] <alexn1> so what should we do about this pager problem (sad)

[14:02:29 CDT(-0500)] <Bosmon2> Anyway, these were the original design goals behind the creation of the Fluid renderer.... I think it will be still quite a long-term task to deliver on them, even from here

[14:02:52 CDT(-0500)] <alexn1> to be honest - I wish we had dedicated resource for the framework

[14:03:04 CDT(-0500)] <Bosmon2> Yes well, the pager problem is quite awkward.... I guess the first thing is to remind ourselves exactly where the failure occurs

[14:03:07 CDT(-0500)] <Bosmon2> Well, we will have a bit soon

[14:03:18 CDT(-0500)] <Bosmon2> colinclark has promised me I can spend the majority of the remainder of the year working on it (smile)

[14:04:21 CDT(-0500)] <alexn1> that would be amazing. If we could improve builder and make documentation somewhat "sexy"

[14:04:38 CDT(-0500)] <alexn1> (smile)

[14:04:55 CDT(-0500)] <Bosmon2> I actually have IE8 here

[14:05:03 CDT(-0500)] <Bosmon2> Which is awkward

[14:05:31 CDT(-0500)] <alexn1> *confused. how ie8 comes here in play ?

[14:05:39 CDT(-0500)] <Bosmon2> Well, to see if I can reproduce the issue

[14:05:43 CDT(-0500)] <Bosmon2> But I assume I can't do it in IE8

[14:06:29 CDT(-0500)] <Bosmon2> Depending on exactly where the issue occurs, it might actually be the shortest path for me to patch the issue in the renderer

[14:06:34 CDT(-0500)] <alexn1> well it is reproducible in IE9 for sure. by cspace folks, mine and michelle's vm

[14:06:45 CDT(-0500)] <Bosmon2> Since that will probably be less work than rewriting all of JURA's peculiar rendererComponent hierarchy

[14:06:53 CDT(-0500)] <alexn1> I'm afraid so

[14:07:06 CDT(-0500)] <alexn1> (sad) that is why I thought that would be the easy way

[14:07:08 CDT(-0500)] <Bosmon2> So, let me have a look at your IE-DEATH branch

[14:07:41 CDT(-0500)] <Bosmon2> You don't happen to have a place where you took a record of the exact stack trace where the problem occurs?

[14:08:05 CDT(-0500)] <alexn1> sorry I'm not quiet following you

[14:08:36 CDT(-0500)] <alexn1> basically if you checkout the death branch and then follow instructions of the last commit

[14:08:49 CDT(-0500)] <alexn1> it will be the minimal amount of files involved in reproducing the bug

[14:08:51 CDT(-0500)] <alexn1> in IE9

[14:09:06 CDT(-0500)] <alexn1> it is using a testfile for the listView

[14:09:11 CDT(-0500)] <Bosmon2> Yes

[14:09:24 CDT(-0500)] <Bosmon2> But presumably there is a JS error at a particular stack

[14:09:36 CDT(-0500)] <Bosmon2> I notice your comment on CSPACE-5387 implicates line 16228 of CSpaceInfusion.js

[14:09:38 CDT(-0500)] <Bosmon2> Is this still corrrect?

[14:09:40 CDT(-0500)] <alexn1> yes

[14:09:44 CDT(-0500)] <alexn1> it is still correct

[14:09:48 CDT(-0500)] <Bosmon2> ok, cool

[14:09:50 CDT(-0500)] <alexn1> you can put a breakpoint there

[14:09:58 CDT(-0500)] <alexn1> and it will stop there right before failing

[14:10:01 CDT(-0500)] <alexn1> with all the info

[14:10:03 CDT(-0500)] <Bosmon2> Well, I can once I get IE9 working (smile)

[14:10:17 CDT(-0500)] <Bosmon2> Unfortunately my machine is out of desktop heap space again..... due to some new Chrome bug I guess

[14:10:18 CDT(-0500)] <alexn1> a reason to update browser (wink)

[14:10:55 CDT(-0500)] <Bosmon2> I prefer not to install updates from Microsoft (smile)

[14:10:56 CDT(-0500)] <alexn1> it is interesting enough to see that the developers I saw at the Throne.JS conference are mostly using Chrome dev tools instead of the FireBug

[14:11:06 CDT(-0500)] <Bosmon2> In this way I can keep my system running for a long time.......

[14:11:21 CDT(-0500)] <alexn1> yes yes. updates from Microsoft are like mandatory malwares you have to install

[14:11:33 CDT(-0500)] <Bosmon2> I still hugely prefer the UI on Firebug.... even though there are numerous and new powerful features in Chrome dev

[14:12:23 CDT(-0500)] <alexn1> I was thinking to give Chrome a shot since the memory leak in FireBug drives me and my computer memory crazy lately

[14:12:38 CDT(-0500)] <Bosmon2> They got bad again?

[14:13:01 CDT(-0500)] <Bosmon2> They had a good release of alpha 10 earlier in the year, I remember

[14:13:05 CDT(-0500)] <Bosmon2> Which seemed to make a lot of them go away

[14:13:26 CDT(-0500)] <alexn1> well my FireBug eaily reaches 2Gb instead of 300 in half an hour. It seems like it is never enough for this FireBug

[14:13:31 CDT(-0500)] <alexn1> I would call it MemoryBug instead

[14:13:36 CDT(-0500)] <Bosmon2> Astounding

[14:13:48 CDT(-0500)] <alexn1> I meant 300Mb -> 2Gb

[14:13:51 CDT(-0500)] <alexn1> (smile)

[14:14:40 CDT(-0500)] <Bosmon2> Blast it

[14:14:46 CDT(-0500)] <Bosmon2> Desktop heap crashed eclipse

[14:14:49 CDT(-0500)] <Bosmon2> I may as well reboot

[14:14:52 CDT(-0500)] <Bosmon2> I'll be back in a few minutes....

[14:15:03 CDT(-0500)] <alexn1> windows reinstall ?

[14:15:04 CDT(-0500)] <alexn1> (smile)

[14:15:10 CDT(-0500)] <Bosmon2> Won't help

[14:15:20 CDT(-0500)] <Bosmon2> I think the latest Chrome has become much more aggressive about GDI handles

[14:15:22 CDT(-0500)] <alexn1> sudo windows re-install ?

[14:15:41 CDT(-0500)] <Bosmon2> I had already hacked the registry to the maximum desktop heap size recommended by MS...

[14:15:47 CDT(-0500)] <Bosmon2> But it looks like I will have to take it a bit higher

[14:16:15 CDT(-0500)] <alexn1> now I know the true meaning of the phrase "always aim higher"

[14:16:25 CDT(-0500)] <Bosmon2> Each Chrome process is using at least 500 handles

[14:16:30 CDT(-0500)] <Bosmon2> And I have several dozen of them

[14:16:42 CDT(-0500)] <Bosmon2> ok, back soon....

[14:16:47 CDT(-0500)] <alexn1> ok ttys

[14:38:48 CDT(-0500)] <Bosmon> Ok.... the good news is that my machine still seems stable with double the recommended amount of desktop heap....

[14:44:56 CDT(-0500)] <Bosmon> The less good news is that I am having trouble reproducing the error on IE9

[14:45:10 CDT(-0500)] <Bosmon> For a start, there seem to be lots of stray commas on CSpaceTests.js that stops the file even from loading

[14:45:55 CDT(-0500)] <alexn1> Bosmon: give me few minutes.

[14:46:25 CDT(-0500)] <Bosmon> After I get rid of that, I find that I am getting an empty template sent to parseTemplates

[14:48:29 CDT(-0500)] <Bosmon> Looks like you are not waiting for I/O completion before trying to instantiate the listView component

[14:53:58 CDT(-0500)] <alexn1> back

[14:54:04 CDT(-0500)] <alexn1> sorry I was talking to Justin

[14:54:37 CDT(-0500)] <alexn1> so did you manage to reproduce it? Should I launch my VM

[14:54:42 CDT(-0500)] <alexn1> to do it in parallel with you ?

[14:54:46 CDT(-0500)] <alexn1> Bosmon: (smile)

[14:56:50 CDT(-0500)] <Bosmon> Ok

[14:56:56 CDT(-0500)] <Bosmon> I have fixed it up so I can reproduce the error

[14:57:46 CDT(-0500)] <Bosmon> But the error is actually in the pager code

[14:57:50 CDT(-0500)] <Bosmon> Not in Yura's rendering code

[14:58:19 CDT(-0500)] <alexn1> well the rendering will fail because of the not closed <td> tag

[14:58:28 CDT(-0500)] <alexn1> which would cause the wrong nesting

[14:58:35 CDT(-0500)] <alexn1> so far from what the error would say

[14:59:01 CDT(-0500)] <alexn1> and the funny thing that Mozilla would get a properly closed <td> tag at the same place if you put a breakpoint

[14:59:07 CDT(-0500)] <alexn1> as I described in the JIRA

[14:59:11 CDT(-0500)] <Bosmon> Yes

[14:59:15 CDT(-0500)] <Bosmon> This issue is well-understood

[14:59:40 CDT(-0500)] <Bosmon> Anyway, so in your test case you are not actually trying the fix for avoiding selfRendering

[14:59:48 CDT(-0500)] <Bosmon> Not to say that the error may not continue to occur even if we do that

[14:59:51 CDT(-0500)] <Bosmon> But we should at least try

[15:00:38 CDT(-0500)] <alexn1> the test case was only for error reproducing since I did not know how to approach the problem in order to fix it

[15:12:20 CDT(-0500)] <Bosmon2> Hi alexn1

[15:12:28 CDT(-0500)] <alexn1> Bosmon2: (smile)

[15:12:28 CDT(-0500)] <Bosmon2> I have pushed an updated version of your test code to https://github.com/amb26/ui/tree/alexey-death

[15:12:47 CDT(-0500)] <alexn1> I do not think I can approve the branch name

[15:13:10 CDT(-0500)] <Bosmon2> So could you work on it a bit, to i) correctly stub out the DataSource as is done in the real test cases, so we can see the complete render cycle ii) turn this into a proper test case which actually issues a test fixture

[15:13:18 CDT(-0500)] <Bosmon2> Feel free to rename the branch (smile)

[15:15:30 CDT(-0500)] <alexn1> so it was a combination of AutoBind with a template which fixed it?

[15:18:25 CDT(-0500)] <Bosmon2> Well, I don't know about autobind.... can we actually just use JURA's original test?

[15:18:29 CDT(-0500)] <Bosmon2> Did that fail too originally?

[15:20:02 CDT(-0500)] <alexn1> yeah it did

[15:20:10 CDT(-0500)] <alexn1> while trying to read some json file I think

[15:20:19 CDT(-0500)] <alexn1> but Mozilla would always surpass the rendering point

[15:20:23 CDT(-0500)] <alexn1> while IE would fail there

[15:20:42 CDT(-0500)] <alexn1> sorry Antranig I'm confused… this branch you sent me… what does it have ?

[15:37:30 CDT(-0500)] <alexn1> Bosmon2: what are out next steps? you want me to look why the test fails ?

[15:37:37 CDT(-0500)] <alexn1> *our

[15:38:54 CDT(-0500)] <Bosmon2> it contains a test case that we need to fix up

[15:39:03 CDT(-0500)] <Bosmon2> Right now I am going back to the original test case to see whether it passes

[15:39:25 CDT(-0500)] <Bosmon2> Right now it behaves a little oddly in that it does actually pass on FF, but as soon as I put the template in, it stops rendering the body correctly

[15:39:39 CDT(-0500)] <Bosmon2> Whereas on IE it fails though a different cause, somehow its request for the page data fails before that

[15:41:01 CDT(-0500)] <Bosmon2> Ah, I guess the test case is only set up to work correctly via a file URL

[15:41:09 CDT(-0500)] <alexn1> yes

[15:41:19 CDT(-0500)] <alexn1> ugh didn't I mention this ?

[15:41:31 CDT(-0500)] <alexn1> I might forgot mentioning that all test files are opened only locally

[15:41:34 CDT(-0500)] <alexn1> from the filesystem

[15:41:40 CDT(-0500)] <Bosmon2> Well, it is a bug (smile)

[15:41:44 CDT(-0500)] <Bosmon2> They should know whether they are test cases or not

[15:41:53 CDT(-0500)] <Bosmon2> They shouldn't rely on the URL to work that out....

[15:42:08 CDT(-0500)] <alexn1> well I saw them like this from the day 1

[15:42:16 CDT(-0500)] <Bosmon2> I am referring to the material in CSpaceTest.js which presumably inspects the document's own URL

[15:42:16 CDT(-0500)] <alexn1> (smile)

[15:42:36 CDT(-0500)] <Bosmon2> Well, you should take care to confiscate JURA's whisky as soon as he returns home (smile)

[15:46:55 CDT(-0500)] <anastasiac> michelled, my FLOE-42 branch is ready for review: https://github.com/acheetham/OER-Commons/tree/FLOE-42

[15:48:17 CDT(-0500)] <michelled> thx anastasiac

[15:52:10 CDT(-0500)] <Bosmon2> So yes, it seems that JURA's abuse of the renderer in using it to render renderer templates will make it impossible to use the approach we were wanting

[15:52:35 CDT(-0500)] <Bosmon2> His entire infrastructure for this component naturally depends on roundtripping the markup through the document

[15:53:21 CDT(-0500)] <alexn1> what would we do then ?

[15:53:50 CDT(-0500)] <alexn1> Bosmon2: *trying to look at few jiras simultaneously

[15:56:38 CDT(-0500)] <Bosmon2> Well, I'm not sure

[15:56:48 CDT(-0500)] <Bosmon2> I'm inclined to tip it over to him to fix this mess (smile)

[15:56:53 CDT(-0500)] <Bosmon2> When is he expected back?

[15:57:47 CDT(-0500)] <alexn1> Aug 31

[15:57:48 CDT(-0500)] <alexn1> (sad)

[15:58:07 CDT(-0500)] <Bosmon2> Out of interest, how did the CSpace 2.5 release proceed without a fix for this issue?

[15:58:23 CDT(-0500)] <alexn1> pretty quiet

[15:58:33 CDT(-0500)] <alexn1> people are more crazy about other small problems and issues

[15:58:42 CDT(-0500)] <alexn1> which I'm trying to look at in the meantime

[15:58:57 CDT(-0500)] <alexn1> there are couple and folks are more aggressive about them

[15:59:07 CDT(-0500)] <alexn1> but then they told me to focus on everything except of IE issue

[15:59:14 CDT(-0500)] <alexn1> so I cannot say for sure if it bothers them or not

[15:59:20 CDT(-0500)] <Bosmon2> ok

[16:00:26 CDT(-0500)] <Bosmon2> I'm also intrigued by the use of the call "Date.today()" in ListView.js line 318

[16:00:34 CDT(-0500)] <Bosmon2> Which as far as I can see is not a valid part of the JS APIs

[16:01:01 CDT(-0500)] <alexn1> well cspace is a place where all impossible becomes possible (wink)

[16:01:11 CDT(-0500)] <Bosmon2> So it would seem

[16:01:15 CDT(-0500)] <alexn1> (big grin)

[16:01:48 CDT(-0500)] <Bosmon2> Oh... perhaps this is a result of that abusive date parsing library which we use, which corrupts the date prototype

[16:02:04 CDT(-0500)] <Bosmon2> Unfortunately we are not including it in the test case, so it fails if any message is displayed

[16:05:58 CDT(-0500)] <alexn1> sorry Bosmon2 I have to leave now. Shoot me an email If I can be of any help and I will try to do that in parallel with other JIRAs I'm working with. hope you will come up with more ideas we could possibly try