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?
endTotally 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. 
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.
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 
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…