Hiccdown Development Notes
Discussion started by Dennis Hackethal
Log in or sign up to participate in this discussion.
With an account, you can revise, criticize, and comment on ideas, and submit new ideas.Notes about developing the Ruby gem Hiccdown.
Hiccdown methods should live in Rails helpers as instance methods.
That isn’t a good idea because Hiccdown methods often share the same conventional names (index, show, etc), which can and does lead to conflict.
That isn’t a good idea because Hiccdown methods often share the same conventional names (index, show, etc), which can and does lead to conflict.
Hiccdown methods should live in Rails helpers.
Hiccdown methods should live in Rails helpers as instance methods.
Hiccdown 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
Does that mean they wouldn’t have access to the view_context? If so, calling helper methods from inside these class methods wouldn’t be possible.
If so, there might be a way to bind them to the view_context. Or I could definitely pass the view_context explicitly as the first parameter:
So instead of
@helper_module.instance_method(@action_name).bind_call(view_context)
I would do
@helper_module.send(@action_name, view_context)
And the parameter list of each Hiccdown method would start accordingly:
module ProductsHelper
def self.index vc #, …
vc.some_helper_method
end
def some_helper_method
# …
end
end
If so, there might be a way to bind them to the view_context. Or I could definitely pass the view_context explicitly as the first parameter.
If so, there might be a way to bind them to the view_context. Or I could definitely pass the view_context explicitly as the first parameter:
So instead of
@helper_module.instance_method(@action_name).bind_call(view_context)
I would do
@helper_module.send(@action_name, view_context)
And the parameter list of each Hiccdown method would start accordingly:
module ProductsHelper
def self.index vc #, …
# …
end
end
If so, there might be a way to bind them to the view_context. Or I could definitely pass the view_context explicitly as the first parameter:
So instead of
@helper_module.instance_method(@action_name).bind_call(view_context)
I would do
@helper_module.send(@action_name, view_context)
And the parameter list of each Hiccdown method would start accordingly:
module ProductsHelper
def self.index vc #, …
vc.some_helper_method
end
def some_helper_method
# …
end
end
Does that mean they wouldn’t have the view_context? If so, calling helper methods from inside these class methods wouldn’t be possible.
Does that mean they wouldn’t have access to the view_context? If so, calling helper methods from inside these class methods wouldn’t be possible.
If so, there might be a way to bind them to the view_context. Or I could definitely pass the view_context explicitly as the first parameter.
If so, there might be a way to bind them to the view_context. Or I could definitely pass the view_context explicitly as the first parameter:
So instead of
@helper_module.instance_method(@action_name).bind_call(view_context)
I would do
@helper_module.send(@action_name, view_context)
And the parameter list of each Hiccdown method would start accordingly:
module ProductsHelper
def self.index vc #, …
# …
end
end
If so, there might be a way to bind them to the view_context. Or I could definitely pass the view_context explicitly as the first parameter:
So instead of
@helper_module.instance_method(@action_name).bind_call(view_context)
I would do
@helper_module.send(@action_name, view_context)
And the parameter list of each Hiccdown method would start accordingly:
module ProductsHelper
def self.index vc #, …
vc.some_helper_method
end
def some_helper_method
# …
end
end
That would be mixing class methods an instance methods in Rails helper modules, which typically only contain instance methods. Not idiomatic Rails usage.
That would be mixing class methods an instance methods in Rails helper modules, which typically only contain instance methods. Not idiomatic Rails usage.
Hiccdown 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
Does that mean they wouldn’t have the view_context? If so, calling helper methods from inside these class methods wouldn’t be possible.
Does that mean they wouldn’t have access to the view_context? If so, calling helper methods from inside these class methods wouldn’t be possible.
If so, there might be a way to bind them to the view_context. Or I could definitely pass the view_context explicitly as the first parameter.
If so, there might be a way to bind them to the view_context. Or I could definitely pass the view_context explicitly as the first parameter:
So instead of
@helper_module.instance_method(@action_name).bind_call(view_context)
I would do
@helper_module.send(@action_name, view_context)
And the parameter list of each Hiccdown method would start accordingly:
module ProductsHelper
def self.index vc #, …
# …
end
end
If so, there might be a way to bind them to the view_context. Or I could definitely pass the view_context explicitly as the first parameter:
So instead of
@helper_module.instance_method(@action_name).bind_call(view_context)
I would do
@helper_module.send(@action_name, view_context)
And the parameter list of each Hiccdown method would start accordingly:
module ProductsHelper
def self.index vc #, …
vc.some_helper_method
end
def some_helper_method
# …
end
end
Hiccdown 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
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.
Then how would you call index from a helper method?
I don’t think that’s something people would do a lot, but they still easily could: ProductsRenderer.index(self)
Test this!
Test this!
I don’t think that’s something people would do a lot, but they still easily could: ProductsRenderer.index(self)
Then how would you call this from a helper method?
I don’t think that’s something people would do a lot, but they still easily could: ProductsRenderer.index(self)
Then how would you call index from a helper method?
I don’t think that’s something people would do a lot, but they still easily could: ProductsRenderer.index(self)
I’m trying this now. Having to prepend every invocation of a helper method with vc. is getting really old really fast.
I’m trying this now. Having to prepend every invocation of a helper method with vc. is getting really old really fast.
Hiccdown methods should live in their own, separate modules. How about they are called ‘renderers’?
module ProductsRenderer
def self.index vc, # …
vc.some_helper_method
end
end
Then how would you call this from a helper method?
I don’t think that’s something people would do a lot, but they still easily could: ProductsRenderer.index(self)
Then how would you call index from a helper method?
I don’t think that’s something people would do a lot, but they still easily could: ProductsRenderer.index(self)
Hiccdown methods should live in their own, separate modules. How about they are called ‘renderers’?
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.
Then how would you call this from a helper method?
I don’t think that’s something people would do a lot, but they still easily could: ProductsRenderer.index(self)
Then how would you call index from a helper method?
I don’t think that’s something people would do a lot, but they still easily could: ProductsRenderer.index(self)
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…
Hiccdown 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
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.
Then how would you call this from a helper method?
I don’t think that’s something people would do a lot, but they still easily could: ProductsRenderer.index(self)
Then how would you call index from a helper method?
I don’t think that’s something people would do a lot, but they still easily could: ProductsRenderer.index(self)
I’m trying this now. Having to prepend every invocation of a helper method with vc. is getting really old really fast.
Hiccdown methods should live in their own, separate classes. How about they are called ‘displays’?
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:
display = @display_module.new
view_context.instance_variables.each do |iv|
display.instance_variable_set(
iv,
view_context.instance_variable_get(iv)
)
end
Then:
class ProductsDisplay
def index vc, # …
vc.some_helper_method(@products)
end
end
Then how would you call this from a helper method?
I don’t think that’s something people would do a lot, but they still easily could: ProductsRenderer.index(self)
Then how would you call index from a helper method?
I don’t think that’s something people would do a lot, but they still easily could: ProductsRenderer.index(self)
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.
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.
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.
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.