| Age | Commit message (Collapse) | Author |
|---|
|
3479-refactor-table_builder-helper
|
|
|
|
|
|
Refs #3657
|
|
Refs #3657
|
|
I hadn't used this syntax before because I think I had tried:
@referential.decorate
without the assignment. Of course it didn't work at the time, but I
didn't notice so I switched to this syntax which did work.
Use the shorter one because it's a bit cleaner.
Refs #3479
|
|
This is no longer necessary. I had put it in because I was getting an
error, but it turns out that error was probably a result of me
redefining `PaginatingDecorator` inside "referential_decorator.rb". Now
that we're using the `PaginatingDecorator` that Jean-Paul created
originally, we no longer have a problem.
Refs #3479
|
|
3479-refactor-table_builder-helper
|
|
|
|
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
|
|
Add a new `ReferentialDecorator` that we can use to define the links
that appear as buttons in the header of the `/referentials/:id` page.
The idea is that these links will take the place of the existing view
code and in the view, we'll instead loop over the links provided by the
decorator and render them as buttons.
I decided to do it this way because there's a requirement that the links
in the gear menu in tables show the same links that appear in the header
of the page. So the Workbenches#show page would show a table of
referentials, and their gear menu links should ostensibly be the same as
the header links in the Referentials#show page.
My goal was to abstract links, and try to separate them from the
presentation layer. Still having trouble with this though. I created a
new `Link` class to represent a link. We can then use this in the
template to create a `link_to`. It becomes messy, though, when we want
to put other elements inside a certain link, as evidenced by the
`:delete` link. Don't like how that's done, but still working out the
best approach to make it cleaner.
Refs #3479
|
|
Method was indented by three spaces. Should be two.
Refs #3479
|
|
|
|
Refs #3662
|
|
Refs #3654
|
|
|
|
|
|
Signed-off-by: Thomas Shawarma Haddad <thomas.haddad@af83.com>
|
|
|
|
Refs #3567
|
|
Signed-off-by: Thomas Shawarma Haddad <thomas.haddad@af83.com>
|
|
|
|
|
|
|
|
Refs #3567
|
|
Refs #2347
|
|
It turns out as described in 44712fe052e0c554c0510d4665a35c66540ffa05
that the vehicle journeys without time tables filter should only show
those vehicle journeys without time tables when the toggle is set to
"Oui".
* Rename our filter method so it makes sense for the new logic
* Use the updated `VehicleJourneys.without_time_tables` method name
* Change the query param check from "false" to "true" to enable the
filter on "Oui"
Refs #3427
|
|
Refs #3445
|
|
Like we did in d0544404ffd77d276a5db5e8cacc85e26bc5a272 with
`filter_without_time_tables`, add a similar method to extract the
departure time filter from `#collection`. This allows us to keep the
`#collection` method a little cleaner.
Add `maybe_` prefixes to both aforementioned new filter methods because
we aren't guaranteed to be filtering. It depends on the contents of the
request parameters received.
Remove the comment describing the date range filter now that it has a
method name.
Refs #3427
|
|
If specified by the frontend via a `q` sub-parameter, filter out vehicle
journeys that don't have associated `TimeTable`s.
Split this filter & params check into a separate method to keep the
`collection` method a little cleaner.
Refs #3427
|
|
Refs #3406
|
|
Refs #3406
|
|
|
|
Refs #3406
|
|
Refs #3384
|
|
This section is a little dense. Comment what it is to make it more
obvious.
Refs #3370
|
|
This method is superseded by
`VehicleJourney.where_departure_time_between`.
Refs #3370
|
|
Handle temporary fixes from 972500267f28f233d5670277c02d43fae5ad8e7b and
1f6fb9c73206f3984d2f942d5d16fb9c094b2164. Restore the JavaScript because
that should function the same way now.
Remove the Ransack call as we've moved this departure time filter
outside of Ransack and into our own custom method in order to eliminate
a duplicated "JOIN" call on "vehicle_journey_at_stops" collision between
the `.with_stops` query and Ransack. The new filter lives in
`VehicleJourney.where_departure_time_between`.
Refs #3370
|
|
There's a `params[:q][:vehicle_journey_without_departure_time]`
parameter coming in from the frontend that's supposed to allow it to
decide whether or not to include vehicle journeys that have nil stops.
Allow this parameter to function for the
`VehicleJourney.where_departure_time_between` method by conditionally
checking an input parameter to determine whether to add the "OR"
condition onto the "WHERE" filter.
Refs #3370
|
|
Add our custom departure time range filter to the query. We pass the
times sent from the frontend into the query in order to get the correct
vehicle journeys back.
Copied the `if params[:q]` check from `#ransack_periode_filter`, but
added an additional condition on the existence of
`:vehicle_journey_at_stops_departure_time_lteq` instead of blatantly
assuming it's there just because its `..._gteq` counterpart is.
Adding the filter necessitated some modifications to the
`VehicleJourneys.departure_time_between` method. We needed to remove the
`SELECT DISTINCT` and join parts of the query, reducing it to a simple
"where" condition.
These removals were due to the nature of the combination of this method
with `VehicleJourneys.with_stops`. The `.with_stops` method already does
a join on `vehicle_journey_at_stops`, and there's already a `SELECT
DISTINCT` applied to the controller's query.
Made the decision to limit this method's use to this specific use-case,
and thus expect DISTINCT and the necessary join to already be defined on
the `ActiveRecord` query object. We modify the test to implement this
requirement.
Finally, rename `.departure_time_between` to
`.where_departure_time_between` to further indicate that this is a
simple `where` condition, without the required extras.
Refs #3370
|
|
Refs #3358
|
|
Refs #3358
|
|
Ref #3347
|
|
|
|
Nullification of foreign keys in delete route moved from an `after_destroy' to a `before_destroy' hook.
(Motivation: Seemed like a good idea)
|
|
|
|
Use the class method to get the vehicle journeys in the proper order of
departure time ascending.
The `.with_stops` method replicates this same SQL sequence of joins and
order.
Refs #3268
|
|
Correctly sort journeys. They used to be sorted correctly this way, but
after d7c6d5ce602219b9bfa47686542dd575f1fe2e50 or
c3d207301d17538b65d2a1239ce0acf642942ce9, the sorting got messed up
because of the join.
Here we leverage `journey_patterns.departure_stop_point_id` in order to
get the first stop and sort by that stop's departure time. Query
solution thanks to Luc and Alban, who remembered that a reference to the
first stop point is stored so we can leverage that for complex things
like this.
Refs #3268
|
|
easy change locale for testing and developping translations
|
|
Refs #3298
|
