jQuery uses getAllResponseHeaders function for getting response headers,
even for getResponseHeader. As far as I know, there is no easy way to
get original xhr object and call getResponseHeader on such object.
Because of that getResponseHeader is broken on firefox with CORS.
I rewrote Travis.ajax to use XMLHttpRequest directly in order to fix
this, the compatibility with jQuery.ajax is mostly handled.
CORS specification specifies "simple request", which does not need a
preflight OPTIONS request. The only thing, which we send and is
forbidding to send simple requests is Authorization header, which is not
needed for public endpoints.
* insert available items at once
* allow to use pushObject on buffer itself
* add a test using arrayObserver to make sure that it fires only when
elements are added to arrangedContent
Browsers disable local storage and session storage when cookies are
disabled - any call to one of those will cause an error. This commit
provides fallback storage, which will store items in memory.
We change ansi terminal instructions into HTML tags before splitting the
log into lines, which sometimes may end up with </span> in the beginning
of the line. This is a quick hack to fix that problem, but we need
better solution.
Till now, log viewer was rendered in handlebars, which was the simplest
solution, but it had a major drawback - every append to log caused it to
rerender which was not efficient and memory consuming.
The new approach is to make Travis.Log interpret the log and send lines
with instructions to the view, so for example if view should add a line,
it gets something like:
{ number: 1, content: '$ bundle install' }
Such approach is required to handle cases where data coming from pusher
is not actually a new line. For example output containing dots from
tests needs to be appended:
$ rake
....
Such output could be sent to client in 2 chunks: "$ rake\n.." and "..".
In such situation we would need to send 3 instructions:
{ number: 1, content: '$ rake' }
{ number: 2, content: '..' }
{ number: 2, content: '..', append: true }
The third instruction can come much later, because tests can take a
while to run, so we can't assume that each line will come in one piece.
The other scenario is \r, for example when showing progress:
\rDownloading: 10%
\rDownloading: 50%
\rDownloading: 100%
Such input should be changed into such instructions:
{ number: 1, content: 'Downloading: 10%' }
{ number: 1, content: 'Downloading: 50%', replace: true }
{ number: 1, content: 'Downloading: 100%', replace: true }
Travis.Log also supports folds, for example on bundle install, the code
was rewritten to make folds management simpler.
When using get with path (eg. get('foo.bar.baz')), get method is called
only on the current object and computed property will be called. Because
there is no easy way to overwrite the computed property, I moved
incomplete record loading to ember-data. It's not DRY and it should be
rewritten, but I don't want to do it at this point as we will need to
completely rewrite it when upgrading ember-data.
While testing in the wild I spotted a few problems with it:
* it didn't work for camel case names.
* it was sometimes setting loaded data too late - it needed to use find
and then save data on the record. Instead it should save data in
special array saved on store, indexed by clientId
* there is already method to get attributes in ember-data, it just
doesn't work with Travis.Foo.get('attributes'), it needs
Ember.get(Travis.Foo, 'attributes') - it makes implementation much
shorter
In order to minimize ajax requests, I implemented isComplete property,
which can be used to check if record is fetched from the API or if it
was just partially loaded (for example by pusher event). This is nice in
terms of requests reduction, but caries risk of showing incomplete data.
This commit fixes this situation by saving which attributes were
provided on "incomplete" load and triggering refresh when any unknown
attribute is tried to be fetched.
The implementation is really simple and will probably need refactoring,
but I would like to test it in the wild before putting much more time
into it.
When we get payload from pusher, we usually don't send the entire
record. Initially such records where fetched from server right away to
get missing data. This was done becuase Ember can't tell if given data
is complete or not and just assumes that the record is loaded.
To not fire unneeded request, this code sets incomplete flag on records
loaded from pusher and loads the rest of the data only if needed.
This is working implementation of links on log line numbers. Although it
does the job, it's really hacky and involves overriding some of the
ember's methods (resolvePath, routeMatcher) beacuse currently
HistoryLocation can't handle hash additions in an easy way.
This code should be fixed as soon as ember's router gets more powerful
and gives much more granular control over matching routes.