How to avoid bunch of <% %>?

Rails
21

I think that would be nice, except i prefer having a “print” or “echo”
(or
“puts”) method rather than “<<”. also i think “<<” isnt going to parse
with
out doing something like “self <<”. One thing I have always liked better
about php vs ruby is the how you handle printing with echo and print. I
think this would be a wonderful addition for ROR. Anyone instereted in
me
making a plugin? If so let me hear you opinions how how it should work.
print? echo? puts?

mark

22

Now, you were right about <<, it certainly isn’t responding right.

Using a symbol would require a pre-processor it seems.

So, maybe something in between like “p”

<% for @row in @rows
p start_form_tag
p text_field(:row, :name)
p hidden_field(:row, :id)
p end_form_tag
p “\n”
end %>

or “o” for output

<% for @row in @rows
o start_form_tag
o text_field(:row, :name)
o hidden_field(:row, :id)
o end_form_tag
o “\n”
end %>

The o is pretty nice for my eye to catch.

WWDHHD?

-hampton.

23

cdr
> since there are 17 replies all containins <% %>s, i will say it
again,
> check out Markaby !!

Your advice had me give it a good try-1 hour-, and I’m not convinced
(…it’s ripe enough yet).

Problems:

  • trivial template errors cause complete compilation failures, with no
    usable error messages.
  • large views are not trivial to convert (see reason below)
  • converted views are not shorter (on average), or not shorter enough
    to justify using another language.
  • though simple, it’s another templating language to learn & master =>
    mainteance !!??
    …

Maybe I was expecting too much, and it should only be used in its
sweet spots, where it really shine but then I have another problem :
introducing another tool, another plugin and another template language
only to use it in a pair of views would make maintenance more complex.

Note: this is only based on trying Markaby out on one not too complex
project. I’m sure there are cases where it makes a real difference.

Alain

24

James L. wrote:

Maybe it’s worth exploring the possibility that the Java world got
something right. Custom tags, especially like those from Struts, go a
long way toward cleaning up the view.

<logic:iterate name=“someform” property=“someprop” id=“element”>
…
</logic:iterate>

or

<% for element in @someprop -%>
…
<% end -%>

I really hope you forgot the tag there.

I completely fail to see how anyone can think the struts tags can look
better than the erb example.

erb is much more concise.

25

On 4/7/06, David M. [email protected] wrote:

I completely fail to see how anyone can think the struts tags can look
better than the erb example.

erb is much more concise.

Like I said, for simple examples it doesn’t really matter. Now take a
look at the OP and tell me that that’s clean. The biggest problem
with <% %> that I’ve found is that it’s harder to see indentation and
blocks. Tags line up more easily.

– James

26

James L. wrote:

Like I said, for simple examples it doesn’t really matter. Now take a
look at the OP and tell me that that’s clean. The biggest problem
with <% %> that I’ve found is that it’s harder to see indentation and
blocks. Tags line up more easily.

Why not just use the erb blocks as tags for the purpose of indentation?
It looks attractive and consistent. There are some other things that I
do to clean up the view:

  1. Omit unnecessary parenthesis and braces for method invocations and
    hash arguments.
  2. Factor any statement that’s more than about 1 line of code into the
    model or controller as appropriate.
  3. Use form helpers (e.g., text_field) rather than the lowel-level form
    tag helpers (e.g., text_field_tag) when you can, they take care of 90%
    of the common cases very simply. Also, I use symbols instead of stings
    for these arguments because it conveys thet fact that these arguments
    will be used to make calls rather than used as strings.
  4. Use ruby’s efficient syntax to your advantage: write “unless” instead
    of “if not” and “obj ? val1 : val2” instead of “obj.nil? val1 : val2”.

Here’s how I’d reformulate the OP’s example:

Add a one-liner to the model:

def other_categories
Category.find(:all, :conditions => [ “id <> ?”, id] )
end

Add another one-liner to the controller. (You’ll also have to set
@category, but that’s a pretty standard thing to do anyway.) Notice that
you don’t need to set the :selected option because it sets
@category.parent_id as selected by default.

@select_options = @category.other_categories.collect{|c| [ c.title,
c.id ] }

Now, the view is actually really clean:

<%= start_form_tag %>
<%= text_field :category, :title, :size => 20, :maxlength => 128 %>
<% unless category.parent_id.nil? %>
<%= select :category, :parent_id, @select_options %>
<% end %>
<%= submit_tag “Enregistrer” %>
<%= link_to “Annuler”, :action => “list” %>
<%= end_form_tag %>

Don’t you think?