Yes, you're right, the parser didn't realize that #{} wasn't normal
string content. This is now fixed.
- Nathan
Robin wrote:
> I suspect this patch has broken my code. I do the following a lot:
>
> %span{:id => "more_info_#{store_item_type[:item_type_id]}"}
>
> With this new patch, the #{} content is not being evaluated at all and
> has broken many of my pages.
>
>
> On Jun 2, 6:45 am, Nathan Weizenbaum <[EMAIL PROTECTED]> wrote:
>
>> Alright, I've modified this a bit and added it to trunk. Thanks a bunch.
>>
>> - Nathan
>>
>> Tom Bagby wrote:
>>
>>> parsing_literal_hashes.diff handles this. It touches more things than
>>> I originally intended because of finding some bugs as I went.
>>>
>>> For example:
>>>
>>> - Attribute hashes built internally all assume that keys are symbols.
>>> This was causing weird cases of spitting out tags with multiple class
>>> or id attributes. I chose to start forcing keys to strings. The
>>> alternative of interning everything is also an option.
>>>
>>> - The object ref syntax was not (still isn't quite) consistent in how
>>> it overrides existing classes or id's. Have tried to fix this to an
>>> extent.
>>>
>>> - I'm not sure how this test is supposed to work:
>>> assert_equal("<p escaped=\"q'uo"te\">\n</p>\n",
>>> render("%p{ :escaped => 'q\\'uo\"te'}", :attr_wrapper => '"'))
>>>
>>> Since the actual test code is in double quotes, the double backslash
>>> turns into a single backslash, but quoting the single quote should be
>>> left in when we actually eval this since single quotes don't do escape
>>> sequences, which means that the asserted result should have a
>>> backslash in there, so ... I changed it to what I thought it should be
>>> but I'm unclear on what this is even testing.
>>>
>>> As per recent comments about patching protocol, maybe this is a bunch
>>> of stuff in one diff, but it's all fallout from doing the literal
>>> hashes thing and then making tests not fail. Can break it up into
>>> steps if necessary.
>>>
>>> -Tom
>>>
>>> On May 30, 8:55 pm, Nathan Weizenbaum <[EMAIL PROTECTED]> wrote:
>>>
>>>> Very good. Committed.
>>>>
>>>> I've also been meaning to get around to making string-only attributes
>>>> parsed at compile-time. That'll also be useful for allowing people using
>>>> :suppress_eval to have attributes.
>>>>
>>>> - Nathan
>>>>
>>>> Tom Bagby wrote:
>>>>
>>>>> Uploaded preparse_class_ids.diff
>>>>>
>>>>> Pretty straightforward, moves processing of class and id strings to
>>>>> engine and not buffer. Nice little perf boost results:
>>>>>
>>>>> Before: Haml/ERB: 2.23403
>>>>> After: Haml/ERB: 1.96521
>>>>>
>>>>> -Tom
>>>>>
>
>
> >
>
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Haml" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/haml?hl=en
-~----------~----~----~----~------~----~------~--~---
