Closed danielballan closed 5 years ago
I like this approach mainly as it reduces the amount of 'duplicate' code we are seeing at the moment in the suitcase.* files. As you say it also gives both naming conventions, the higher level one and the lower level one which I also find appealing.
This has been resolved with PR#1
A thought I had on the way home that I just want to scribble down for discussion tomorrow:
The availability of
event_model.DocumentRouter
, which landed after we started work on suitcase-csv, invites another promising possibility for how to structure suitcases. We could move the business logic into aDocumentRouter
subclass, trading the wall ofif name == ...
blocks for corresponding methods onDocumentRouter
. We would still include a top-level function that consumes a generator (export
/ whatever we name it). Only the internal implementation would change: that function would become a thin wrapper around the callable class. Both would be public.Let's consider the what this would make easy and what it would make hard.
Pro:
Avoid the boiler plate of the if statements, especially the layout munging here:
...which
DocumentRouter
does for free, munging any events and bulk_events internally and then routing through itsevent_page
method.I expect this would appear much more sensible to prospective suitcase authors unfamiliar with the arcana of the event model's history.
Con:
Is this worth trying to see how it compares?