diff options
| author | Teddy Wing | 2017-06-14 11:14:16 +0200 |
|---|---|---|
| committer | Teddy Wing | 2017-06-14 11:40:54 +0200 |
| commit | 734de24950c6ae490d4781799c8a6d805944e6aa (patch) | |
| tree | be5fc5d25253c04b189d97046220e7bee9052972 /script | |
| parent | 1c70b12b7c71a428bfafc601d5538392ad2113bb (diff) | |
| download | chouette-core-734de24950c6ae490d4781799c8a6d805944e6aa.tar.bz2 | |
Workbenches#show: Use common referential action_links in table gear menu
Get our `ReferentialDecorator` working for a collection of
`Referential`s. We decorate the `ActiveRecord::Relation` of referentials
that gets passed to the table builder. This enables us to call the
`#action_links` method on those referentials, getting a list of links
that should appear in the gear menu. From that list, we can generate the
proper HTML to stick into the menu.
This was my first test of reusing the `#action_links` for both the
header buttons in Referentials#show and the list in Workbenches#show.
Ran into some trouble.
The issue was that decorating the collection with Draper's defaults
doesn't delegate methods on the collection object (in other words,
`ActiveRecord::Relation`). We call methods on the collection in our
code, and doing so on our new decorated collection caused errors.
As a first step to get around the first batch of errors, I changed the
`_filters.html.slim` template to call `#human_attribute_name` on
`Referential` model directly, instead of on the Relation. There was some
additional weirdness that Luc tipped me off to as we have a
`Chouette::ActiveRecord` class that defines its own
`#human_attribute_name` method. Switching the callee to the model fixed
this error.
Subsequently, I ran into a problem in the `TableBuilderHelper`. In that
code, we call `collection.model` to determine the class of objects in
our table. Now that I think about it, maybe we should just pass this
information when calling `table_builder`. Let's do that because it would
be better. Anyway, to enable that `ActiveRecord::Relation#model` method
to be called, I created a Draper `CollectionDecorator` that delegates
the `#model` method. This allows us to call `#model` on the decorated
collection of referentials (or other objects).
Finally, I ran into another delegate problem for our pagination method
calls. Fortunately, Draper provides some code for a
`CollectionDecorator` for pagination. I copied this and used it in
conjunction with my custom `ModelDecorator` to properly delegate all
necessary collection methods for a collection of Referentials.
Stuck my `PaginatingDecorator` and `ModelDecorator` right in the
`referential_decorator.rb` file for now just for testing until I got
things working. Needed to import this file in the controller where we
decorate the collection. Not entirely sure why but my guess is that it's
because the loader connects classes to file names and we have several
different classes in that file. Maybe I'm totally wrong on that. Anyway,
will be moving those classes to separate files later.
In the controller, decorate our `Referential` collection with the
`ModelDecorator` (which inherits from `PaginatingDecorator`, giving us
those delegated methods), and ensure the objects inside the collection
get decorated with our original `ReferentialDecorator`.
In `TableBuilderHelper#build_links`, comment out all the existing link
building code and instead map over the `#action_links` provided by the
decorator. Currently this should only work for `Referential`
collections, but the idea is to use that pattern for all table objects.
NOTE: We should add a doc comment to the table builder that tells people
that they need a decorator for their model in order for it to work.
Refs #3479
Diffstat (limited to 'script')
0 files changed, 0 insertions, 0 deletions
