search

CodeGrade / bottlenose

CS assignment / grade mangement system
GNU Affero General Public License v3.0
39 stars 21 forks source link

Split assignments to separate controllers #23

Open NatTuck opened 7 years ago

NatTuck commented 7 years ago

Currently we have three assignment types:

We should split these to separate controllers so they can have separate views.

That probably implies separate models and single-table-inheritance and a subfolder under models.

This will also make it easier to add a couple new types:

This may require some more thought about type-specific graders, and the grader logic.

blerner commented 7 years ago

How do you go about creating separate subclasses of controllers? We now have separate model subclasses, so that's most of the benefit already accomplished, I think...

NatTuck commented 7 years ago

Ah, here's where the plural thing matters.

You'd create a {model}s_controller.rb for each model class, and then implement at least show methods in them. That'd let us split out the views, which would be useful.

blerner commented 7 years ago

Wouldn't that require changing routes also, so instead of /assignments/#, it'd be /files/# or /questions/# ? If so, I'm not in favor...

NatTuck commented 7 years ago

Yes, it would give us a /questions/# path. That's not a bad thing though, and the rails routing mechanics should handle it correctly. Much nicer than having to manually route one controller method to several views manually.

It also means that the {controller, method} pair maps to a unique view for selective JavaScript execution.

blerner commented 7 years ago

I disagree. It gives us 2n families of URLs, instead of two families (assignments, submissions, and their subtypes), of which most URLs don't work with most parameters. If I manually navigate to /files/123, but that assignment it actually a questions assignment, then it'll either crash accessing bogus fields (by trying to access files specific stuff), give nonsensical output (by actually giving questions specific stuff), or require a lot more error checking work on the part of each controller. As opposed to a single manual reflective dynamic dispatch in each controller.

There's no conceptual advantage to having those subtypes broken out into their own virtual collections, either: we're not going to have a /files index page separate from the /assignments index page, for instance..

It's not worth the trade-off. Rails doesn't have to dictate this structure to us if it doesn't improve our use cases in any material way.