Open brettcave opened 8 years ago
Hey @brettcave indeed I totally agree that the 1.1.1
have an architecture that make it extremely hard to extend.
I'm not sure yet if we should even have as much logic on the new version as we had before. The ranking logic we will probably need to keep, but I'm thinking about keep it simple, generate the AR classes and let the user implement their logic by their own. But as I said, I'm not sure yet, once we finish this we might want to start bringing boilerplate logic to the gem.
What are your thoughts about it?
Considering that the model and rake tasks are generated into a project by the Gioco setup task, the only Gioco functionality that is left in the dependency gem are the Core and Ranking classes. The gem works great for it's functionality out the box, but if I want to modify / extend it it becomes difficult with Core being external to the project.
Does it make sense to generate local Gioco::Core and Gioco::Ranking classes during the rake setup task then? The gem dependency could then be scoped to development (e.g. in a bundler group or gemspec
add_development_dependency
) and gives a local resource to allow modification.This suggestion comes from a modification to Gioco in wanting to associate point allocation and badges earned to events - where a user has events and these events earn the user points and badges. The
sync_resource_by_points
needed to be modified to accept anevent
parameter and as a user, I can see how many points I earned with each event, and if that event earned me any badges. I'm not sure if this sort of feature is generic enough to log it as a Core feature request or if it's better to localize the libraries to allow customization - localization seems like a better approach.