Giters

chrismccord / phoenix_haml

Phoenix Template Engine for Haml

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Time to bumb the version

JustMikey opened this issue · comments

commented

Trying to add it to mix.exs file, I get the following:

Looking up alternatives for conflicting requirements on phoenix_html
Activated version: 2.1.0
From deps/phoenix_haml/mix.exs: ~> 1.1
From mix.exs: ~> 2.0
** (Mix) Hex dependency resolution failed, relax the version requirements or unlock dependencies

commented

Is phoenix_haml still a strategic part of phoenix? Seems to get little treatment lately.

I'm currently evaluating Elixir / Phoenix as a future platform and haml is a must for me. Elixir is such a nice, noise free language but I can't stand eex templates (can't stand erb as well).

commented

@gernotkogler same here

commented

Is phoenix_haml still a strategic part of phoenix? Seems to get little treatment lately.

I'm currently evaluating Elixir / Phoenix as a future platform and haml is a must for me. Elixir is such a nice, noise free language but I can't stand eex templates (can't stand erb as well).

No. It never really was, but all it is a bridge b/w phoenix template engine and calliope, so it is quite easy to maintain. One thing I will recommend is this:

At least, for a moment, consider it might be time to move on from haml. I used haml exclusively for 4 years, but my thoughts have changed on it. It's an extra layer of complexity for your application and the readability benefits are outweighed by the dependency and edge cases. Often any keystroke you save is offset everytime you need to do

= surround "," do
  ...

So this project is an option, but I would seriously reconsider your tooling since you are evaluating a different stack anyway. It might be time to move on. There's also http://emmet.io which can give you the best of both worlds.

commented

@chrismccord Thank you for your reply and the link to emmet project, it seems rather interesting

commented

Thanks for making that that clear, so phoenix_haml is dead, right? Emmet is not what I'm looking for, I certainly could write pure html with all the bells and whistles if I wanted to, but I don't. Writing that noise is one point, reading it many times afterwards ist what counts to me.

One last question: Ist the long term strategy for phoenix to be a full stack web framework or are you favoring SPA architectures in the long term (generating html on the client side)?

commented

Thanks for making that that clear, so phoenix_haml is dead, right?

No it's not dead, it's just not a "strategic part of phoenix". It's just glue between the phoenix template engine, and calliope(the haml parser) this is literally the entire thing required to support it from the source:

defmodule PhoenixHaml.Engine do
  @behaviour Phoenix.Template.Engine

  @doc """
  Precompiles the String file_path into a function defintion, using Calliope engine
  """
  def compile(path, _name) do
    path
    |> read!
    |> EEx.compile_string(engine: Phoenix.HTML.Engine, file: path, line: 1)
  end

  defp read!(file_path) do
    file_path |> File.read! |> Calliope.Render.precompile
  end
end

One last question: Ist the long term strategy for phoenix to be a full stack web framework or are you favoring SPA architectures in the long term (generating html on the client side)?

Phoenix will be fantastic for both.

commented

I'm sure it is ;-) But 'moving on' in my book is not falling back to embedded html that I wrote when Rails was 1.0. I think phoenix needs a modern templating language that suits the elegance of elixir, it doesn't have to be haml. Maybe I'll find time to try something after I've mastered the basics of elixir / phoenix.

commented

I'll take a look at phoenix_haml. I'm in the process of updating calliope now and should have changes out by the end of the week

—
Thanks,

Johnny

On Sun, Aug 16, 2015 at 4:35 PM, Chris McCord notifications@github.com
wrote:

Thanks for making that that clear, so phoenix_haml is dead, right?
No it's not dead, it's just not a "strategic part of phoenix". It's just glue between the phoenix template engine, and calliope(the haml parser) this is literally the entire thing required to support it from the source:

defmodule PhoenixHaml.Engine do
  @behaviour Phoenix.Template.Engine
  @doc """
  Precompiles the String file_path into a function defintion, using Calliope engine
  """
  def compile(path, _name) do
    path
    |> read!
    |> EEx.compile_string(engine: Phoenix.HTML.Engine, file: path, line: 1)
  end
  defp read!(file_path) do
    file_path |> File.read! |> Calliope.Render.precompile
  end
end

One last question: Ist the long term strategy for phoenix to be a full stack web framework or are you favoring SPA architectures in the long term (generating html on the client side)?

Phoenix will be fantastic for both.

Reply to this email directly or view it on GitHub:
#16 (comment)

commented

👍 I'm using phoenix_haml in production now and struggle to upgrade phoenix to 1.0. Indeed, we're converting from jade to haml in order to use phoenix.

Considering the popularity of haml, this library should be a strategic part of phoenix. I believe that jade plays a major part in the success of express.js. Languages like haml and jade have much better usability than html. Better usability means better productivity and maintainability. Falling back to EEx is a big backward step for most programmers. I believe many of us won't eagerly adapt phoenix because of this reason. Phoenix doesn't have "management pressures" like java frameworks to push programmers to use them. If phoenix will be relied on foot soldiers (like us), phoenix should help us work less (obviously by typing less characters).

I really like to see phoenix being used by many more programmers. Phoenix is really nice framework, and the performance in production is superb. Its shortcoming is its default template engine. If we can have a better choice for templates, I'm sure phoenix will beat express.js (even with its wonderful jade template system) in no time.

commented

I have not published a new release to hex yet, but master should work 1.0. Please give that a try. If it doesn't, PRs will gladly be accepted. Haml will never be a strategic part of phoenix. Ask the rails community how just using erb worked out for them :) . If you want to use haml/slim/et al, phoenix has a template engine layer that will make it all possible, but it won't be part of core.

commented

I think we shouldn't start a discussion on erb vs haml here. There are enough "this vs that" wars among programmers already. For us, our systems are ported from rails to node. The templates are converted from erb to haml to jade during the years. Currently, we have ported several parts to phoenix and run them in production. Phoenix runs great, and we want to port more parts to phoenix especially after it has 1.0 version.

By being a strategic part, it doesn't have to be in the core. I think phoenix should have a "strategic toolbelt", i.e., packages that facilitate programmers to convert existing systems to phoenix.

I really like phoenix. I wish I would have time available to contribute to the project. Porting jade to elixir seems to be fun (and challenging). However, my schedule doesn't allow me to do that anytime soon.

commented

I think phoenix should have a "strategic toolbelt", i.e., packages that facilitate programmers to convert existing systems to phoenix.

We have that then, with your template engine layer. Just so we're clear, as I said above, this is literally the entirety of the code required to support a new template engine in phoenix (haml in this case):

defmodule PhoenixHaml.Engine do
  @behaviour Phoenix.Template.Engine

  @doc """
  Precompiles the String file_path into a function defintion, using Calliope engine
  """
  def compile(path, _name) do
    path
    |> read!
    |> EEx.compile_string(engine: Phoenix.HTML.Engine, file: path, line: 1)
  end

  defp read!(file_path) do
    file_path |> File.read! |> Calliope.Render.precompile
  end
end

So we have the toolbelt for programmer extension. I think you'll find a happy home here :)

commented

I'm very interested in phoenix/elixir and I'm making the strategic technical decisions at our shop. We are building large, complex business apps on the rails platform - think SAP, just a little smaller ;-) Therefore, complex templates and forms are a big thing to us. Imho, a modern templating language is a must for a modern web framework. I'm aware that phoenix is moving fast right now, but had we already adopted the platform we would be stuck at version 0.x since phoenix_haml is not ready. For me, this is a showstopper, as much as I love phoenix / elixir.

commented

since phoenix_haml is not ready

It's ready.

commented

Ok, didn't realize that, sorry. I'll try it right now. And keep up the great work!

commented

@chrismccord I understand what you mean. It seems easy to add another template engine to phoenix. However, we still need to implement the template engine we want to use.

For haml, it's calliope. However, calliope has a few serious bugs that we've already reported to @nurugger07. We're really waiting for the updates. I wish we could help @nurugger07 fix the bugs, but our schedule doesn't let us do that. Probably, the phoenix team can help him better and faster than we do?

commented

We're really waiting for the updates. ... Probably, the phoenix team can help him better and faster than we do?

Phoenix and calliope consists of only a handful of comitters, all with spouses, jobs, and families.