Dennis Hackethal
Member since June 2024
Activity
#337 · Dennis Hackethal, 3 months agoWhen all I change during a revision is the criticism flag, the activity log just says ‘no changes’.
As of 9702c05, a revision activity now says that the idea was either marked or unmarked as a criticism.
#351 · Dennis Hackethal, 3 months agoWhen a comment is a criticism on another criticism, the activity should say ‘So and so addressed criticism #…’
Done as of 735c3cc.
When a comment is a criticism on another criticism, the activity should say ‘So and so addressed criticism #…’
Fix typo
The activity feed just shows top-level criticisms as regular ideas. They should be shown as criticismssuchjust like when they are child ideas.
#340 · Dennis Hackethal, 3 months agoThe activity feed just shows top-level criticisms as regular ideas. They should be shown as criticisms such like when they are child ideas.
such like
‘just like’
#344 · Dennis Hackethal, 3 months agoShould probably show the explanation in a revision, when given. In the activity feed, that is.
Done as of 7e7c6cd.
Should probably show the explanation in a revision, when given. In the activity feed, that is.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 probably show the explanation in a revision, when given.
Discuss Veritula itself. For feedback and suggestions.
When all I change during a revision is the criticism flag, the activity log just says ‘no changes’.
Accidentally marked as a criticism
#333 · Dennis Hackethal, 3 months agoHaving 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_forminstead offormis 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.
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.
#303 · Dennis Hackethal, 3 months agoHiccdown methods should live in Rails helpers as class methods. That way, the problem described in #302 is solved – methods can be referenced unambiguously:
ProductsHelper.index StoresHelper.index
#327 applies here, too: no access to instance variables inside helper class methods.
#315 · Dennis Hackethal, 3 months agoI don’t think that’s something people would do a lot, but they still easily could:
ProductsRenderer.index(self)
Not as of #330, they couldn’t.
Hiccdown methods should live in their own, separatemodules.classes. How about they are called‘displays’?↵ ↵ ```ruby↵ module‘displays’?↵ ↵ ```ruby↵ class ProductsDisplay defself.indexindex vc, # … vc.some_helper_methodend↵ 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 haveend↵ end↵ ```↵ ↵ Behind the scenes, the Hiccdown gem would need to make thebenefit of having unambiguously resolvable method names.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↵ ```
#325 · Dennis Hackethal, 3 months agoHiccdown methods should live in their own, separate modules. How about they are called ‘displays’?
module ProductsDisplay def self.index vc, # … vc.some_helper_method end endA 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.
Instance variables are not available inside the methods.
#325 · Dennis Hackethal, 3 months agoHiccdown methods should live in their own, separate modules. How about they are called ‘displays’?
module ProductsDisplay def self.index vc, # … vc.some_helper_method end endA 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.
I’m trying this now. Having to prepend every invocation of a helper method with vc. is getting really old really fast.