search

teknik-eksjo / chronos

A scheduling app that helps teachers submit workday outlines
MIT License
5 stars 5 forks source link

Create backend of base schedule page #81

Open shhmon opened 8 years ago

shhmon commented 8 years ago

Continuing #38 and #79

In order to make this work, we will have to modify the sliders so that the weekdays displayed before them are not hard-coded text values but properties of the individual sliders. We can then use the sliders 'change' event and some Ajax to make the slider detect changes and compare the new data with the one that's already in the database. If changes are detected, Ajax should then POST the new data in the background to the same /base-schedule URL that will then handle the information and push it to the database.

Some nifty solution to avoid too frequent POST requests might also be needed.

shhmon commented 8 years ago

As mentioned in #79, the data model by @Greenheart and @Kallshem is needed to implement this

Greenheart commented 8 years ago

@Catagen Seems like a good start for a solution. The datamodel is ready to be hooked up to some backend-routers since we agreed that the best way to finish the datamodel-methods is to start with the rest of the app and add them as we find a need.

But before we start we need to discuss if we want to send the data to specific API-paths or if we want to handle everything related to the base-schedule submission in one big router-function. For example the router for /base-schedule could become a big function doing way too many things (bad for maintainability). Thoughts? @teknik-eksjo/te13

Greenheart commented 8 years ago

Suggested implementation

Greenheart commented 8 years ago

@teknik-eksjo/te13 I'll work on this feature today, message me if you'd like to join!

Edit: I figured that this depends on #83 since it'll be much easier to test and debug with some existing data. I'll continue there.

Greenheart commented 8 years ago

@teknik-eksjo/te13 Before we can move on with this issue, we need to plan a big chunk of the backend. I'd like us to discuss this on for example Hangouts and then submit notes in this issue.

Limpan commented 8 years ago

Are there any specific issues or questions up for debate?

Greenheart commented 8 years ago

@Limpan The problem is essentially that I don't know where to start. I think some discussions could help me break the problem down and see where to start solving it. Meanwhile, I'm working on the db-script.

hugolundin commented 8 years ago

@teknik-eksjo/te13 Before we can move on with this issue, we need to plan a big chunk of the backend. I'd like us to discuss this on for example Hangouts and then submit notes in this issue.

I don't think that I will have a lot of time to sit down and discuss the matter, but I also feel that I don't really know what are to be done.

Route /base-schedule/update works like an API-endpoint handling post requests sent via AJAX. Would be nice to post json-data here but URL-encoded parameters could work as well. What do you think, URL or JSON? Limit rate of AJAX-posting --> once every 5 seconds? Implement the syncing-feature generally to make it possible to use it for both /base-schedule and /deviations

To add something in the discussion about these questions:

  1. I do not really know what is preferred generally (maybe @Limpan have something to say), but otherwise, we could just choose one of the ways, and try it out.
  2. I think that we discussed this matter earlier, and came to the conclusion that we should try to post ajax on every slider change, if it doesn't decrease performance noticeably.
  3. I think it's more clear and understandable in code to divide it, but this could need some further discussion too. Do @Limpan have any thoughts?
Greenheart commented 8 years ago

I think that we discussed this matter earlier, and came to the conclusion that we should try to post ajax on every slider change, if it doesn't decrease performance noticeably.

Sounds like a good idea!

I think it's more clear and understandable in code to divide it, but this could need some further discussion too.

@hugolundin You're referring to dividing the /base-schedule-routes? Me and @Catagen discussed having one function handling the POSTs and one for the GETs

Next, we need to discuss in what order different objects will be created.

For example: Before a Teacher can login using their SSO-email and edit their Schedule (the wrapper object for 1 BaseSchedule & N Deviations), there has to be a WorkPeriod that the Teacher's Schedule is related to. (The reason for this is that a free-floating Schedule is kind of useless. Schedules are meant to exist in the context of a specific WorkPeriod)

Because of the dependency-chain described above, there has to be an Admin that

  1. creates a WorkPeriod A
  2. sends SSO-emails which allow Teachers to edit their Schedule for WorkPeriod A

@teknik-eksjo/te13 thoughts on this?

hugolundin commented 8 years ago

@hugolundin You're referring to dividing the /base-schedule-routes? Me and @Catagen discussed having one function handling the POSTs and one for the GETs

I think I don't really understand what you have discussed earlier about this issue, but I would like to have @Limpan and the rest of @teknik-eksjo/te13's thoughts about this before we move on to combine or divide things in other ways than usual.

For example: Before a Teacher can login using their SSO-email and edit their Schedule (the wrapper object for 1 BaseSchedule & N Deviations), there has to be a WorkPeriod that the Teacher's Schedule is related to. (The reason for this is that a free-floating Schedule is kind of useless. Schedules are meant to exist in the context of a specific WorkPeriod)

Agreed.

Because of the dependency-chain described above, there has to be an Admin that

  1. creates a WorkPeriod A
  2. sends SSO-emails that links every Teacher to edit their Schedule for WorkPeriod A

before the Teacher can edit their Schedule.

Sounds about right but I dont really understand:

sends SSO-emails that links every Teacher to edit their Schedule for WorkPeriod A

before the Teacher can edit their Schedule.

Do you mean:

  1. Admin creates WorkPeriod
  2. By using already added teachers in the system or by adding new teachers,Admin send SSO-emails to everyone, which they then can use to fill in their BaseSchedule and their Deviations.

?

If that is the case, I totally agree with you. Further on, we also should discuss the approval process. How the approvers communicate with teachers, if they should be able to add comments and so on..

Greenheart commented 8 years ago

@hugolundin You got it correctly :+1: I updated the description slightly since it was phrased unclearly.

Further on, we also should discuss the approval process. How the approvers communicate with teachers, if they should be able to add comments and so on..

Yes, but let's discuss this in other, more specific issues :blush:

Limpan commented 8 years ago

Schedules could be created when admin adds periods or when a user uses their login link. Creating on demand makes it easier to tell if the user acted or not.

Use get when you're requesting data and post for all requests that changes application state. URLs with parameters should always be safe to request (don't change anything on the server side).

This means that slider data should be sent via post and the best way to encode data is json (mime application/json).

Use meaningful url endpoints. If it's better to split the endpoints or to encode it in the json data I couldn't tell at this point in time.

I remember that we talked about using the "on release" event instead of "on change" to limit the rate but to leave it at that at the moment.

Greenheart commented 8 years ago

Next up:

Before we can implement this back-end we need a few other features:

Greenheart commented 8 years ago

when a user uses their login link.

@Limpan Probably this alternative, to avoid having newly created teacher-accounts that don't get their own Schedules for a specific WorkPeriod

Use meaningful url endpoints.

How about this structure?

Since there's only one type of post-request i think one POST-handler for the server is sufficient.

I remember that we talked about using the "on release" event instead of "on change" to limit the rate but to leave it at that at the moment.

@Catagen fixed this by using the change-event emitted by the slider when the value changes internally.

shhmon commented 8 years ago

This seems to be a very broad discussion, so maybe it's a good idea we all discuss it in class tomorrow.

For now the only input I have is that the change event seems to be a perfect method for submitting slider data, and I do not think the frequency of the data-posts will be an issue at all.

Schedules could be created when admin adds periods or when a user uses their login link.

This I think is way better than our initial thoughts of detecting the 'first' GET request and then creating a schedule.

Since there's only one type of post-request i think one POST-handler for the server is sufficient.

Totally agree.

As mentioned, several other components need to work in order to start developing this feature. After discussing this broad topic, a small plan would maybe help us keep things organized. We could use the wiki for that?

Greenheart commented 8 years ago

Schedules could be created (...) when a user uses their login link.

I think this is the best solution so far, as I described above.

After discussing this broad topic, a small plan would maybe help us keep things organized. We could use the wiki for that?

We definitely need to discuss this tomorow. Either the wiki, or the description of each Milestone could act as a priority-list