Workflow for developing a helper without restarting the server between edits

I am developing a helper and each time I make a change to it I have to shutdown the middleman server and then restart it (middleman server) and refresh the page before seeing the changes.

Is this how everyone else is doing it? Is there any easier way apart from developing the helper as a standalone ruby script and integrating to Middleman once complete?

1 Like

I usually develop my Helper inline - in HAML first, then export to the class later.

1 Like

I develop helpers and extensions with a debugger, so I can set break points, explore the call stack, check variable values and test method calls before I finish the actual code. But, otherwise, I do restart Middleman server frequently. (My Middleman sites are usually not big, so restarting doesn’t take long either.)

Thank you @iwarner. Maybe that could work for me as well as my helper isn’t too complex.

@vvasabi I’ll have to bug you about your workflow a bit more one day. Sounds intriguing. I’m not sure I would even know how to launch a debugger on Middleman code. I’m more of a python/shell developer, so I’ve never actually used Ruby prior to working with Middleman.

Thank you both for your answers :slight_smile:

For those as new to Ruby and Middleman as me, it might be helpful to know that in order to include Ruby code (such as helper code) in the HAML you need to use :ruby filter and then indent actual Ruby code ‘under it’, just as you would tags and other content:

:ruby
	def helpername(arg)
	# Some code
	end

Content (code / text) passed to filters can be intended in any way that filter (ruby, markdown, etc.) allows for. In other words, indenting Ruby code for readability won’t cause Illegal nesting syntax error.

No this is incorrect you can inline ruby in HAML as effectively as writing it normally.

Please check out on of my partials here:
https://github.com/iwarner/CodeBlender-Middleman/blob/master/source/atom/button/_button.haml

In the case of testing the Helper in a partial I would not create the method name or enclosing block - focus on the code that does stuff.

In my partial you can see that its all inline - others would put this in a gem, but I like the fact that the code is in a modular place that I can directly edit and see the effects.

So in most cases I go for partials over helpers.

That’s an interesting one @iwarner, although that doesn’t seem to work on .erb files. I guess this “filter” is an Haml specific syntax as per the referenced site, isn’t it?

Outside from the above, it would be good if you can answer some questions so to gather more knowledge?

  • I tried to look at your linked code, but got slightly confused by the different implementations in the button.html.haml? Are those codeBlender methods acting as a kind of interface??

  • What is the relation between the partial _button.haml and the button.html.haml? I couldn’t see the latter recalling the former.

Sorry for all those silly questions; this is probably because I’m not using haml.

= codeblender is actually a helper that just enables me to call my symlinked codeblender partials.

I basically put codeblender into each project, its basically a library of partials built on top of bootstrap with opinionated options

So the button partial - used the icon partial and the image partial - look at the source code to view those.

The _button.haml is the partial

The button.html.haml is the FE code - see http://codeblender.net/atom/button/button.html

Remember this source code you are looking at is a website as much as a collection of partials so check out the FE too.