Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add GistConfig class #68

Merged
merged 4 commits into from Aug 15, 2015
Merged

Conversation

JacobBennett
Copy link
Contributor

Allows an author to add a gistlog.yml to their gist and have the following values pulled into a config file for the gist:

  1. published
  2. published_at
  3. preview

The main goal of this PR is to allow authors to customize the preview text that is used for their gists on the author page. The other two config items will be used in future development to allow more fine grained control over the presentation and publishing of their posts.

{
Arr::set($this->settings, $offset, null);
}
}

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Expected 1 newline at end of file; 0 found

@JacobBennett JacobBennett mentioned this pull request Jul 27, 2015
@JacobBennett
Copy link
Contributor Author

Updated the relevant Nitpick CI issues.

@adamwathan
Copy link
Contributor

@JacobBennett I'm gonna have to make it easy to ignore things like test files I think, heh... Wouldn't worry about anything that isn't main source code, definitely prefer snake_case test names, don't care about namespaces in migrations, etc.

@mattstauffer
Copy link
Member

OK, I deleted all the useless nitpick errors. :) I'll try to review this PR ASAP; thanks so much @JacobBennett!

@JacobBennett
Copy link
Contributor Author

@adamwathan yeah I was betting the snake case was the preferred convention. First time I've seen nitpick. Really cool tool.

@mattstauffer no prob. Glad to help in any way I can. Would love to help implement other ideas regarding the published at date as well.

/**
* @var array
*/
private $default_settings = array(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can use short array syntax here and on :21

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we've done camelCase everywhere else in the app, both for properties and for inline variables

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this include the keys in the defaultSettings array?

for example:

$defaultSettings = [
    'published',
    'publishedOn',
    'preview',
];

@mattstauffer
Copy link
Member

I made some notes; With these changes, this looks great.

As a side note, we'll need to add some directions on how to use all this stuff, but that'll be a separate issue/PR.

Thanks!!

@JacobBennett
Copy link
Contributor Author

I'll get to work on these changes and have them done hopefully soon. Some great insights! I've never actually had anyone do a "code review" for me. Pretty much a one man show at my current job. Just goes to show the incredible value to be gained from having another set of eyes look over your code. Thanks.

@JacobBennett
Copy link
Contributor Author

@mattstauffer so I made all the changes regarding new lines, short arrays, etc. The only thing left, which I'm thinking of adding in another PR is the date issue for the published_on setting.

My thoughts for the next PR would include the following:

  1. A dates array in the config class that contains the keys of settings that need to be converted to dates
  2. Dates in YYYY-MM-DD format
  3. published_on, if set, will be used instead of the created_at property when displayed on the gistlog
  4. Instructions for utilizing the new settings available in the gistlog.yml file.

If you're okay with that, we can probably merge and close out this PR. Let me know.

@JacobBennett
Copy link
Contributor Author

Hey @mattstauffer, have intentionally held off on being annoying and asking about this because I know you are likely slammed at the moment, but wanted to check and see if there was anything you needed me to do or if you needed any further explanation on this PR.

Essentially pulling the PR in will allow authors to set a custom preview, thats it at this point. Any other hooks are strictly for future dev.

@mattstauffer
Copy link
Member

@JacobBennett Thanks for the ping! Got back from vacation yesterday. Let me check it over again. :)

@mattstauffer
Copy link
Member

@JacobBennett Hey, this is is all great, but I'd love for us to avoid committing anything to master that shows the MM-DD-YYYY date to avoid confusion. I know you want to save it for a separate PR, but can you either drop the date stuff from this one, or just do that separate PR against this branch before we merge this branch to master? I don't want to delay this launch because it's great work but I don't want to merge in anything with the wrong date format. :)

Thanks!

chore: update Exception to catch correct type

chore: PSR-2 cleanup
@JacobBennett
Copy link
Contributor Author

@mattstauffer The date(s) in the YML file will now be parsed into Carbon objects using the GistConfig class.

To do so, the YML key to be used as a date must be specified in the GistConfig defaultSettings array and then included in the dates array.

The value of said date key must be in the format specified in http://symfony.com/legacy/doc/reference/1_3/en/02-YAML#chapter_02_sub_dates, which is in Y-m-d.

Since the dates are being parsed to a Carbon object, the format of the date after this is up to the consumer of the object. The tests run against this class do show the dates in Y-m-d format for consistency however.

@JacobBennett
Copy link
Contributor Author

Hey @mattstauffer, did you happen to see my last ping on this one? Think we should have all the changes set to go for this.

@mattstauffer
Copy link
Member

@JacobBennett I hadn't seen it. Looking at it now. Thanks!

@mattstauffer
Copy link
Member

@JacobBennett with the extra lines dropped, this looks fantastic. Just push up those changes (sorry to nit pick!) and it's ready to go--I'll finally merge this sucker. Thanks man!

mattstauffer added a commit that referenced this pull request Aug 15, 2015
@mattstauffer mattstauffer merged commit 6da41fe into tighten:master Aug 15, 2015
@JacobBennett
Copy link
Contributor Author

Didn't get a chance to make those changes before you merged, but thanks for merging it in! Whew! Now onto some other issues and pull requests :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants