Rails - Sep 2006 - HAML: RoR's new templating engine

Hampton Catlin is presenting a new template engine called HAML at
RailsConf tomorrow.

It combines structured XHTML creation with inline Ruby, but also
borrows the same language used to define CSS. You have to see it to
know what I mean.

I just learned about the project a couple of days ago, and I think it
has a really bright future. My colleagues and I at Unspace prepared an
introductory article on it here:

     http://unspace.ca/discover/haml/

If you like the article, please help spread the word with a Digg:


http://digg.com/programming/Introducing_a_new_templating_engine_for_Rails

Also feel free to work on the Wikipedia entry:

     http://en.wikipedia.org/wiki/HAML

To hear more you''ll have to see Hampton at RailsConf tomorrow.

John


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

Looks really awesome..


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

On 9/13/06, John Philip Green
<heyjohngreen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> Hampton Catlin is presenting a new template engine called HAML at
> RailsConf tomorrow.
>
> It combines structured XHTML creation with inline Ruby, but also
> borrows the same language used to define CSS. You have to see it to
> know what I mean.
Interesting.. No offense, I''m sure it''s a good system in its
own
right, but I''ve been trying very hard to get away from
whitespace-significant programming recently. :)

-Pawel

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

On Sep 13, 2006, at 3:53 PM, John Philip Green wrote:
>
> Hampton Catlin is presenting a new template engine called HAML at
> RailsConf tomorrow.
>
> It combines structured XHTML creation with inline Ruby, but also
> borrows the same language used to define CSS. You have to see it to
> know what I mean.
>
> I just learned about the project a couple of days ago, and I think it
> has a really bright future. My colleagues and I at Unspace prepared an
> introductory article on it here:
>
>      http://unspace.ca/discover/haml/
>
> If you like the article, please help spread the word with a Digg:
>
>
> http://digg.com/programming/ 
> Introducing_a_new_templating_engine_for_Rails
>
> Also feel free to work on the Wikipedia entry:
>
>      http://en.wikipedia.org/wiki/HAML
>
> To hear more you''ll have to see Hampton at RailsConf tomorrow.
>
> John

	This does look very nice. One thing I ran into instantly and that  
wasn''t mentioned in the docs was how to do mutli line iterators. Like  
when you want to iterate over a collection and output elements. I  
couldn''t figure out how that would work. Can you give a clue?

	Other then that, way cool. I''ll definitely give it a go if it can do  
multi line statements.

-Ezra

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

That was one of the first questions I had for Hampton when I saw HAML.
But you can see how the syntax is so much more succinct without it,
because you don''t need closing braces/tags, and then you are not much
better off than using regular XHTML.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

I haven''t used it much at all myself, that''s why the article
is so
basic... but from what I understand you would use regular Ruby control
structures.

The best thing to do would be to hear from Hampton himself. If you''ll
be at RailsConf don''t miss his presentation tomorrow.

Also, I''m sure after his presentation there will be a lot of interest
to get HAML documented and so forth.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

Interesting. It''s nice to have another alternative to rhtml, and I 
couldn''t agree more with that page''s statement that we should
have
better. I think I''ll still probably stick with Markaby, but there are 
some things I think I might like better in HAML, such as no 
closers/blocks. I wonder if Rails'' caching works with HAML (it
doesn''t
with Markaby so far -- been waiting and waiting for why to release a new 
version and docs).

Joe

-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

Checked it out. Looks great, but several questions in my mind would be:

1. I didn''t see any support in the code for block-controlled view
constructs
such as:

<% for foo in @foos do %>
<%= foo.name %>
<% end %>

I.e., how do you stick raw Ruby in without the results being inserted in the
stream?

2. What is the ~ character for? I saw it in the tests and the plugin code,
but not sure what it does.

3. How would designers work with this?

Thanks


John Philip Green wrote:
> 
> 
> Hampton Catlin is presenting a new template engine called HAML at
> RailsConf tomorrow.
> 
> It combines structured XHTML creation with inline Ruby, but also
> borrows the same language used to define CSS. You have to see it to
> know what I mean.
> 
> I just learned about the project a couple of days ago, and I think it
> has a really bright future. My colleagues and I at Unspace prepared an
> introductory article on it here:
> 
>      http://unspace.ca/discover/haml/
> 
> If you like the article, please help spread the word with a Digg:
> 
> 
> http://digg.com/programming/Introducing_a_new_templating_engine_for_Rails
> 
> Also feel free to work on the Wikipedia entry:
> 
>      http://en.wikipedia.org/wiki/HAML
> 
> To hear more you''ll have to see Hampton at RailsConf tomorrow.
> 
> John
> 
> 
> > 
> 
> 
-- 
View this message in context:
http://www.nabble.com/HAML%3A-RoR%27s-new-templating-engine-tf2268612.html#a6299823
Sent from the RubyOnRails Users forum at Nabble.com.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

> 3. How would designers work with this?
Frankly, it''s a godsend ;)

I am a designer at Unspace and have been working in HAML since Hampton
created it, and I find it much easier to use than traditional markup.
It makes complex, HTML heavy pages very readable and compact. I also
think since class and id names have direct correlation with CSS it just
makes sense if you know what I mean. I picked up HAML pretty much right
away and haven''t looked back.

I think if your designers are comforatble working with CSS/XHTML they
shouldn''t have any problem with it.

- Anthony Watts


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

On 9/14/06, s.ross <cwdinfo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
>
>
> Checked it out. Looks great, but several questions in my mind would be:
>
> 1. I didn''t see any support in the code for block-controlled view
> constructs
> such as:
>
> <% for foo in @foos do %>
> <%= foo.name %>
> <% end %>

That was a difficult early decision to make. At first, it was something that
I planned to add. But, then as we began to use it on our projects (several
of them so far) we found that *not* having if, loops, and blocks is actually
a *good* thing.

Our code ends up being more readable, and it forces us to make hard-but-good
decisions on whether the bit of wanted functionality should be a partial, a
helper, or a one-line-loop. Generally, this means that the code is far more
readable

You''d say this

= print_foo_names(@foos)

and go put that in the helpers.

I.e., how do you stick raw Ruby in without the results being inserted in
the
> stream?

Well, in general, that code *should* be in the view, assuming that it
doesn''t return a result.

However, if you want a hacky way...

= action_with_no_result && nil

Any line that returns a nil will not print... that''s including tags.

#wontprint= nil

It can be helpful when you want a wrapping div and you''d like to
supress the
output.


2. What is the ~ character for? I saw it in the tests and the plugin
code,
> but not sure what it does.


Well, the biggest problem with auto-indenting code are those pesky <pre>,
<code>, and <textarea> tags. In all of HTML, they are the only ones
who
don''t want to be indented or you get wonky results.

I spent more time on this issue than on any other in building HAML. I could
fill a book with my thoughts on it and my struggles. However, after talking
to some very smart people and doing lots of consideration, this was the
result.

First, ~ simply says "hey, watch out, you might be given some whitespace
sensitive stuff coming into you from the evaluation on the right". But,
what
it does is causes some processing that changes "\n" into the UTF-8
entity
for endlines. Basically, it puts the whole tag on one line, but puts in an
endline character that the browser can respect, but won''t mess up your
output.

It keeps the output beautiful and doesn''t hurt anything. Also, it saves
some
processing to only have to specify where it might happen.


3. How would designers work with this?


Our designer loves it. They don''t really care  about HTML, they care
about
understanding the structure of the page. Also, they go crazy for the CSS
style syntax.

Funny story, Anthony, the guy who posted below, he wouldn''t work the
other
day because we didn''t install haml on a project. He now refuses to work
on
any projects that don''t use HAML. Simply because he likes the syntax
and the
way it helps him think about the pages structure. Honestly, I am super
surprized by this outcome, but it speaks a lot to what our problems have
been so far.

Thanks
>
>
>
Sincerely,
Hampton Catlin.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

How the hell do you do control structures like loops in HAML???

HAs anyone had any success??

Thanks
CHRIS!

-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

Hello John,

2006/9/13, John Philip Green
<heyjohngreen@gmail.com>:
>      http://unspace.ca/discover/haml/
That's a great example.  One thing I would have liked to see is a call
to a partial.  Is it as simple as:

%table
  %tbody
    %tr= render(:partial => 'foo', :collections => @foos)

Thanks !
-- 
François Beausoleil
http://blog.teksol.info/
http://piston.rubyforge.org/

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to rubyonrails-talk@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

So, assume you want to make a list.

.ul
  = print_foo_names(@foos)

...

def print_foo_names(foos)
  foos.each do |foo|
  content_tag(''li'', foos.name)
end

Is this the general idea?


Hampton wrote:
> 
> 
> You''d say this
> 
> = print_foo_names(@foos)
> 
> and go put that in the helpers.
> 
> 
-- 
View this message in context:
http://www.nabble.com/HAML%3A-RoR%27s-new-templating-engine-tf2268612.html#a6309570
Sent from the RubyOnRails Users forum at Nabble.com.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

Francois Beausoleil wrote:
> %table
>   %tbody
>     %tr= render(:partial => ''foo'', :collections =>
@foos)
Looks good to me Francois.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

You can make helpers.. but I''d argue that in your example,
you''d want
to use a partial.

Down with code inside views!


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

What I''m grappling with is the case where you have a relatively large
number
of records returned from a query. There are times where 

render :partial => ''foo_partial'', :collection => @foos

works great, but then there are times where custom iteration is more
effective. Do you wrap every conditional piece in a partial, as:

= render :partial => ''admin_menu'' if admin?

There''s just not a lot of information out there yet.

I wouldn''t be spending so many cycles on this if I didn''t
think HAML had a
lot of potential. There''s just something I''m not seeing...



Ryan McMinn wrote:
> 
> 
> You can make helpers.. but I''d argue that in your example,
you''d want
> to use a partial.
> 
> Down with code inside views!
> 
> 
> > 
> 
> 
-- 
View this message in context:
http://www.nabble.com/HAML%3A-RoR%27s-new-templating-engine-tf2268612.html#a6310649
Sent from the RubyOnRails Users forum at Nabble.com.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

On Sep 14, 2006, at 10:17 AM, s.ross wrote:
>
>
> What I''m grappling with is the case where you have a relatively  
> large number
> of records returned from a query. There are times where
>
> render :partial => ''foo_partial'', :collection =>
@foos
>
> works great, but then there are times where custom iteration is more
> effective. Do you wrap every conditional piece in a partial, as:
>
> = render :partial => ''admin_menu'' if admin?
>
> There''s just not a lot of information out there yet.
>
> I wouldn''t be spending so many cycles on this if I didn''t
think
> HAML had a
> lot of potential. There''s just something I''m not
seeing...
>

	I agree. I think this looks really promising and would love to be  
able to use it. unfortunately I don''t think its realistic to now  
allow multi line iterations. I may have a look and patch this in  
though. Was it left out because it was hard to implement or because  
the authors really don''t think its needed? I really like the looks of  
these templates but no multi line loops is a show stopper for me.

	I mean, what about form_for block? How do you do those? do you have  
to render a partial that has normal erb in it? I just don''t think it  
makes sense to not allow multi line loops. I would love to see this  
added.


Cheers-
-Ezra

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

Not allowing multi-line iterators is a pretty big limb to cut off, but
I''d like to see it explored more before people demand familiarity.
I''m
pretty interested in this, and plan to try to contribute some patches
in the coming days. One obvious change I feel is that elements like
img, br, hr and link shouldn''t require explicit closing by the coder.

I am also curious to analyze the source more and see if there''s a good
reason not to use the ActionView tag helper lib for basic tag creation.
It does escaping and the basic task it is charged with pretty well
already. Perhaps the authors could elaborate on why they avoided that?

Ezra Zygmuntowicz wrote:
> On Sep 14, 2006, at 10:17 AM, s.ross wrote:
>
> >
> >
> > What I''m grappling with is the case where you have a
relatively
> > large number
> > of records returned from a query. There are times where
> >
> > render :partial => ''foo_partial'', :collection
=> @foos
> >
> > works great, but then there are times where custom iteration is more
> > effective. Do you wrap every conditional piece in a partial, as:
> >
> > = render :partial => ''admin_menu'' if admin?
> >
> > There''s just not a lot of information out there yet.
> >
> > I wouldn''t be spending so many cycles on this if I
didn''t think
> > HAML had a
> > lot of potential. There''s just something I''m not
seeing...
> >
>
>
> 	I agree. I think this looks really promising and would love to be
> able to use it. unfortunately I don''t think its realistic to now
> allow multi line iterations. I may have a look and patch this in
> though. Was it left out because it was hard to implement or because
> the authors really don''t think its needed? I really like the looks
of
> these templates but no multi line loops is a show stopper for me.
>
> 	I mean, what about form_for block? How do you do those? do you have
> to render a partial that has normal erb in it? I just don''t think
it
> makes sense to not allow multi line loops. I would love to see this
> added.
> 
> 
> Cheers-
> -Ezra

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

On 14-Sep-06, at 12:18 PM, Francois Beausoleil wrote:
> That''s a great example.  One thing I would have liked to see is a
call
> to a partial.  Is it as simple as:
>
> %table
>   %tbody
>     %tr= render(:partial => ''foo'', :collection =>
@foos)
Yes. That''s exactly how you''d do it, actually.

/Jeff

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

Steve Ross wrote:
> What I''m grappling with is the case where you have a relatively
large
> number
> of records returned from a query. There are times where
> 
> render :partial => ''foo_partial'', :collection =>
@foos
> 
> works great, but then there are times where custom iteration is more
> effective. Do you wrap every conditional piece in a partial, as:
> 
> = render :partial => ''admin_menu'' if admin?
> 
You can certainly do that line.
> There''s just not a lot of information out there yet.
> 
> I wouldn''t be spending so many cycles on this if I didn''t
think HAML had
> a
> lot of potential. There''s just something I''m not
seeing...
> 
And from your post above: that is indeed the idea. Do you big loops of 
simple things in helpers. Exactly as you said above.

Works nice for taking little obscure loops and making them more clear!

-hampton.

-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

> 	I agree. I think this looks really promising and would love to be
> able to use it. unfortunately I don''t think its realistic to now
> allow multi line iterations.
Ezra-

Great questions from you guys. I''m really glad that you guys are
zooming
right in there with questions I asked myself many, many, many times.

It really comes down to the fact that blocks in views have always been a 
red-flag for me as far as quality of code and readability.

The long term approach for the form_for block is to allow its use in the 
helpers. So, I might have a helper like this for a form.

def person_form(person)
  form_for(person) do |f|
    f.text_area(:name)
    f.date_select(:birthday)
    f.submit_tag
  end
end

Then, when I build my page, it might look like this.

signup.haml
-----------------
%p
  My site really rocks!
.signup
  %p Please fill out the form below to sign up!
  #form_area= person_form()
-----------------

Or heck, just write it yourself using the old helpers.

But, that being said, I''m open to suggestions. The no-block rule has 
worked out several times very well to produce simple-looking code with 
complex rules that gets hidden and broken up in a few ways.

There is the "More than 10 lines a method is bad" school of thought,
and
I''m not necissarily disagreeing this way. Why are we ok with 40 line 
views??

-hampton.

PS: So, I need to override the form_for to get it working without an ERB 
object, since right now its specific to ERB. That''s on the todo list. 
Patches for that would be fantastic!

-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

I forgot one big thing.

I am considering multi-single line support.

That is...

%div= link_to :action => "logoff", |
              :id     => @user.id, |
              :message=> "message" |

Doing the pipes on the end to put together single-evaluated lines.

In theory, if that was implemented, then blocks *could* be possible. 
However, I generally want to stay away from that: see the previous 
posts.

(Also, form_for would *never* work, since I''m not using erb, without 
re-writing. multi-line or not.)

-hampton.

-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

Ezra Zygmuntowicz wrote:
> 	I agree. I think this looks really promising and would love to be
> able to use it. unfortunately I don''t think its realistic to now
> allow multi line iterations. I may have a look and patch this in
> though. Was it left out because it was hard to implement or because
> the authors really don''t think its needed? I really like the looks
of
> these templates but no multi line loops is a show stopper for me.
+1 for me too. I''m not interested in creating partials for each and 
every each loop (which would result in my templates really multiplying), 
nor putting the loop into a helper which outputs via Ruby not template 
markup or rhtml (yuck).

Joe

-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

It''s a paradigm shift all right. For example,

---------hello.haml--------
!!!
%html
  %head
    %title this is the title
  %body
    hello world
    %ul= render :partial => ''list_item'', :collection =>
@members
-------------------------------

---------_list_item.haml---------
%li= list_item.member_name
-------------------------------

I''m going to have to dig into what this means when you get into
pagination
and such. I use blocks for so much stuff in rhtml it would hurt not to have
them. I think elimination of blocks might break the direction Rails is going
but I don''t know for sure...

Steve



Ezra Zygmuntowicz-3 wrote:
> 
> 
> 
> On Sep 14, 2006, at 10:17 AM, s.ross wrote:
> 
>>
>>
>> What I''m grappling with is the case where you have a
relatively
>> large number
>> of records returned from a query. There are times where
>>
>> render :partial => ''foo_partial'', :collection
=> @foos
>>
>> works great, but then there are times where custom iteration is more
>> effective. Do you wrap every conditional piece in a partial, as:
>>
>> = render :partial => ''admin_menu'' if admin?
>>
>> There''s just not a lot of information out there yet.
>>
>> I wouldn''t be spending so many cycles on this if I
didn''t think
>> HAML had a
>> lot of potential. There''s just something I''m not
seeing...
>>
> 
> 
> 	I agree. I think this looks really promising and would love to be  
> able to use it. unfortunately I don''t think its realistic to now  
> allow multi line iterations. I may have a look and patch this in  
> though. Was it left out because it was hard to implement or because  
> the authors really don''t think its needed? I really like the looks
of
> these templates but no multi line loops is a show stopper for me.
> 
> 	I mean, what about form_for block? How do you do those? do you have  
> to render a partial that has normal erb in it? I just don''t think
it
> makes sense to not allow multi line loops. I would love to see this  
> added.
> 
> 
> Cheers-
> -Ezra
> 
> > 
> 
> 
-- 
View this message in context:
http://www.nabble.com/HAML%3A-RoR%27s-new-templating-engine-tf2268612.html#a6312632
Sent from the RubyOnRails Users forum at Nabble.com.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

> ---------hello.haml--------
> !!!
> %html
>   %head
>     %title this is the title
>   %body
>     hello world
>     %ul= render :partial => ''list_item'', :collection
=> @members
> -------------------------------
> 
> ---------_list_item.haml---------
> %li= list_item.member_name
> -------------------------------
No, that would be bad.

This will be committed soon.

!!!
%html
  %head
    %title this is the title
  %body
    hello world
    %ul= list_items(@members) &:login
    %ul= list_items(@members) { |m| "#{m.last_name}, #{m.first_name}"
}


Like I said though, I''m open to suggestions. I just suggest that anyone
reading this... install the plugin, and convert just *one* template. Its 
rather easy. Just change the extention and play with it.

Though, I am always open to reconsidering.

-hampton.

-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

Can you characterize "bad" (as in, "that would be bad")?
I''m finding it
pretty easy to convert templates, although I ran up against one that had 
a file-column in it that required some messing around:

    = @catalog_item = catalog_item;
link_to(image_tag(url_for_file_column("catalog_item",
"image", "thumb")),
{:action => ''enlarge'', :id => catalog_item}, :popup
=> [''new window''])


Joe-95 wrote:
> 
> 
> 
>> ---------hello.haml--------
>> !!!
>> %html
>>   %head
>>     %title this is the title
>>   %body
>>     hello world
>>     %ul= render :partial => ''list_item'',
:collection => @members
>> -------------------------------
>> 
>> ---------_list_item.haml---------
>> %li= list_item.member_name
>> -------------------------------
> 
> No, that would be bad.
> 
> This will be committed soon.
> 
> !!!
> %html
>   %head
>     %title this is the title
>   %body
>     hello world
>     %ul= list_items(@members) &:login
>     %ul= list_items(@members) { |m| "#{m.last_name},
#{m.first_name}" }
> 
> 
> Like I said though, I''m open to suggestions. I just suggest that
anyone
> reading this... install the plugin, and convert just *one* template. Its 
> rather easy. Just change the extention and play with it.
> 
> Though, I am always open to reconsidering.
> 
> -hampton.
> 
> 
-- 
View this message in context:
http://www.nabble.com/HAML%3A-RoR%27s-new-templating-engine-tf2268612.html#a6316390
Sent from the RubyOnRails Users forum at Nabble.com.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

Heads up: run the tabs to spaces command in textmate, even if you are
using soft-tabs. Maybe I misunderstand that term, but it led me to a
while of frustration ''til I realized what was up. Yay whitespace
lovin''.

So, I''m thinking it shouldn''t need me to declare which *html*
elements
are self-terminating. But we can leave in the option for
self-termination at will, of course. I was also thinking % with no
identifer could be considered as %p.

What about an inline syntax:

% Hi. Um.. I {em really}, {strong really} like you. Okay.

Also, why not use ActionView::Helpers::TagHelper? It already handles
the basic tag creation in a simple way, and does escaping and such.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

I agree with everything Seth pointed out. Why not let any amount of
(non-newline) whitespace denote a new block, rather than only two
spaces?

I''d also like to add my voice to those who feel that adding support for
Ruby blocks would be a good idea. If you also added some character, say
''-'', that denoted code that was executed but not used as
output, then
you could do something like:

- for foo in @foolist
  %h1 foo.name
  %p foo.text


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

OK, i have > 30 controllers, with hundreds of views.  Can you imagine 
all the work it would requrie to create sub-views for all my control 
loops!?  I use rails to be speedy and efficient.

It''s a pity HAML is doing this, otherwise it could be a massively used 
templating system.

-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

I echo this.

Have started using HAML for a major project, as it is simply beautiful.

However, I''m not going to write a partial for every tiny loop: it would
be madness.

Neither do I want to mess around with generating layout from a helper
object. Isn''t that what views are for ?

Although I understand that ''code in views'' == bad, surely the
equivalent of "take this collection of things (which were collected
together somewhere else) and show each one like this" is more markup
than code ?

I''m now in the curious position of using HAML for pretty much
everything, and calling in an rhtml partial when I need to pump out a
list. Hardly ideal...

Terry

Chris wrote:
> OK, i have > 30 controllers, with hundreds of views.  Can you imagine
> all the work it would requrie to create sub-views for all my control
> loops!?  I use rails to be speedy and efficient.
>
> It''s a pity HAML is doing this, otherwise it could be a massively
used
> templating system.
> 
> -- 
> Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

Nex3 wrote:
> I agree with everything Seth pointed out. Why not let any amount of
> (non-newline) whitespace denote a new block, rather than only two
> spaces?
> 
> I''d also like to add my voice to those who feel that adding
support for
> Ruby blocks would be a good idea. If you also added some character, say
> ''-'', that denoted code that was executed but not used as
output, then
> you could do something like:
> 
> - for foo in @foolist
>   %h1 foo.name
>   %p foo.text
I''m not against using the - to mean "eval but don''t print
anything".
However, the problem is the way that its all parsed and executed. We 
might be able to work something out, but the deal is that each line is 
currently evaluated in-itself.

I''m not sold on the idea that this is a good thing and the 
implementation would become much more complex.

However, I still haven''t seen any arguements on why this is a Good 
Thing, beyond forces of habit, and that some rails helpers use it. 
Tradition isn''t a good arguement.

In the three fairly-complex projects I have done in HAML, besides 
breaking habit, I haven''t really *needed* blocks. The closest I got was
a pang of rememberance for how i''d do it in rhtml.

I am listening though, and thinking about this very carefully. I''m more
open to arguements about how people have hit certain problems and can''t
solve them with nice-looking code... and there aren''t any alternate 
helpers that could be made to simplify things.

-hampton.

-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

> I''m not against using the - to mean "eval but don''t
print anything".
> However, the problem is the way that its all parsed and executed. We 
> might be able to work something out, but the deal is that each line is 
> currently evaluated in-itself.
> 
I was unclear in my post.

This should mean.. I''m not against the "-" then I start
talking about
blocks and how complex implementing them could be.

I really should read my posts over once before I hit the submit button.

-hampton.


-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

itsterry wrote:
> Although I understand that ''code in views'' == bad, surely
the
> equivalent of "take this collection of things (which were collected
> together somewhere else) and show each one like this" is more markup
> than code ?
It''s presentation logic, not really "code". Things like:

unless session[:member].nil?
  text "Hello #{session[:member].name}!"
end

Joe

-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

On Sep 15, 2006, at 5:31 AM, Hampton Catlin wrote:
>
> Nex3 wrote:
>> I agree with everything Seth pointed out. Why not let any amount of
>> (non-newline) whitespace denote a new block, rather than only two
>> spaces?
>>
>> I''d also like to add my voice to those who feel that adding  
>> support for
>> Ruby blocks would be a good idea. If you also added some  
>> character, say
>> ''-'', that denoted code that was executed but not used
as output, then
>> you could do something like:
>>
>> - for foo in @foolist
>>   %h1 foo.name
>>   %p foo.text
>
> I''m not against using the - to mean "eval but don''t
print anything".
> However, the problem is the way that its all parsed and executed. We
> might be able to work something out, but the deal is that each line is
> currently evaluated in-itself.
So this seems more like an implementation issue rather then there is  
no reason to allow it right? I really like your syntax but I think  
you will keep getting pushback until multi line iterations and if  
statements are allowed.  I looked at the codebase and I don''t think  
it would be too hard to add a little state to the parse loop to keep  
track of multi line statements and eval them accordingly.
>
> I''m not sold on the idea that this is a good thing and the
> implementation would become much more complex.
>
> However, I still haven''t seen any arguements on why this is a Good
> Thing, beyond forces of habit, and that some rails helpers use it.
> Tradition isn''t a good arguement.
What about <% cache do %> blocks? what about content_for :sidebar  
blocks? there are really a ton of useful situations where the blocks  
in a view are very important.

Couldn''t you do some look ahead when parsing the template? You  
already are loading all the lines into memory before processing with  
this line:

template.split(/\n/).map do |line|

What about preprocessing the template to combine multi line  
statements starting with == into one line statements starting with =  
and with the compressed lines separated with ;

so this:

%body
   #posts
     == @posts.each do |post|
     ==   link_to post.title, :action => ''foo'', :id =>
post
     == end

becomes this internally after preprocessing before parsing:

%body
   #posts
     = @posts.each do |post| ; link_to post.title, :action =>  
''foo'', :id => post ; end

Some stupid code that does this preprocessing:

       buffer = []
       seen = false
       last = false
       template.each_with_index do |line, index|
         if line.strip =~ /^==/
           unless seen
             buffer << line.sub(/==/,''='').chomp
             last = index
             seen = true
           else
             buffer[last] <<
'';''+line.sub(''=='',
'''').strip
           end
         else
           seen = false
           buffer << line
         end
       end

And then go into your normal parse loop now that the multi line  
statements are compressed to single line statements? I am sure there  
is a better way to do it but this seems feasible.
>
> In the three fairly-complex projects I have done in HAML, besides
> breaking habit, I haven''t really *needed* blocks. The closest I
got
> was
> a pang of rememberance for how i''d do it in rhtml.
Maybe you haven''t needed block because you weren''t allowed to
do
them ;) I think HAML is truly something very cool, I just think it  
won''t get as much adoption as it should  until you allow multi line  
statements period.


just my two cents here of course...


Cheers-
-Ezra



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

Chris wrote:
> OK, i have > 30 controllers, with hundreds of views.  Can you imagine 
> all the work it would requrie to create sub-views for all my control 
> loops!?  I use rails to be speedy and efficient.
> 
> It''s a pity HAML is doing this, otherwise it could be a massively
used
> templating system.
I enjoyed Hampton''s presentation at RailsConf yesterday, and
I''ve just
read through the whole of this thread.

One thing that strikes me is that Rails has an asymmetry between the use 
of files for helpers (where you can put many helpers in one file), and 
the use of files for partials (where you have have one file per 
partial). I get the impression that in Chris''s case this would lead to 
an unmanageable mass of tiny files.

Would it be possible for HAML partials to get away from the "one file 
per partial" constraint? It would be good to be able to use named 
template fragments, defined either in the file that is using them or in 
a fragment library file looked up by convention (or explicitly imported).

In programming, it''s a good idea to factor out a new method wherever
you
can put a meaningful name to a bunch of lines in an existing method. You 
wouldn''t dream of doing this if every method had to live in its own 
file. Shouldn''t the same principles apply to templates?

regards

   Justin Forder



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

> In programming, it''s a good idea to factor out a new method
wherever you
> can put a meaningful name to a bunch of lines in an existing method. You
> wouldn''t dream of doing this if every method had to live in its
own
> file. Shouldn''t the same principles apply to templates?
Now _that_ is a smart thought !


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

Justin Forder wrote:
> Would it be possible for HAML partials to get away from the "one file
> per partial" constraint? It would be good to be able to use named
> template fragments, defined either in the file that is using them or in
> a fragment library file looked up by convention (or explicitly imported).
This idea needs further exploration... I like it. The concept reminds
me a bit of XSL templates: you would usually have many per file, but
HAML would of course have a different mechanism for including the
partials.

Here''s an example XSL file if you''ve never seen one:
http://www.brics.dk/~amoeller/XML/xslt-4.1.html

John Philip Green


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

HI, does this new template engine code work well within Dreamweaver?
I have had very good success with RHTML code within DW.

Thanks,

-Conrad

On 9/16/06, John Philip Green
<heyjohngreen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
> Justin Forder wrote:
> > Would it be possible for HAML partials to get away from the "one
file
> > per partial" constraint? It would be good to be able to use named
> > template fragments, defined either in the file that is using them or
in
> > a fragment library file looked up by convention (or explicitly
imported).
>
> This idea needs further exploration... I like it. The concept reminds
> me a bit of XSL templates: you would usually have many per file, but
> HAML would of course have a different mechanism for including the
> partials.
>
> Here''s an example XSL file if you''ve never seen one:
> http://www.brics.dk/~amoeller/XML/xslt-4.1.html
>
> John Philip Green
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

I have been following this thread, though not too closely so I may have missed
some of the following points.

1. My first impression is HAML is so "leading edge" that current
editors don''t
have any support for it yet.

2. Although RHTML isn''t "special" or "better" than
ASP, JSP and the likes. However,
besides good compatibility, vanilla HTML do not need further processing. In HAML
just about every line needs to be transformed (HAML -> HTML or whatever).
This
beg the question of performance. Are there performance issues we should be
concerned
about?

3. HAML perhaps may be easily learned but I wonder how well this works in
practice.
It is another layer of abstraction web designers/authors will need to deal with.
I am not
sure how well HAML will be accepted in their world.

Long

>"Conrad Taylor" wrote:
> 
> HI, does this new template engine code work well within Dreamweaver?
> I have had very good success with RHTML code within DW.
> 

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

Justin-

Now, *that''s* along with my thinking.

Very soon we will indeed have multi-line statements. I''m going to make
it clear that I think 99% of the loops in views are *crap* and are
against HAML style.

However, I have wanted to be able to say this.

#links
  = link_to "signup",         |
               :action => "go" |
               :id       => @id |


I think this looks ok and works great for hashs and making stuff look
good by taking one line and making it go on multiple. That being said,
you could do a loop, though, I really don''t recommend it most places.

Now, on to what you said! Your point that we need *another* solution
is exactly what I''m thinking about these days. The fact is that
ApplicationHelpers are weird things. They seem to be where you put it
when you don''t have any other idea of where it should go.

DHH said something in his talk that really hit me. "When you fix one
thing, you notice how broken something else is!" That''s exactly my
opinion. I think that haml''s general restraints (Good Thing) just show
the awkwardness of Helpers at the moment. Or whatever it is that we
can think of that might be better.

One of the solutions I''m thinking of are Markaby fragments. I wish I
could have a backup file of markaby fragments that I can call and use
to describe the little bits that I''m now putting in helpers.

I think the views themselves are better now, now is time to turn our
attention towards new, totally crazy, rebellious ideas for helpers and
fragments.

Please email me directly with your thoughts.

hcatlin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org

Thanks,
Hampton.
>
> Would it be possible for HAML partials to get away from the "one file
> per partial" constraint? It would be good to be able to use named
> template fragments, defined either in the file that is using them or in
> a fragment library file looked up by convention (or explicitly imported).
>
> In programming, it''s a good idea to factor out a new method
wherever you
> can put a meaningful name to a bunch of lines in an existing method. You
> wouldn''t dream of doing this if every method had to live in its
own
> file. Shouldn''t the same principles apply to templates?
>
>
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

>
> I have been following this thread, though not too closely so I may have
missed
> some of the following points.
I''m happy to clarify them.
>
> 1. My first impression is HAML is so "leading edge" that current
editors don''t
> have any support for it yet.
yes, wysiwyg editors have absolutely zero support. However, every
designer I know has dropped wysiwyg for a powerful toolkit of
in-browser css editors and etc.

I''d welcome someone to write that, but its not something any of the
designers I know using this require (or have asked for).
> 2. Although RHTML isn''t "special" or "better"
than ASP, JSP and the likes. However,
> besides good compatibility, vanilla HTML do not need further processing. In
HAML
> just about every line needs to be transformed (HAML -> HTML or
whatever). This
> beg the question of performance. Are there performance issues we should be
concerned
> about?
It is slower. And you are right that it will always be a bit slower.
However, DBs remain the bottleneck in producing a page, not rendering.
While RHTML may be 2% of the render-time for a certain page, HAML is
about 3-4% of the time. That''s absolutely acceptable in my mind when
DBs take up 85% and are still the actual slowdowns.

Caching isn''t implemented yet, but it will be soon. (Patches welcome!)
> 3. HAML perhaps may be easily learned but I wonder how well this works in
practice.
> It is another layer of abstraction web designers/authors will need to deal
with. I am not
> sure how well HAML will be accepted in their world.
Every designer that I know that has used it "in the real world"
won''t
work without it now. They refuse to use anything else. *Not*
coder-designers, just designers.

HAML makes it much easier for a designer to parse in their mind what
is going on because of the syntax and etc. If statements, loops,
blocks, and hand-coded XHTML is probably the worst thing for a
designer to have to deal with. They should only care about
understanding the structure in the DOM.

We at unspace interactive have been using this successfully in all of
our projects over the past 3 months. It wasn''t introduced after it was
created. We held it back to give it its paces and to see how it worked
out. There is a reason that we flew across the world to introduce it
at RailsConf Europe. Its because it works in a real-life situation and
produces great code with very little overhead.

Our goal is to deliver value to our clients, and HAML helps us accomplish that.

It works. Period.

-hampton.

PS: Though, we are always improving!!!!! It isn''t finished yet. But,
now is the world''s chance to make improvements and to make it kick
even more ass than we could do internally.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

I''m going to have to agree on the designer issue. If your designer is
using
DreamWeaver or some other WYSIWYG program, they won''t like HAML. At
least at
first. HAML is more like the underlying document structure. Not every design
requires knowledge of the document structure, but most good designs are
deliberate and are mindful of the document structure. If you design is not
in this category, rhtml still works fine.

One thing that would really help me (and I believe others) understand the
"it works" part of this equation is a non-trivial example of one
action that
really does something interesting. Something that really exercises HAML so
we can learn by example.

This might include a form so we can understand why form_for blocks are not
as interesting in the context of HAML. Additionally, please consider
Ezra''s
comments about joining block statements because I know there are many
instances where I do things like:

<% content_for :sidebar %>
some arbitrary stuff, optionally drawn from instance variables
<% end %>

or even more frequently:

<% content_for :title %>

Thanks for opening this up to the rest of the Rails world.


Hampton wrote:
> 
> Every designer that I know that has used it "in the real world"
won''t
> work without it now. They refuse to use anything else. *Not*
> coder-designers, just designers.
> 
> HAML makes it much easier for a designer to parse in their mind what
> is going on because of the syntax and etc. If statements, loops,
> blocks, and hand-coded XHTML is probably the worst thing for a
> designer to have to deal with. They should only care about
> understanding the structure in the DOM.
> 
-- 
View this message in context:
http://www.nabble.com/HAML%3A-RoR%27s-new-templating-engine-tf2268612.html#a6342894
Sent from the RubyOnRails Users forum at Nabble.com.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

Speaking to the implementation issues of using loops, I''ve submitted a
patch that allows the following:
- for page in @pages
  %h1= page.name
  .page
    = page.text
- end
This works for all types of blocks. It should be possible to eliminate
the need to manually type "end" as well. So it''s not a
problem to
implement loops and blocks in HAML... it''s just an issue of whether or
not we want them.

Personally, I feel that loops and especially if statements are
neccessary for the language. There are certainly many times when
they''re inappropriate, but there are also many times when
they''re
legitimately useful. In addition, they''re an integral part of Ruby;
various methods built into the language and into Rails rely upon
blocks, the ability to key off a boolean, and the like. HAML won''t be
able to use any of this if it doesn''t support blocks.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

And the patch is ... where?


Nex3 wrote:
> 
> 
> Speaking to the implementation issues of using loops, I''ve
submitted a
> patch that allows the following:
> - for page in @pages
>   %h1= page.name
>   .page
>     = page.text
> - end
> This works for all types of blocks. It should be possible to eliminate
> the need to manually type "end" as well. So it''s not a
problem to
> implement loops and blocks in HAML... it''s just an issue of
whether or
> not we want them.
> 
> Personally, I feel that loops and especially if statements are
> neccessary for the language. There are certainly many times when
> they''re inappropriate, but there are also many times when
they''re
> legitimately useful. In addition, they''re an integral part of
Ruby;
> various methods built into the language and into Rails rely upon
> blocks, the ability to key off a boolean, and the like. HAML won''t
be
> able to use any of this if it doesn''t support blocks.
> 
> 
> > 
> 
> 
-- 
View this message in context:
http://www.nabble.com/HAML%3A-RoR%27s-new-templating-engine-tf2268612.html#a6343610
Sent from the RubyOnRails Users forum at Nabble.com.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

Hampton wrote:
> I''m going to make
> it clear that I think 99% of the loops in views are *crap* and are
> against HAML style.
Odd, since many others here disagree, and so many other existing 
template languages do as well...

Joe

-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

@s.ross: Here:
http://dev.hamptoncatlin.com/haml/ticket/16


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

I would add that one of the most Rails-esque things to do is just get
something working and then polish it up later. TDD encourages this too.
Here''s an example from scaffold:

<% for column in Catalog.content_columns %>
<p>
  <%= column.human_name %>: <%=h @catalog.send(column.name) %>
</p>
<% end %>

<%= link_to ''Edit'', :action => ''edit'',
:id => @catalog %> |
<%= link_to ''Back'', :action => ''list''
%>


Without knowing anything about the underlying model, this view uses loops to
iterate over the members of the content_columns collection twice. Yeah, the
problem can be solved other ways. It probably *will* be solved a different
way in the final implementation. But somethings just getting the CRUD to
work is enough to see whether you''re headed in the right direction.

Would this be sooooo evil to include in HAML?

--steve


Joe Ruby MUDCRAP-CE wrote:
> 
> 
> Hampton wrote:
>> I''m going to make
>> it clear that I think 99% of the loops in views are *crap* and are
>> against HAML style.
> 
> Odd, since many others here disagree, and so many other existing 
> template languages do as well...
> 
> Joe
> 
> -- 
> Posted via http://www.ruby-forum.com/.
> 
> > 
> 
> 
-- 
View this message in context:
http://www.nabble.com/HAML%3A-RoR%27s-new-templating-engine-tf2268612.html#a6344104
Sent from the RubyOnRails Users forum at Nabble.com.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

I feel like the suggestions for how to handle multi-line blocks here
are turning HAML into an ugly beast, should they come to fruition. It
seems to me that there are probably ways to figure out when a
multi-line statement terminates without any explicit help. For
starters, if = is encountered, but no special symbols for subsequent
lines, couldn''t you assume the expression continues until the next
special symbol is encountered?

For what it''s worth, I can tell you right now that I''d pretty
much drop
HAML like a hot potato if it turned into something that required me to
do == or | for every line of a block. That seems very far off the mark
for what HAML promised out of the gates.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

Don''t worry, my patch deals with this. All you have to do for a block
is:

- block_magic do |param|
  = param.stuff
  %p= param.magic

No closing tag or repetitive characters needed.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

I applied this patch and as I noted in Trac, it causes certain breakage in my
code. Maybe I did something wrong...

(eval):3:in `template_eval'': compile error
(eval):3: parse error, unexpected ''('', expecting $
$HAML_instance << ""( "fine" * 3).to_s <<
"\n"
                     ^
Extracted source (around line #0):

1: = "fine" * 3


Here''s the template that breaks (expected result: finefinefine):

= "fine" * 3

And one that works around the above error:

%p= "fine" * 3




Nex3 wrote:
> 
> 
> Don''t worry, my patch deals with this. All you have to do for a
block
> is:
> 
> - block_magic do |param|
>   = param.stuff
>   %p= param.magic
> 
> No closing tag or repetitive characters needed.
> 
> 
> > 
> 
> 
-- 
View this message in context:
http://www.nabble.com/HAML%3A-RoR%27s-new-templating-engine-tf2268612.html#a6346496
Sent from the RubyOnRails Users forum at Nabble.com.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

I am developing a Rails site and am gearing for deployment. The one last
bit I want to do (and need help with) is to make the site more professional
looking.

1. I need a good stylesheet color scheme for font, div borders and background.

2. I am somewhat a minimalist. I only need a handful of graphic icons and
maybe a site logo.

3. The overall site layout is done and set. I may need help with layout for
specific areas within a page.

Work will be off-site. I don''t think it will require a lot of work (I
could be
wrong) but if you are interested in helping, send me a note to

long755[@]rogers[dot]com.

In the message, describe your background and current work. Please include
links to live sites that you''ve designed or created graphics for. Note,
resumes
will NOT be read.

I want to thank you all for your interest, but only successful candidates will
be contacted for round 2.

Cheers,

Long
PS: If you know of a good designer please forward this message.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

Checking back in.. I lost steam with HAML. Going back to the few
templates I initially converted, I''m not sure I like it as much. I do
want to keep an eye on it, though.

Hampton, you commented on DBs being the bottleneck, not rendering, but
from what I''ve heard (including from members of Rails core), rendering
has actually been one of the most notorious performance monkeys on our
collective back for most of Rails life thus far.

This is just what I''ve heard, and I''d be interested for more
of your
take on this.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

Seth Thomas Rasmussen wrote:
> 
> Checking back in.. I lost steam with HAML. Going back to the few
> templates I initially converted, I''m not sure I like it as much. I
do
> want to keep an eye on it, though.
> 
> Hampton, you commented on DBs being the bottleneck, not rendering, but
> from what I''ve heard (including from members of Rails core),
rendering
> has actually been one of the most notorious performance monkeys on our
> collective back for most of Rails life thus far.
> 
> This is just what I''ve heard, and I''d be interested for
more of your
> take on this.
> 
My bad. I somehow created a new thread that followed this one...

Back to rendering performance. In a templating system, my understanding
is that static content is usually pushed to the template and one tries to keep
dynamic content to a minimum. Rails has many helpers that are used to transform
to static html, for convenience. This can be good but the cost is performance
when
it is over-used. With rhtml developers do have more control and can balance/tune
rendering speed more easily. I don''t think the same can be said for
HAML.

Long


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

> Hampton, you commented on DBs being the bottleneck, not rendering, but
> from what I''ve heard (including from members of Rails core),
rendering
> has actually been one of the most notorious performance monkeys on our
> collective back for most of Rails life thus far.
On my production site (which is currently in closed beta) DB is 
consistantly less than %20, and often under %10. I''d have to agree that
rendering is the main bottleneck.

Just a thought...maybe the DB is the bottleneck on all ur sites because 
ur using HAML without caching support (which at view level, requires 
blocks)....it''s possible.

Anyways, I, like most others in this discussion, think HAML has a LOT of 
potential and will be a great product once it matures a bit more and 
supports caching and blocks with a nice, easy syntax. Until then I
won''t
be using it, but I will be watching it''s development closely. Keep up 
the good work ;)

Golly

-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

[Oops, repost cos I replied to the wrong email...sorry]
> Hampton, you commented on DBs being the bottleneck, not rendering, but
> from what I''ve heard (including from members of Rails core),
rendering
> has actually been one of the most notorious performance monkeys on our
> collective back for most of Rails life thus far.
On my production site (which is currently in closed beta) DB is
consistantly less than %20, and often under %10. I''d have to agree that
rendering is the main bottleneck.

Just a thought...maybe the DB is the bottleneck on all ur sites because
ur using HAML without caching support (which at view level, requires
blocks)....it''s possible.

Anyways, I, like most others in this discussion, think HAML has a LOT of
potential and will be a great product once it matures a bit more and
supports caching and blocks with a nice, easy syntax. Until then I
won''t
be using it, but I will be watching it''s development closely. Keep up
the good work ;)

Golly

-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

Seth Thomas Rasmussen wrote:
> Hampton, you commented on DBs being the bottleneck, not rendering, but
> from what I''ve heard (including from members of Rails core),
rendering
> has actually been one of the most notorious performance monkeys on our
> collective back for most of Rails life thus far.
I''ve never had performance problems with rendering. DB is the only one 
I''ve had to watch for.

Joe

-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

I''ve noticed consistent problems with rendering times. DB queries (once
memcached) doesn''t seem to be an issue. Especially the link helpers and
the
routes are pretty pathetic when it comes to speed (and even nominally
complex routes). I haven''t played around with Edge (or REST) but in the
last
rails stable, rendering is a bottleneck. Stafan Kaes has a template
optimizer (and some pointers to route generation) which has helped me a lot.

Vish

On 10/2/06, Joe Ruby MUDCRAP-CE
<rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>
wrote:
>
>
> Seth Thomas Rasmussen wrote:
>
> > Hampton, you commented on DBs being the bottleneck, not rendering, but
> > from what I''ve heard (including from members of Rails core),
rendering
> > has actually been one of the most notorious performance monkeys on our
> > collective back for most of Rails life thus far.
>
> I''ve never had performance problems with rendering. DB is the only
one
> I''ve had to watch for.
>
> Joe
>
> --
> Posted via http://www.ruby-forum.com/.
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

When you guys say "DB is consistantly less than %20", where do you get
that
from?

On 10/2/06, Vishnu Gopal
<g.vishnu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
> I''ve noticed consistent problems with rendering times. DB queries
(once
> memcached) doesn''t seem to be an issue. Especially the link
helpers and the
> routes are pretty pathetic when it comes to speed (and even nominally
> complex routes). I haven''t played around with Edge (or REST) but
in the last
> rails stable, rendering is a bottleneck. Stafan Kaes has a template
> optimizer (and some pointers to route generation) which has helped me a
lot.
>
>
> Vish
>
> On 10/2/06, Joe Ruby MUDCRAP-CE
<rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:
> >
> >
> > Seth Thomas Rasmussen wrote:
> >
> > > Hampton, you commented on DBs being the bottleneck, not
rendering, but
> >
> > > from what I''ve heard (including from members of Rails
core), rendering
> > > has actually been one of the most notorious performance monkeys
on our
> > > collective back for most of Rails life thus far.
> >
> > I''ve never had performance problems with rendering. DB is the
only one
> > I''ve had to watch for.
> >
> > Joe
> >
> > --
> > Posted via http://www.ruby-forum.com/.
> >
> >
> > > >
> >

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

blinking bear wrote:
> When you guys say "DB is consistantly less than %20", where do
you get
> that
> from?
If you look in the log files you can get info on rendering/DB time.
Eg:
Completed in 0.07800 (12 reqs/sec) | Rendering: 0.04700 (60%) | DB: 
0.01500 (19%) | 200 OK

-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

I am certain that for your site that must be true. However, that does
also lead me to believe that you aren''t doing DB calls that are that
intensive. Doing three joins across tables that you can''t really cache,
because its over several servers and is constantly changing. I
generally have DB calls that are about 70% on most of the *major* calls
to server.

As far as speed in HAML goes, there are a couple notes about it. We
have achieved a 20-30% speedup already in the latest version (0.2)

With silent-scripting, I think that rails-caching probably works now,
though I haven''t tried it out yet.

And, beyond that, we are currently starting work on building a C
compiler for HAML (and its derivatives also in development). Basically,
in version 0.2, HAML does some compiling before it gets executed. Very
similar to what ERb does. Anyhow, we noticed that we would very likely
be able to move this code into a C library and have it spit out HAML
buffered-ready code very quickly. Adding that into the codebase (might
show up around 0.5) should make us *faster* than ERb.

Though, only time will tell.

Anyhow, I appreciate the feedback on HAML and will take your concerns
on speed to heart and work even more on getting speed-ups. However,
though I am working to improvements, I don''t think that speed should
keep anyone from actually using it in production. Yes, it is slower,
but its not so slow that your site would come to a crawl in any real
sense.

All of our sites still feel zippy.

-hampton.


On Oct 1, 9:26 pm, David Barri
<rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>
wrote:
> > Hampton, you commented on DBs being the bottleneck, not rendering, but
> > from what I''ve heard (including from members of Rails core),
rendering
> > has actually been one of the most notorious performance monkeys on our
> > collective back for most of Rails life thus far.On my production site
(which is currently in closed beta) DB is
> consistantly less than %20, and often under %10. I''d have to agree
that
> rendering is the main bottleneck.
>
> Just a thought...maybe the DB is the bottleneck on all ur sites because
> ur usingHAMLwithout caching support (which at view level, requires
> blocks)....it''s possible.
>
> Anyways, I, like most others in this discussion, thinkHAMLhas a LOT of
> potential and will be a great product once it matures a bit more and
> supports caching and blocks with a nice, easy syntax. Until then I
won''t
> be using it, but I will be watching it''s development closely. Keep
up
> the good work ;)
> 
> Golly
> 
> --
> Posted viahttp://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

Just a comment on a C compiler. It seems like optimizing that close  
to bare metal will introduce portability issues. In any case, a  
different approach would be to introduce an optimizer much as Stephan  
Kaes has shown for Erb. The idea is that you do some semantic  
evaluation of the code looking for things like loop-invariants,  
common sub-expressions, and expensive evaluations that might be  
linearized.

I''m still not sure rendering is that big a deal. It''s very
difficult
to tell where the components divide out, but RailsBench does a pretty  
good job of telling you -- is it clear that everyone is suffering  
from templating engine overhead? Compiling to C just seems like a big  
hammer.



On Oct 20, 2006, at 5:04 AM, hcatlin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
wrote:
>
> I am certain that for your site that must be true. However, that does
> also lead me to believe that you aren''t doing DB calls that are
that
> intensive. Doing three joins across tables that you can''t really  
> cache,
> because its over several servers and is constantly changing. I
> generally have DB calls that are about 70% on most of the *major*  
> calls
> to server.
>
> As far as speed in HAML goes, there are a couple notes about it. We
> have achieved a 20-30% speedup already in the latest version (0.2)
>
> With silent-scripting, I think that rails-caching probably works now,
> though I haven''t tried it out yet.
>
> And, beyond that, we are currently starting work on building a C
> compiler for HAML (and its derivatives also in development).  
> Basically,
> in version 0.2, HAML does some compiling before it gets executed. Very
> similar to what ERb does. Anyhow, we noticed that we would very likely
> be able to move this code into a C library and have it spit out HAML
> buffered-ready code very quickly. Adding that into the codebase (might
> show up around 0.5) should make us *faster* than ERb.
>
> Though, only time will tell.
>
> Anyhow, I appreciate the feedback on HAML and will take your concerns
> on speed to heart and work even more on getting speed-ups. However,
> though I am working to improvements, I don''t think that speed
should
> keep anyone from actually using it in production. Yes, it is slower,
> but its not so slow that your site would come to a crawl in any real
> sense.
>
> All of our sites still feel zippy.
>
> -hampton.
>
>
> On Oct 1, 9:26 pm, David Barri
<rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>
> wrote:
>>> Hampton, you commented on DBs being the bottleneck, not  
>>> rendering, but
>>> from what I''ve heard (including from members of Rails
core),
>>> rendering
>>> has actually been one of the most notorious performance monkeys  
>>> on our
>>> collective back for most of Rails life thus far.On my production  
>>> site (which is currently in closed beta) DB is
>> consistantly less than %20, and often under %10. I''d have to
agree
>> that
>> rendering is the main bottleneck.
>>
>> Just a thought...maybe the DB is the bottleneck on all ur sites  
>> because
>> ur usingHAMLwithout caching support (which at view level, requires
>> blocks)....it''s possible.
>>
>> Anyways, I, like most others in this discussion, thinkHAMLhas a  
>> LOT of
>> potential and will be a great product once it matures a bit more and
>> supports caching and blocks with a nice, easy syntax. Until then I  
>> won''t
>> be using it, but I will be watching it''s development closely.
Keep up
>> the good work ;)
>>
>> Golly
>>
>> --
>> Posted viahttp://www.ruby-forum.com/.
>
>
> >

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

A native version would most likely be a unix-only Gem that can
optionally be installed to speed up certain string-manipulations
(especially in the pre-compile) stage.

However, also this weekend, I was working on the code-base for the
upcoming 0.3 release and added caching (via pre-compiled buffering) to
the engine. I was able to achieve a 50% speedup. My benchmarks on v.2
that take 0.5 seconds now take 0.22 seconds (results obviously may
vary).

This puts us much closer to where we want to be.

That being said. I agree with you. All of my production apps seem
zippy enough. I really don''t notice any slow-downs at all. However,
that being said, I still think its important to really work on this
and keep the code as stable and fast as possible.

-hampton.

On 10/22/06, s.ross <cwdinfo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
> Just a comment on a C compiler. It seems like optimizing that close
> to bare metal will introduce portability issues. In any case, a
> different approach would be to introduce an optimizer much as Stephan
> Kaes has shown for Erb. The idea is that you do some semantic
> evaluation of the code looking for things like loop-invariants,
> common sub-expressions, and expensive evaluations that might be
> linearized.
>
> I''m still not sure rendering is that big a deal. It''s
very difficult
> to tell where the components divide out, but RailsBench does a pretty
> good job of telling you -- is it clear that everyone is suffering
> from templating engine overhead? Compiling to C just seems like a big
> hammer.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---