Multiple conditions on filters

Is there a more efficient way of coding this?

before_filter :f1, unless: :test?
before_filter :f2, only: :show, unless: :test?

I don’t want to call test? twice as it is not trivial.

Colin

can you memoize the result of test? assuming it wouldn’t change between
callbacks? otherwise, write one callback and perform all the tests,
including the action check for only show inside it?

On 29 August 2015 at 16:08, tamouse pontiki [email protected]
wrote:

can you memoize the result of test? assuming it wouldn’t change between
callbacks? otherwise, write one callback and perform all the tests,
including the action check for only show inside it?

Yes I could do either of those but neither is aesthetically pleasing,
which is why I wondered whether there was a better solution. Will
probably plump for the first as the second filter would have to be
called something like
f1_unless_test_and_f2_if_show_unless_test
for it to make any sense when read as f1 and f2 are unrelated.

Colin

On 29 August 2015 at 20:07, Elizabeth McGurty [email protected]
wrote:

What may be more aesthetically pleasing to you is the structure. although I
am not certain:

before_filter :f2, :only => :show do |c|
unless c.this.test?
end

Totally not certain about the syntax, but I think that the spirit of what I
am offering may be helpful

Thanks for the suggestion, but I am not sure how that helps with the
f1 filter and the repeated call of test?()

Colin

On Sat, Aug 29, 2015 at 10:26 AM, Colin L. [email protected] wrote:

f1_unless_test_and_f2_if_show_unless_test
for it to make any sense when read as f1 and f2 are unrelated.

I completely agree with the lack of aesthetics.

Since f1 and f2 are completely unrelated, except for being gated by
test?,
I’d opt for keeping their invocation separate. Temporal coupling isn’t
useful coupling.

Sorry, I’ve got nothing else. :frowning:

Tamara

On 1 September 2015 at 13:29, tamouse pontiki [email protected]
wrote:

Yes I could do either of those but neither is aesthetically pleasing,
I’d opt for keeping their invocation separate. Temporal coupling isn’t
useful coupling.

Sorry, I’ve got nothing else. :frowning:

OK, thanks. I have gone for memorising the intermediate values in the
test filter as I know they are not going to change within a request.
I had hoped there might be some clever way of massaging the
before_filter syntax that would provide a solution but I suspect that
is not possible.

Cheers

Colin

Colin, please show your result…

What may be more aesthetically pleasing to you is the structure.
although I
am not certain:

before_filter
http://apidock.com/rails/ActionController/Filters/ClassMethods/before_filter
:f2, :only => :show do |c|
unless c.this.test?
end

Totally not certain about the syntax, but I think that the spirit of
what I
am offering may be helpful

Liz

And I am also super confused as to the notion of ‘memorising’. What
does
that mean? Kids memorise the alphabet and times tables, what does that
metaphor mean in terms of Ruby and Ruby on Rails? Memorising is a
process
of repeatedly iterating through a series that must eventually be held in
one’s memory. Does Rails have some neural process of educating itself
in
neural memorising?
Liz

On 1 September 2015 at 15:43, Stewart M. [email protected]
wrote:

I don’t see any reason why not to wrap something like this in a
before_filter block/lambda. That way you avoid the silly function name, and
I wouldn’t consider that coupling.

I am not entirely sure what you mean, can you show how my code

before_filter :f1, unless: :test?
before_filter :f2, only: :show, unless: :test?

would look in that case please

Also, Liz, I think he means “record or store the relevant information in
another format”, such if the response was a large object or collection and
Colin only needed to know that there were more than ten, Colin might set
@morethanten to true.

Correct

Colin

I don’t see any reason why not to wrap something like this in a
before_filter block/lambda. That way you avoid the silly function name,
and
I wouldn’t consider that coupling.

Also, Liz, I think he means “record or store the relevant information in
another format”, such if the response was a large object or collection
and
Colin only needed to know that there were more than ten, Colin might set
@morethanten to true.

On Tue, Sep 1, 2015 at 10:29 AM, Elizabeth McGurty [email protected]

As you read through Ruby code, you may see this construction:

@foo ||= some_expensive_operation(parameters)

That’s known as memoizing (take a memo) or memorizing (or memorising if
you’re in England).

What it does is take the existing value if the expensive operation has
already run once, or return and store for later the result of the
expensive operation. It’s a one-liner in-memory cache.

Walter

Like:

before_filter do

result = test?

unless result
  return  f1 && ( action_name !="show" || f2 )
end

end

That’s playing some “ruby golf” , you can pull that apart to make it as
readable as you want ( honestly I actually perfer ‘and’ and ‘or’ but
that
would result in some more ()s ).

On 1 September 2015 at 15:41, Elizabeth McGurty [email protected]
wrote:

And I am also super confused as to the notion of ‘memorising’. What does
that mean? Kids memorise the alphabet and times tables, what does that
metaphor mean in terms of Ruby and Ruby on Rails? Memorising is a process of
repeatedly iterating through a series that must eventually be held in one’s
memory. Does Rails have some neural process of educating itself in neural
memorising?

The test filter (which is not actually called that of course, it has a
name meaningful in the context of my application) does a fair amount
of db lookup, based on the request params, and comes up with a true or
false answer. My mod is, in the test filter, to test a class variable
(lets call it @test_answer) and if it is nil then to run the db
lookups, caculate the answer true or false, save it in @test_answer
and return that value. If it is not nil then I just return the value.
The result is that the first time it runs it does the lookup, the
second time it just returns the answer

In practice that just turns into something like
def test?
@test_answer ||= do_the_lookup_and_calcs()
end

Colin

On 1 September 2015 at 16:33, Elizabeth McGurty [email protected]
wrote:

Very nice! The all important ||=

Now if I could just convince you of the benefits of inline posting
rather than top posting then I would feel my life was worth while
after all :slight_smile:

Colin

Very nice! The all important ||=

Too existential for me… I just click the button…
All the best…
Liz

On 1 September 2015 at 15:54, Stewart M. [email protected]
wrote:

end

That’s playing some “ruby golf” , you can pull that apart to make it as
readable as you want ( honestly I actually perfer ‘and’ and ‘or’ but that
would result in some more ()s ).

Yes I see, thanks for the explanation.

Colin

So my suggestion of do had some value?

I have no idea as to what you are talking about…Etiquette??? I think
that I always follow it…

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs