You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi,
I just wanted to touch base and see if the following functionality would be approved as a patch to this code base as I am planning to code it regardless and I want to gear it towards either being plugged directly into Highline or being its own add-on gem. (If the former is possible, I think it's important I talk to you guys beforehand to ensure I meet whatever constraints you want to impose.)
Basically, I want to code a way for something like this (input/output from use of 'checkinstall' menu editor) as the end result, but on the way there, a lot of features could easily be added that I think could make highline a bit more robust than it already is, for instance with wizards/workflows to fully describe the variables to be set in a class. Here's the screenshot:
Basically:
I want the ability to see all the values for an object at a glance and be able to set any one of them individually. (If this is done, it's an insignificant amount of work to have the added feature of prompting for each value in sequence.) The only thing that this screenshot doesn't show that I'd like is the ability to abort changing a field, and also to re-set it to the default value.
I think the way I want to implement this is to accept classes that have some sort of ActiveModel-type class interface (though I would want this to be agnostic in terms of dependencies or the model's inhereted attributes, so I would just expect the provided class to respond to certain functions).
The benefit of this, is if "include Highline::Model" is added to the model, we can design our own methods like Model.wizard or Model.menu that could be called on it.
Any model would only need to have the following functionality defined:
A method returning list of the attributes to be set.
A method to set a given attribute to a given value.
We could additionally accept, but not require, the following methods to that model for more advanced features: (Say the column in question is 'name'.)
#name_default -- will show up between square brackets at the prompt and will be assumed as the answer if no input is provided.
#name_hide? -- will make an attribute /not/ appear either for the wizard, each redraw of the menu or both (depending on return value), if, for instance, a specific answer to another value has rendered the choice moot.
Compatibility with include ActiveModel::Validations for validations or a custom-implemented model with a similar interface. For instance, #name_validates? could be called on setting any attribute to accept/reject the value and, if accepted, #validate could be called on the record after any attribute is changed for the purpose of obtaining an array of warnings/errors for the console to list if any attributes are incompatible with each other.
Compatibility with the 'simple_enum' gem (or similar custom implementation). This would turn any field into an enumerated list of choices rather than free-response-type input.
Compatibility with 'ActiveAttr' gem (or similar implementation) for typecasting (and setting default values).
Compatibility with ActiveModel::SecurePassword (for instance by not echoing input when taking values for this field.)
Compatibility with ActiveModel::Dirty (for instance by selectively showing the save button).
Please let me know what you guys think.
The text was updated successfully, but these errors were encountered:
If I am understanding the request correctly, you want to add a feature where HighLine basically builds a menu system for modifying the properties of some object. Sure. This seems like a fine add on. I have no problem with adding it.
Hi,
I just wanted to touch base and see if the following functionality would be approved as a patch to this code base as I am planning to code it regardless and I want to gear it towards either being plugged directly into Highline or being its own add-on gem. (If the former is possible, I think it's important I talk to you guys beforehand to ensure I meet whatever constraints you want to impose.)
Basically, I want to code a way for something like this (input/output from use of 'checkinstall' menu editor) as the end result, but on the way there, a lot of features could easily be added that I think could make highline a bit more robust than it already is, for instance with wizards/workflows to fully describe the variables to be set in a class. Here's the screenshot:
Basically:
I want the ability to see all the values for an object at a glance and be able to set any one of them individually. (If this is done, it's an insignificant amount of work to have the added feature of prompting for each value in sequence.) The only thing that this screenshot doesn't show that I'd like is the ability to abort changing a field, and also to re-set it to the default value.
I think the way I want to implement this is to accept classes that have some sort of ActiveModel-type class interface (though I would want this to be agnostic in terms of dependencies or the model's inhereted attributes, so I would just expect the provided class to respond to certain functions).
The benefit of this, is if "include Highline::Model" is added to the model, we can design our own methods like
Model.wizard
orModel.menu
that could be called on it.Any model would only need to have the following functionality defined:
We could additionally accept, but not require, the following methods to that model for more advanced features: (Say the column in question is 'name'.)
#name_default
-- will show up between square brackets at the prompt and will be assumed as the answer if no input is provided.#name_hide?
-- will make an attribute /not/ appear either for the wizard, each redraw of the menu or both (depending on return value), if, for instance, a specific answer to another value has rendered the choice moot.include ActiveModel::Validations
for validations or a custom-implemented model with a similar interface. For instance,#name_validates?
could be called on setting any attribute to accept/reject the value and, if accepted,#validate
could be called on the record after any attribute is changed for the purpose of obtaining an array of warnings/errors for the console to list if any attributes are incompatible with each other.ActiveModel::SecurePassword
(for instance by not echoing input when taking values for this field.)ActiveModel::Dirty
(for instance by selectively showing the save button).Please let me know what you guys think.
The text was updated successfully, but these errors were encountered: