1396 update reduced datums for existing target via data service#1426
1396 update reduced datums for existing target via data service#1426
Conversation
…t-via-data-service
…t-via-data-service
…-service' of https://github.com/TOMToolkit/tom_base into 1396-update-reduced-datums-for-existing-target-via-data-service
| """Builds the query parameters from the form data""" | ||
| raise NotImplementedError(f'build_query_parameters method has not been implemented for {self.name}') | ||
|
|
||
| # Include this method if you wish for the TOM to be able to query data for an individual Target. |
There was a problem hiding this comment.
I'm looking for advice here. I'm using the existence of this method in forms.py:69 to test whether something should be in the form choices. I'm curious if there is a better way to do this.
This way seems imperfect because it doesn't show up in the docs now and breaks the symmetry for other methods being used here.
Fingel
left a comment
There was a problem hiding this comment.
This is nice. Having all the code related to a single service in one module is compelling.
Having spent the time working on the Alerce implementation, I would say this is good but there is one area I think improvements could be made: making the code more self-documenting.
I spent a lot of time trying to figure out what various function parameters and return values were or were supposed to be. I resorted to a lot of print() debugging for parameters like query_parmeters target, target_result, query_results and data. Are they dictionaries? Objects? If they are dictionaries, what keys do they have? There was a lot of tracing function calls to understand how the data flowed.
The documentation might cover these calls in english, but it's really helpful to have the feedback directly in the code/editor as well. There are a few things that might be considered:
Use actual objects where it makes sense instead of dictionaries. If an object doesn't make sense because it would have no methods, use a dataclass (designed for this very purpose). At the least, type annotations would go a long way to at least differentiate between objects and dictionaries.
That's it. Nice work!
phycodurus
left a comment
There was a problem hiding this comment.
One other comment we talked about was an <hr> above the version (and maybe one between the Form and the "Run/Save Query" row).
docs/brokers/create_dataservice.rst
Outdated
|
|
||
|
|
||
| .. code-block:: html | ||
| :caption: my_dataservice/partials/myservice_simple_form.html |
There was a problem hiding this comment.
We talked about double-checking that the filename :caption:(s) are correct.
Also, the agreement between these /path/to/partial return values and where the partials are in the file system (and how they are named (extention or no)) might be worth an explicit mention or trouble-shooting tip.
|
|
||
| Simple forms are often a single field that will find expected results. Such as a Target name or ID field. | ||
|
|
||
| This consists of adding the ``get_simple_form_partial()`` method to MyDataService and then creating the partial. |
There was a problem hiding this comment.
These methods fall more under the responsibility of the Form class.
(This refactor would affect the get_context_data() method of the View where they are used).
|
Refactor:
|
…t-via-data-service
Adds Redundancy for new data from Data Services
Adds Docs
Adds form to Target detail page to Target Detail page to get new data from Data Service.