I hope you don't mind that I bounced this over to Google Groups to
keep other developers in the loop.
Please dig in if you are inspired. I agree: a remote branch is the way
to start.
Are you sure that we want a BAR(R) module? I think that you'll want to
push duplicated logic down to the Competition super-class, but we'll
see once you look at the code. The BARs, despite their similar names,
feel fairly different to me. I've also found that duplicate
competition code can usually be made quite abstract, and apply to all
competitions, not just the BARs or cross series.
I'm also not a big fan of the ASSOCIATION switches. I'd rather keep
the current competitions as sparse classes that spec out the rules at
a high level. Like:
class ObraBar < Competition
members_only false
…
end
class WsbaBar < Competition
members_only true
…
end
But not:
class Barr < Competion
if ASSOCIATION.short_name == "obra"
members_only false
elsif ASSOCIATION.short_name == "wsba"
members_only true
end
end
While I like to keep things DRY, I'm also concerned about keeping it
easy to figure out how a competition works. A bad example: to
understand the CrossCrusadeOverall, you need to look at Overall,
Competition, Event, and maybe Race and Result. Bad encapsulation on my
part. In the long run, perhaps Competition should be a module that
consolidates all the code instead of an Event superclass.
I wonder how many times I misspelled "competition" in this email. ;)
Scott
On Aug 28, 2009, at 11:44 AM, Ryan Rickerts wrote:
> Speaking of tackling and modulizing...
>
> After this fix, I want to try and put BAR in a Module and centralize
> some of the shared methods between MBRA, WSBA, OBRA, etc. Hopefully
> even load some methods or query parameters dynamically based on the
> ASSOCIATION.short_name in local/config/environment.rb?
>
> Was going to try this in a git branch called "bar_refactor", and
> involves moving files around. Let me know if you have any tips,
> concerns, conflicting efforts, etc.
>
> Thanks,
> RyanR>