Question about event creation logic
Sameer Siruguri
https://github.com/railsbridge/bridge_troll/blob/master/app/controllers/events_controller.rb#L60
Travis Grathwell
I think that code is unused. There was a brief period where the `published` flag existed in the DB but it defaulted to true. (I might have been playing around with different values of `published` for events on staging or something like that).
The only thing I know about that can affect the status of `published` there is the DB default. I don't recall any code that set it true only for admins or anything like that (though it's certainly possible for us to implement that in the future, if desired).
--
You received this message because you are subscribed to the Google Groups "Bridge Troll" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bridge-troll...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Sameer Siruguri
Ok, thanks!
Typed on a mobile device.
Sameer Siruguri
I am looking at the views code for the event creation, and ran into a couple of decision points that I wanted to run by everyone.
One is that, with the new “draft saved” state, the form doesn’t quite
work, because the form either lets you create (meaning submit for
publication) an event, and then subsequently update it. The form tag helper automagically manages the submit button value and form HTTP method.
What we need now is a way to save the draft, but go back to the new-event view. Which means a couple of things - when the Create Event button becomes Update Event, there’ll have to be a Submit for Publish button, or we change the language so that we always have only two buttons - Submit For Approval and Save. The other thing is that the controller actions for both PATCH and POST will need to manage the save-draft control flow.
So to be DRY, I’d probably collapse the two actions into one, with a helper private method probably to handle saving/updating. I’m not sure if this would mean changes to the routes structure, to accommodate a “submit-for-publication’ HTTP request which could be done as a PATCH that has a different submit tag. But all this would push the code a bit away from the scaffolding structure it’s in, and I like the scaffolding structure because it’s easier for beginners to grok.
So the first question is, would folks be okay if I refactored things a bit or should I try to maintain it so that the code looks like what you would see in the RailsGuides tutorials, for example?
The second thing is what happens to drafted events on the index page (root page) - currently, there’s a grid of unpublished events and the opacity layer makes it look like you can’t click on them - also, you have to click on the console button, to get to the edit button. With the new state, I think it’ll be nicer to have it say "DRAFT” with a button that says “Resume.” I’ll just go ahead and submit this in the PR but wanted to give you a heads up.
Thanks!