fluid-work IRC Logs-2012-07-24
[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>
[13:08:05 CDT(-0500)] <Bosmon2> Could you express the issue more clearly?
[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
[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
[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
[13:33:50 CDT(-0500)]
<Bosmon2> Just start with this line for now: template: "
.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
[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
[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
[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
[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
[13:57:25 CDT(-0500)] <alexn1> can I ask a question ?
[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>
[13:57:57 CDT(-0500)] <Bosmon2> I think it is awful
[13:58:01 CDT(-0500)] <Bosmon2> Because it is not HTML
[13:58:26 CDT(-0500)] <alexn1> what about dom-templating ?
[13:58:29 CDT(-0500)] <alexn1>
[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
[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
[14:02:11 CDT(-0500)] <alexn1> so what should we do about this pager problem
[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
[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>
[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> 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
[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
[14:10:55 CDT(-0500)] <Bosmon2> I prefer not to install updates from Microsoft
[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>
[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>
[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:
[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:
[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
[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 ?