On Thu, Nov 5, 2015 at 9:26 AM, Kevin Deisz wrote:
> Hi there,
>
> Seems like in the positive condition, link_to_if and link_to_unless are
> inconsistent. When I send a block to link_to (or for that matter anything
> else that calls content_tag) the block is used to determine the content in
> the
It would necessarily break backward compatibility with the positive
condition, but that's the point that I'm making. If it's not going to be
accepted that's fine, I was just hoping to understand why.
On Thu, Nov 5, 2015 at 4:18 PM, Rafael Mendonça França <
rafaelmfra...@gmail.com> wrote:
> If tha
If that is possible without breaking backward compatibility go ahead, but I
can't think in a way to make it backward compatible.
On Thu, Nov 5, 2015 at 2:00 PM Kevin Deisz wrote:
> I get that that's the way that it works, my point was that it's
> inconsistent. Right now you can't achieve the nor
I get that that's the way that it works, my point was that it's
inconsistent. Right now you can't achieve the normal link_to behavior when
the condition is met. We can preserve the behavior for the negative case
and still get the content_tag block benefit for the positive case.
On Thu, Nov 5, 2015
It is the way they work. See the documentation. The block is used only when
the condition is not met.
On Thu, Nov 5, 2015 at 1:26 PM Kevin Deisz wrote:
> Hi there,
>
> Seems like in the positive condition, link_to_if and link_to_unless are
> inconsistent. When I send a block to link_to (or for t
Hi there,
Seems like in the positive condition, link_to_if and link_to_unless are
inconsistent. When I send a block to link_to (or for that matter anything
else that calls content_tag) the block is used to determine the content in
the case that "name" is not provided. It gets around this by shi