Add customizable extension partials to good_job/jobs#show view #1200
Conversation
|
Thank you! This looks nice. Could you please add an example in to the |
This variable is a GoodJob::DiscreteExecution except in cases where migrations have not been run in a long time. That case didn't seem worthy of cluttering up the comment. See: bensheldon#928
|
Now updated with an example and a spec. |
| @@ -21,6 +21,12 @@ def create_migration_file | |||
| migration_template 'migrations/create_good_jobs.rb.erb', File.join(db_migrate_path, "create_good_jobs.rb") | |||
| end | |||
|
|
|||
| def copy_empty_partials | |||
| %w[custom_job_details custom_execution_details].each do |partial| | |||
| copy_file "views/_#{partial}.html.erb", "app/views/good_job/jobs/_#{partial}.html.erb" | |||
There was a problem hiding this comment.
I think I'd prefer not to copy these over as part of the install generator. Initially I was excited about it, but I try to step lightly inside of other people's applications and I think I'd prefer to document it in the readme, but otherwise not force it on an application.
There was a problem hiding this comment.
This also makes me think that the path should either be:
views/good_job/_custom_job_details.html.erbORviews/good_job/jobs/_job_details.html.erb
...because I think the custom is useful if it's at a simple root path, but otherwise it should just be "override this existing vanilla-looking path"
|
I have an immediate use for this PR. What is the outlook for merge? |
|
Thanks for updating the PR @bensheldon, I'm dealing with a newborn here and won't have time to follow up for a while 😅 |
|
@grncdr no worries at all 💖 I appreciate your help moving it this far forward 🙇🏻 |
bensheldon
changed the title
|
Woohoo! When do you expect to cut a new release with these changes? |
|
Just made a release 🎉 https://github.com/bensheldon/good_job/releases/tag/v3.25.0 |
This is a minimal implementation of the idea from #1197.
I've opted not to address the issues of exposing internal classes in this first pass, but rather just document the potential for unstable APIs. I'm open to ideas, but my opinion at the moment is that this strikes the right balance between complexity/maintenance burden for GoodJob maintainers and users.