Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Render the console inside the body tag #162

Merged
merged 1 commit into from Sep 9, 2015

Conversation

gsamokovarov
Copy link
Collaborator

Before this commit, the console was rendered straight after the closing

tag, which made the page HTML invalid. However, browsers are used to be molested and they are really good at displaying whatever you throw at them, so that wasn't big problem anyway. Still it was something that bug me quite a bit. I'm trying to redeem myself here.

Because I had to change the newly introduced WebConsole::Response class
I had cleaned the workspace a bit:

  • WebConsole::Response no longer depends on a logger. The detection
    should be better now, so we don't need to couple the query check in
    it.
  • WebConsole::Response does one thing only. It used to check the
    acceptance of a given Content-Type. I moved this to the middleware
    class.
  • I have reverted the WebConsole::WhinyRequest to keep the logging out
    of the logic in the request class. We no longer need to log in two
    separate classes, so no need to break Liskov or introduce logging
    into simple query methods.

@sh19910711 do you wanna review this?

@rails-bot
Copy link

@gsamokovarov: no appropriate reviewer found, use r? to override

# possible.
#
# The object quacks like Rack::Response.
class Response < Struct.new(:body, :status, :headers)
# Returns whether the response is from an acceptable content type.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Need to remove this comment?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@sh19910711
Copy link

@sh19910711 do you wanna review this?

Yeah, I will do.

@gsamokovarov
Copy link
Collaborator Author

@sh19910711 I've updated the PR.

assert_select 'body > #console'
end

test '#acceptable_content_type? is truthy if response format is HTML' do

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This test case seems to be doing the same thing as the above one (test 'render console inside the body tag'). We can merge them into one, perhaps.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yup.

@sh19910711
Copy link

The code seems good to me.

WebConsole::Response does one thing only.

I like that 👍

Before this commit, the console was rendered straight after the closing
</html> tag, which made the page HTML invalid. However, browsers are
used to be molested and they are really good at displaying whatever you
throw at them, so that wasn't big problem anyway. Still it was something
that bug me quite a bit. I'm trying to redeem myself here.

Because I had to change the newly introduce `WebConsole::Response` class
I had cleaned the workspace a bit:

* `WebConsole::Response` no longer depends on a logger. The detection
  should be better now, so we don't need to couple the query check in
  it.

* `WebConsole::Response` does one thing only. It used to check the
  acceptance of a given `Content-Type`. I moved this to the middleware
  class.

* I have reverted the `WebConsole::WhinyRequest` to keep the logging out
  of the logic in the request class. We no longer need to log in two
  separate classes, so no need to break `Liskov` or introduce logging
  into simple query methods.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants