Use Django REST framework about whatsup

[adrienbrunet]

I had a look at it today. I'm really short on time so I can't do it right now even I'd really like to.
IMO, we need to add first a form to handle the query. It would be really cleaner to use a clean function to handle the query rather than request.GET.get('attribute', '').

It will make the view thiner and easier to understand. What the views does:
it retrieves the Target model and filter it with the parameters from the form. The data validation should occur in a form clean rather than inside the view.

When we have that, it would be even easier to add DRF. It is easy to create a model API endpoint, and filter the queryset with some parameters. The tricky part seems to rely here on that form clean.

With a form, we could also add widgets (such as a datetime picker...!!) and the html will be much simpler. You don't need to write all the form html, django can do it for you. Adding sites would be even easier if we consider a foreignkey to a new model with the coordinates.

You might want to create tickets from that comment. Again, I'm truly sorry to write more comments than actual code. I lack some free time to help you more.

I have started to add a sphinx structure for the project. Do you have any docs that you've written which isn't in the repo? It would be helpful. The docs I'va generated are quite empty so far.

[zemogle]

Thanks for the suggestions. This package is only providing an API end-point for use inside the telescope observing interface. At present a form never gets shown to the user (the form you can see in urls.py is just to help with testing a bit). The observing interface constructs the query string parameters. It would be excellent to have the form available more generally (and develop the list of objects including ones suitable for amateur telescopes).

It looks like DRF does validation using serializers. How about I start the ball rolling by thinning the view down in this way?

[adrienbrunet]

I'm not sure to understand. There IS a form. When you "runserver", you get a page with a form to fill with a date and a location to select from a list. If it's only for testing purpose, we should get rid of it and write some test instead of an html mockup. It would be easier to maintain and a good test is self-explainatory while a bad mock up doesn't reflect the behaviour of your app. 😃

To filter against parameter querys, see http://www.django-rest-framework.org/api-guide/filtering/#filtering-against-query-parameters

I have the feeling that the project is splitted in too many really small projects. We could have more benefits to work on a larger picture but you may have your reasons not to do so. 😔 I'm trusting you on the architecture of the project

[zemogle]

😊 You found me out! We can replace that with a Django form, or just remove it because Laurent has written some excellent tests which make it redundant.

What did you mean about the larger picture? If you mean the full observation interface, it is a longer term plan for us to open that up but it is a HUGE piece of code. Maybe a functional diagram would help, to show how different apps fit together?

[adrienbrunet]

Maybe yes. There is a lot of overhead to maintain different apps for too small part of code. Maybe there is a ot we could refactor. But it is a start. Let's get that app working, then we'll talk bigger apps ❗

[zemogle]

Now using DRF in production 😄

[adrienbrunet]

👍