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 --save NAME option to save your chosen scrolls when creating an app #26

Open
wants to merge 7 commits into
base: master
Choose a base branch
from

Conversation

jackdempsey
Copy link
Contributor

Simple way to save your selections. Considering how to implement pulling them back out and using them when generating.

On one hand, I thought about overloading the scrolls option to let you do -s saved_name, rather than creating yet another option. At the same time another option would be cleaner and likely more obvious...so maybe I'll spike on that and see how it goes.

Also, yeah, didn't include tests. Happy to give them a go if you have some guidance on it--I always find testing code like this to sometimes get a bit awkward and unhelpful.

@jackdempsey
Copy link
Contributor Author

Seems like a ~/.scrolls dir might be desired from other pull requests? Maybe makes sense to standardize that, and then the file that stores this data can go in there?

@drnic
Copy link
Owner

drnic commented Apr 29, 2012

Perhaps a "saved scroll" is just another scroll with dependencies? (the scrolls you originally selected)

@drnic
Copy link
Owner

drnic commented Apr 29, 2012

Then we don't need --use, rather you just select your custom scroll "my-scrolls" normally: scrolls new myapp2 -s my-scrolls.

Thoughts?

@jackdempsey
Copy link
Contributor Author

Yep, definitely like that style of use. You could even publish scrolls that represent common configs, etc.

So, how do we build this? It would seem that if scrolls had a way of depending on other scrolls, you could easy save one that just depends on those you selected. I don't believe they currently have this functionality though? Seems a basic version of this wouldn't be hard to build.

@jackdempsey
Copy link
Contributor Author

Ahh, just found the require option after looking through source. Seems this would do it. I'm going to give this idea a go and see how it turns out.

@jackdempsey
Copy link
Contributor Author

Ok, code is ugly (partial copy/paste from rake task), but is proof-of-concept ready. I like this strategy. Would probably want to combine with other efforts to write out scroll file to ~/.scrolls/{name}.rb or something similar.

@drnic
Copy link
Owner

drnic commented Apr 30, 2012

I'm trying to think through the UX here.

  1. You generate an app with some scrolls.
  2. You realize you missed some scrolls, so you generate it again (happens to me)
  3. Later, you want to generate a new app with the scrolls you previously used; or a co-worker is creating a new app and wants to use those scrolls

Perhaps --save isn't in their mind? Perhaps we offer a new command scrolls save and it shows you your previous history, you select one, and give it a name.

Thoughts?

@jackdempsey
Copy link
Contributor Author

Ok so it automatically writes a history file that you then select from? I can see that working nicely.

  1. Every time you run scrolls we add to a history log
  2. You can call scrolls history to see that list. You can then --save or --use directly from it?

I think I like the history command, pure in what it does, and then the options give you both saving as a new scroll for future use, as well as ability to just reuse easily without worrying about generating a new scroll.

What you think?

@drnic
Copy link
Owner

drnic commented Apr 30, 2012

Yeah that sounds good.

@jackdempsey
Copy link
Contributor Author

Ok, spiked out functionality as described above, take a peek and let me know what you think.

@jackdempsey
Copy link
Contributor Author

Thoughts? If looks good, will take a look at writing some tests for this.

@drnic
Copy link
Owner

drnic commented May 15, 2012

The idea looks great. Continue!

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.

2 participants