[Question] Using the haml parser by itself

[jaitaiwan]

G'day

I'm wondering if the haml parser could be exposed as it's own library? I'm in need of just the haml -> html part but looking through the code it doesn't look like that's possible?

If you have a suggestion on how to make that happen I'd really appreciate it.

[stackus]

You're correct, that functionality does not exist and isn't easily exposed either.

While mulling over how this might work I considered what might be the expectation for the fragments of the template that are Go code. Did you have an idea of how you saw this working or could expand on your use case?

[jaitaiwan]

I wouldn’t want to include go fragments. The use case is just exclusive HAML. My thought on how it might work would be that the HAML compiler could be separated out and have the go part of it drop into the haml compiler when it knows to drop into that mode.

Hopefully that answers the question a bit?

[stackus]

Are you needing the Haml CLI render command?

With the following saved to test.haml:

!!! 5
%head{lang: "en"}
	%title Example
%body
	%ul
		- (1..3).each do |i|
			%li Item #{i}

Running:

> haml render test.haml

Would render the Haml template directly to HTML. You'd need to use Ruby instead of Go for anything dynamic.

As for the "go fragments" I meant the inline Go code, which you might have as well. But JIC and to clear up any ambiguity this is what I meant demonstrated in a Haml template:

!!!
%head{lang: "en"}
	%title Example
%body
	%ul
		- for i := 0; i < 3; i++
			=@render lineItem(i)

I was talking about the Go code that could be inlined using the - and = operators. It would be very limiting to not be able to use inlined Go in the templates for looping, conditionals, partials, and etc. The hiccup I'm seeing here is determining the type the parameter i goes into when I leave the current template and go into another. Assuming we're dealing with straight Haml templates and we load Haml for the partial from a file named something like "lineItem.haml". One way this could work is inventing some new syntax, it could live in a frontmatter-like section, that defined the types accepted by the template when it gets used as a partial.

Reflecting on the type that i is from the source template might be problematic if the partial is used in different places and reflection gave a different answer.

[jaitaiwan]

So yes, I can see what you're getting at. Effectively looking for the haml render cli command but having the ability to execute it in runtime and deliver the http results. I can see why you've inlined go-code now as you're using it to replace the rubyseque features in haml. I would probably want to treat each template as a completely isolated component and have no ability to reference variables outside of the scope of the current template except for ones that were passed in.