Masterview users - Jan 2007 - problem with mv:attr and erb evaluated code.

I ran into this before, but I can''t find any email from me about it.
Sorry if this is a repeat, but the problem persists in MV 0.3.1

If you have a helper method that you want to evaluate in a construct like:

<div mv:attr=":id => #{myhelper(arg)}"></div>

it legitimately renders it so:
<div id="<%= myhelper(arg) %>"></div>

But if you increase the argument count to more than 1, e.g.:
<div mv:attr=":id => #{myhelper(arg, 1)}">

It renders:
<div></div>

You can try this in the interactive render. Perhaps it has something
to do with the commas? In any case, the bit between the ''#{''
and ''}''
should be dropped as is into the erb output. No parsing at all should
be done on this string.

In my case, I could not create an array for the args because it was a
mv:attr at the same level as the mv:block and one of the args was the
bound variable ({|arg2| ...} of the block. In the end, I created a
closure with the other arg and called p.call(arg2) I don''t think I
should have had to do that.

It only seems to occur with commas. Periods and other Ruby punctuation
seem unaffected. My guess, w/o scouring the code, is you are looking
for a comma separating the key=>value pairs int the attribute hash.

This is a serious problem for me, as it crops up all the time. We
create a series of elements (divs, trs etc.,) in a block, then combine
the block variable with something else to dynamically generate an id
(that we use later in a form or with some RJS call.) I can trick it in
most cases, but I want to DRY it with a helper.  I should be able to
pass any number of args to my helper.

Also, I could, I suppose, use <div id="{{{= myhelper(arg, 1)
}}}"> but
that looks ugly in the designer, and I''d rather not.

Ed


-- 
Ed Howland
http://greenprogrammer.blogspot.com

On 1/31/07, Ed Howland <ed.howland at gmail.com>
wrote:
>
> I ran into this before, but I can''t find any email from me about
it.
> Sorry if this is a repeat, but the problem persists in MV 0.3.1
>
> If you have a helper method that you want to evaluate in a construct like:
>
> <div mv:attr=":id => #{myhelper(arg)}"></div>
>
> it legitimately renders it so:
> <div id="<%= myhelper(arg) %>"></div>
>
> But if you increase the argument count to more than 1, e.g.:
> <div mv:attr=":id => #{myhelper(arg, 1)}">
>
> It renders:
> <div></div>
>
> You can try this in the interactive render. Perhaps it has something
> to do with the commas? In any case, the bit between the
''#{'' and ''}''
> should be dropped as is into the erb output. No parsing at all should
> be done on this string.
>
> In my case, I could not create an array for the args because it was a
> mv:attr at the same level as the mv:block and one of the args was the
> bound variable ({|arg2| ...} of the block. In the end, I created a
> closure with the other arg and called p.call(arg2) I don''t think I
> should have had to do that.
>
> It only seems to occur with commas. Periods and other Ruby punctuation
> seem unaffected. My guess, w/o scouring the code, is you are looking
> for a comma separating the key=>value pairs int the attribute hash.
>
> This is a serious problem for me, as it crops up all the time. We
> create a series of elements (divs, trs etc.,) in a block, then combine
> the block variable with something else to dynamically generate an id
> (that we use later in a form or with some RJS call.) I can trick it in
> most cases, but I want to DRY it with a helper.  I should be able to
> pass any number of args to my helper.
>
> Also, I could, I suppose, use <div id="{{{= myhelper(arg, 1)
}}}"> but
> that looks ugly in the designer, and I''d rather not.


Thanks for the email Ed. I will try to get the fix in with the others we are
preparing right now. Should be out very soon.

Blessings,

Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/masterview-users/attachments/20070131/a090fb53/attachment.html

On 1/31/07, Ed Howland <ed.howland at gmail.com>
wrote:
>
> I ran into this before, but I can''t find any email from me about
it.
> Sorry if this is a repeat, but the problem persists in MV 0.3.1
>
> If you have a helper method that you want to evaluate in a construct like:
>
> <div mv:attr=":id => #{myhelper(arg)}"></div>
>
> it legitimately renders it so:
> <div id="<%= myhelper(arg) %>"></div>
>
> But if you increase the argument count to more than 1, e.g.:
> <div mv:attr=":id => #{myhelper(arg, 1)}">
>
> It renders:
> <div></div>

I have tested this in the trunk and it is resolved. (We had fixed one of the
parsing functions)

So you can get this with the next release, which is due out any time now.

It''s also available in the trunk.

I added this test to insure that it works

  def test_attr_eval_helper_with_multi_params
    template = <<-END
      <div mv:generate=''foo/bar''>
        <span class="red" mv:attr=":id => #\{myhelper(arg,
1)\}">foo
bar</span>
      </div>
    END
    expected = {
      ''foo/bar'' => "<div><span
class=\"red\" id=\"<%= myhelper(arg, 1)
%>\">foo bar</span></div>"
    }
    assert_template_result expected, template
  end


Blessings,

Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/masterview-users/attachments/20070220/d996067b/attachment-0001.html

On 2/20/07, Jeff Barczewski <jeff.barczewski at gmail.com>
wrote:
> On 1/31/07, Ed Howland <ed.howland at gmail.com> wrote:
> > I ran into this before, but I can''t find any email from me
about it.
> > Sorry if this is a repeat, but the problem persists in MV 0.3.1
> >
> > If you have a helper method that you want to evaluate in a construct
like:
> >
> > <div mv:attr=":id => #{myhelper(arg)}"></div>
> >
> > it legitimately renders it so:
> > <div id="<%= myhelper(arg) %>"></div>
> >
> > But if you increase the argument count to more than 1, e.g.:
> > <div mv:attr=":id => #{myhelper(arg, 1)}">
> >
> > It renders:
> > <div></div>
>
> I have tested this in the trunk and it is resolved. (We had fixed one of
the
> parsing functions)
>
> So you can get this with the next release, which is due out any time now.
>
> It''s also available in the trunk.
>
> I added this test to insure that it works
>
>   def test_attr_eval_helper_with_multi_params
>     template = <<-END
>       <div mv:generate=''foo/bar''>
>         <span class="red" mv:attr=":id =>
#\{myhelper(arg, 1)\}">foo
> bar</span>
>       </div>
>     END
>     expected = {
>       ''foo/bar'' => "<div><span
class=\"red\" id=\"<%= myhelper(arg, 1)
> %>\">foo bar</span></div>"
>     }
>     assert_template_result expected, template
>   end
>
Jeff, are the escapes of the curly-braces needed for all double-quated
string evals? Does that need to be documented somewhere?

Ed


>
> Blessings,
>
> Jeff
>
> _______________________________________________
> Masterview-users mailing list
> Masterview-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/masterview-users
>

-- 
Ed Howland
http://greenprogrammer.blogspot.com

On 2/20/07, Ed Howland <ed.howland at gmail.com>
wrote:
>
>
> Jeff, are the escapes of the curly-braces needed for all double-quated
> string evals? Does that need to be documented somewhere?
>
>
Actually no, you don''t need to do anything like that. This was only
necessary because the here doc (<<) in my test case tries to eval things.
You don''t need to do that in your templates.

Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/masterview-users/attachments/20070220/d3c6e9ea/attachment.html