refactor resources controller

[nicholalexander]

hey guys!

i'd like to make a strong case to refactor the resources controller into individual controllers per resource. @zniazi 's recent pull request is a great example - we're going to be putting model specific logic in the controller and i'm afraid it's going to get crazy up in here, quick.

if we take it out of the context of the hackathon and look at it as an open source project that we want to maintain, i think the railsy way is the way to go. @surenm - can we have a vote or something?

[surenm]

We should have individual controllers, agreed. I am thinking of good ways
to do this.

On Tue, Nov 11, 2014 at 3:59 PM, nichol alexander [email protected]
wrote:

hey guys!

i'd like to make a strong case to refactor the resources controller into
individual controllers per resource. @zniazi https://github.com/zniazi
's recent pull request is a great example - we're going to be putting model
specific logic in the controller and i'm afraid it's going to get crazy up
in here, quick.

if we take it out of the context of the hackathon and look at it as an
open source project that we want to maintain, i think the railsy way is the
way to go. @surenm https://github.com/surenm - can we have a vote or
something?

—
Reply to this email directly or view it on GitHub
#38.

Cheers,
~Suren.

http://suren.in
http://twitter.com/suren
skype: pingsuren

[nicholalexander]

if we want to be really fancy, lets write a couple of basic tests, refactor the routes, add the new controllers, and then hit the existing resources - the results returned should be identical because the changes are all happening under the surface.

[NancyKo]

Yes, I agree. It is going to get messy and unreadable.

[zniazi]

I think that's a good point. I put it in the same controller in case you
guys had some way you wanted to generalize the constellations controller
methods.

On Tue, Nov 11, 2014 at 4:03 PM, NancyKo [email protected] wrote:

Yes, I agree. It is going to get messy and unreadable.

—
Reply to this email directly or view it on GitHub
#38 (comment)
.

[nicholalexander]

look at this nice open source project! #starapi4ever

[nicholalexander]

@surenm why don't we do the refactoring as part of v2. leave v1 resources controller as it, and then set up the v2 to use the individual resources controllers?

[surenm]

I prefer the v2 approach because then you can compare the end points
between versions.

Also I think we should have a /api/latest/ where latest is a synonym for
the latest api version.

On Tue, Nov 11, 2014 at 4:42 PM, nichol alexander [email protected]
wrote:

@surenm https://github.com/surenm why don't we do the refactoring as
part of v2. leave v1 resources controller as it, and then set up the v2 to
use the individual resources controllers?

—
Reply to this email directly or view it on GitHub
#38 (comment)
.

Cheers,
~Suren.

http://suren.in
http://twitter.com/suren
skype: pingsuren

[jdmcpeek]

I agree with the individual controllers. I suggest we add a new branch for every feature or big change, so for this it would be titled something like feature/refactor-controllers. There's a git paradigm called 'git-flow' which is really useful for this kind of... well, workflow! Check out a description here: http://danielkummer.github.io/git-flow-cheatsheet/

I didn't work much on the controllers, so @surenm and @nicholalexander do one of you guys want to go ahead and delegate tasks? Seems we're all in consensus here.

[nicholalexander]

cool - i assigned myself and will work on a first pass today. if you assign issues to people - you know what everyone is working on so there isn't overlap.