592797 - Sisyphus - Crash Automation - UI

Status: RESOLVED DUPLICATE of bug 661941

(Testing Graveyard :: Sisyphus, defect)

Description

[Bob Clary [:bc] (inactive)]

Attachment: work in process patch v1

This bug will track the UI work for bug hunter. Clint, I'd like to get this in and out of my patch queue but it is far from complete. Its pretty big, so I'm not sure you need to review the whole thing.

Comment 1

[cmtalbert]

Comment on attachment 471213 [details] [diff] [review]
work in process patch v1

Whew that's a lot of code.  Was there no other way to send the html other than doing the html.push(<tag>) stuff that you're doing?  It would seem more maintainable to have the html in separate files that are imported into here, but since I'm not real clear on whether or not you have file access apis in the scope that this javascript runs that may not actually be a viable option.  

Can you elaborate on how this part works?

Comment 2

[Bob Clary [:bc] (inactive)]

Since the list functions are server side, I can use couchapp to include js and html and do make some use of that in the code.

Some of the original list functions used the older couchapp template stuff, but I found that to be very awkward and difficult to maintain since the list function had pieces of html scattered around in the templates directories. The templates didn't support conditional processing which was necessary to share between the crashes, assertions and valgrind messages. The newer couchapp mustache templates do (I think) support some conditional processing but I just couldn't grok them and found the basic html buffer stuff easier to implement and understand.

I'm not sure which part you want to know about but the html.push stuff basically uses an array to collect html fragments server side which are then joined together and sent to the browser. The array of fragments, join thing is pretty efficient compared to concatenating the html as a simple string. I'm not sure about mustache templating but the original templating did a global search and replace on the template to substitute the template variables with their values. That can be pretty performance intensive to have to search the template string and perform a global regexp replace for each template variable for each row. I think some of the performance improvement we've seen in the UI is due to the elimination of this regexp replace stuff.

Comment 3

[cmtalbert]

(In reply to comment #2)
> Since the list functions are server side, I can use couchapp to include js and
> html and do make some use of that in the code.
> 
> Some of the original list functions used the older couchapp template stuff, but
> I found that to be very awkward and difficult to maintain since the list
> function had pieces of html scattered around in the templates directories. The
> templates didn't support conditional processing which was necessary to share
> between the crashes, assertions and valgrind messages. The newer couchapp
> mustache templates do (I think) support some conditional processing but I just
> couldn't grok them and found the basic html buffer stuff easier to implement
> and understand.
> 
> I'm not sure which part you want to know about but the html.push stuff
> basically uses an array to collect html fragments server side which are then
> joined together and sent to the browser. The array of fragments, join thing is
> pretty efficient compared to concatenating the html as a simple string. I'm not
> sure about mustache templating but the original templating did a global search
> and replace on the template to substitute the template variables with their
> values. That can be pretty performance intensive to have to search the template
> string and perform a global regexp replace for each template variable for each
> row. I think some of the performance improvement we've seen in the UI is due to
> the elimination of this regexp replace stuff.
Huh, cool.  That makes sense.  I didn't think about the downstream effects of templetizing the html.  At first glance that seems easier to manage, but I agree that this approach does have the added benefit of putting everything in one place.  Cool, thanks for the info.

Comment 4

[Bob Clary [:bc] (inactive)]

http://hg.mozilla.org/automation/sisyphus/rev/76fddbbb8a9a

more to come.

Comment 5

[Bob Clary [:bc] (inactive)]

moving all work over to mcôté