Search Ideas

Done as of e3f2c5b.

In activity feed, behind timestamp (‘… hours ago’), link to corresponding discussion.

Done as of c11a13c.

As of 9702c05, a revision activity now says that the idea was either marked or unmarked as a criticism.

Done as of 735c3cc.

When a comment is a criticism on another criticism, the activity should say ‘So and so addressed criticism #…’

The activity feed just shows top-level criticisms as regular ideas. They should be shown as criticisms just like when they are child ideas.

such like

‘just like’

Done as of 8269806.

Done as of 7e7c6cd.

Should probably show the explanation in a revision, when given. In the activity feed, that is.

Done as of 146e967.

Highlight current nav item.

It doesn’t really matter. This would be like calling a controller action from a helper method. Not something people do.

The activity feed just shows top-level criticisms as regular ideas. They should be shown as criticisms such like when they are child ideas.

Should I give the icons in the activity feed colors?

Should probably show the explanation in a revision, when given.

When all I change during a revision is the criticism flag, the activity log just says ‘no changes’.

I think the thing I’m really fighting here is Rails being object-oriented. Which I can’t do anything about.

Not sure the Rails team realizes how much OOP reduces the extensibility of Rails.

I think the thing I’m really fighting here is Rails being object-oriented. Which I can’t do anything about.

Not sure the Rails team realizes how much OOP reduces the extensibility of Rails.

Having explored three different ideas, I believe #302 – having regular helper methods to render Hiccdown structures – is the best.

The idea is not without its flaws, but having to qualify a method name by, say, calling it idea_form instead of form is still better than manually having to pass the view context around all the time and not being able to trivially access instance variables.

So I’ll stick with #302 for now, which is the status quo already.

#327 applies here, too: no access to instance variables inside helper class methods.

Not as of #330, they couldn’t.

Hiccdown methods should live in their own, separate classes. How about they are called ‘displays’?

1
2
3
4
5

class ProductsDisplay
  def index vc, # …
    vc.some_helper_method
  end
end

Behind the scenes, the Hiccdown gem would need to make the instance variables available to the display class:

1
2
3
4
5
6
7
8

display = @display_module.new

view_context.instance_variables.each do |iv|
  display.instance_variable_set(
    iv,
    view_context.instance_variable_get(iv)
  )
end

Then:

1
2
3
4
5

class ProductsDisplay
  def index vc, # …
    vc.some_helper_method(@products)
  end
end

That’s way too verbose.