Add a generic view API with view builder

[jc0n]

@mhrivnak: We discussed this via IM recently so I won't provide too much detail here. This is for the sake of tracking the change.

---

Most of the views are all the same in terms of the wrapping get_filtered and performing a few simple (potentially nested) merges. I have created a generic ViewBuilder object which allows this work to be encapsulated elsewhere. It provides a couple of benefits:

• Simplifies the creation of new views
• Promotes a consistent implementation for all views across different managers
• Enhances readability
• Does not change the current API. Should not break backwards compatibility.

A demonstration of the ViewBuilder semantics applied to the AssignmentManager.transcript_view, one of the more complicated in terms of required nested merges:

   @service_method
    def transcript_view(self, auth_token, filters=None, fields=None,
            user_id=None):
        view = self.build_view(
                filters={'exact': {
                    'status': 'completed',
                    'user': user_id or auth_token.user_id
                    }},
                fields=('user', 'status', 'date_started', 'date_completed',
                        'achievement_awards'),
                merges=(
                    ('task',
                        ('name', 'title', 'type', 'description',
                         'achievements')),
                    ('task.achievements',
                        ('name', 'description')),
                ))
        return view(auth_token, filters, fields)

[mhrivnak]

Please add a comment to the docblock for FlatMerge.call and NestedMerge.call about what the "result" parameter should be. I am currently trying to bug-fix and am having to read backwards through your code to figure this out.

For the future, all methods should have parameters documented, unless it's something very common like "auth_token", or is a very standard method definition in the API.

[jc0n]

I'll update the documentation.

For now the quick explanation is that those Merge classes are somewhat of a strategy pattern. The call defines the implementation and it is applied to a result (a list of dictionaries as returned by Getter) here https://github.com/TireSwingSoftware/openassign-server/commit/98515addade85b331bd0dabb24d712dfc09a1d33#L1R961. The initial result is https://github.com/TireSwingSoftware/openassign-server/commit/98515addade85b331bd0dabb24d712dfc09a1d33#L1R956. However, it changes with each merge.

[mhrivnak]

Ok. It looks like there are lots of important methods that are missing documentation, like View._parse_foreign_key. View._raw_query seems important, but there's no documentation at all. There are many others.

Please review all the code you wrote related to this task, and add method documentation where missing. Each method should have:

• basic explanation of its purpose
• explanation of each parameter, what type it should be, and perhaps where it might come from
• description of what will be returned

[jc0n]

@mhrivnak: You can sign off on this one. It LGTM.

[jc0n]

@mhrivnak: New revision is up. You may want to take a look.

[mhrivnak]

Thanks! Feel free to close this issue if you're done with it.