Activity Feed

  Dennis Hackethal addressed criticism #342.

Highlight current nav item.

#342·Dennis HackethalOP, over 1 year ago

Done as of 146e967.

  Dennis Hackethal submitted criticism #342.

Highlight current nav item.

  Dennis Hackethal addressed criticism #331.

Not as of #330, they couldn’t.

#331·Dennis HackethalOP, over 1 year ago

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

  Dennis Hackethal submitted criticism #340.

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

  Dennis Hackethal submitted criticism #339.

Should I give the icons in the activity feed colors?

  Dennis Hackethal submitted criticism #338.

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

  Dennis Hackethal started a discussion titled ‘Veritula – Meta’.

Discuss Veritula itself. For feedback and suggestions.

The discussion starts with idea #337.

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

  Dennis Hackethal revised criticism #334 and unmarked it as a criticism.

Accidentally marked as a criticism

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.

  Dennis Hackethal criticized idea #333.

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.

#333·Dennis HackethalOP, over 1 year ago

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.

  Dennis Hackethal submitted idea #333.

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.

  Dennis Hackethal criticized idea #303.

Hiccdown methods should live in Rails helpers as class methods. That way, the problem described in #302 is solved – methods can be referenced unambiguously:

ruby
ProductsHelper.index

StoresHelper.index
#303·Dennis HackethalOP, over 1 year ago

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

  Dennis Hackethal addressed criticism #315.

I don’t think that’s something people would do a lot, but they still easily could: ProductsRenderer.index(self)

#315·Dennis HackethalOP, over 1 year ago

Not as of #330, they couldn’t.

  Dennis Hackethal revised idea #325.

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

ruby
module ProductsDisplay

  def self.index vc, # …

    vc.some_helper_method

  end

end

A benefit of this approach is that, when people start a new Rails app, they may end up putting whatever they’d otherwise put in a helper in a display, since displays have the benefit of having unambiguously resolvable method names.

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

ruby
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:

ruby
display = @display_module.new



view_context.instance_variables.each do |iv|

  display.instance_variable_set(

    iv,

    view_context.instance_variable_get(iv)

  )

end

Then:

ruby
class ProductsDisplay

  def index vc, # …

    vc.some_helper_method(@products)

  end

end
  Dennis Hackethal addressed criticism #328.

They are: vc.instance_variable_get(:@foo)

#328·Dennis HackethalOP, over 1 year ago

That’s way too verbose.

  Dennis Hackethal addressed criticism #327.

Instance variables are not available inside the methods.

#327·Dennis HackethalOP, over 1 year ago

They are: vc.instance_variable_get(:@foo)

  Dennis Hackethal criticized idea #325.

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

ruby
module ProductsDisplay

  def self.index vc, # …

    vc.some_helper_method

  end

end

A benefit of this approach is that, when people start a new Rails app, they may end up putting whatever they’d otherwise put in a helper in a display, since displays have the benefit of having unambiguously resolvable method names.

#325·Dennis HackethalOP revised over 1 year ago

Instance variables are not available inside the methods.

  Dennis Hackethal criticized idea #325.

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

ruby
module ProductsDisplay

  def self.index vc, # …

    vc.some_helper_method

  end

end

A benefit of this approach is that, when people start a new Rails app, they may end up putting whatever they’d otherwise put in a helper in a display, since displays have the benefit of having unambiguously resolvable method names.

#325·Dennis HackethalOP revised over 1 year ago

I’m trying this now. Having to prepend every invocation of a helper method with vc. is getting really old really fast.

  Dennis Hackethal revised idea #316.

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

ruby
module ProductsRenderer

  def self.index vc, # …

    vc.some_helper_method

  end

end

A benefit of this approach is that, when people start a new Rails app, they may end up putting whatever they’d otherwise put in a helper in a renderer, since renderers have the benefit of having unambiguously resolvable method names.

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

ruby
module ProductsDisplay

  def self.index vc, # …

    vc.some_helper_method

  end

end

A benefit of this approach is that, when people start a new Rails app, they may end up putting whatever they’d otherwise put in a helper in a display, since displays have the benefit of having unambiguously resolvable method names.

  Dennis Hackethal revised criticism #322.

Tested, it works.

Tested, it works. self does indeed point to the view_context in the helper. Verified by printing object_ids.

  Dennis Hackethal addressed criticism #321.

Test this!

#321·Dennis HackethalOP, over 1 year ago

Tested, it works.

  Dennis Hackethal addressed criticism #315.

I don’t think that’s something people would do a lot, but they still easily could: ProductsRenderer.index(self)

#315·Dennis HackethalOP, over 1 year ago

Test this!

  Dennis Hackethal commented on criticism #319.

I don’t like the term ‘renderer’ yet. It’s too loaded with meaning, what with Rails already having a render method in controllers and another render method in views…

#319·Dennis HackethalOP, over 1 year ago

Maybe ‘Display’. ProductsDisplay

  Dennis Hackethal criticized idea #316.

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

ruby
module ProductsRenderer

  def self.index vc, # …

    vc.some_helper_method

  end

end

A benefit of this approach is that, when people start a new Rails app, they may end up putting whatever they’d otherwise put in a helper in a renderer, since renderers have the benefit of having unambiguously resolvable method names.

#316·Dennis HackethalOP revised over 1 year ago

I don’t like the term ‘renderer’ yet. It’s too loaded with meaning, what with Rails already having a render method in controllers and another render method in views…

  Dennis Hackethal revised criticism #314.

Then how would you call this from a helper method?

Then how would you call index from a helper method?

  Dennis Hackethal revised idea #313.

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

ruby
module ProductsRenderer

  def self.index vc, # …

    vc.some_helper_method

  end

end

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

ruby
module ProductsRenderer

  def self.index vc, # …

    vc.some_helper_method

  end

end

A benefit of this approach is that, when people start a new Rails app, they may end up putting whatever they’d otherwise put in a helper in a renderer, since renderers have the benefit of having unambiguously resolvable method names.