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 missing support for date_select method. #13

Merged
merged 1 commit into from
Aug 6, 2020
Merged

Conversation

seanpdoyle
Copy link
Owner

Prior to this commit, a corresponding implementation for
ActionView::Helpers::FormBuilder#date_select was omitted.

This commit corrects that oversight.

Prior to this commit, a corresponding implementation for
[ActionView::Helpers::FormBuilder#date_select][date_select] was omitted.

This commit corrects that oversight.

[date_select]: https://api.rubyonrails.org/classes/ActionView/Helpers/FormBuilder.html#method-i-date_select
@seanpdoyle seanpdoyle merged commit d3bbac5 into main Aug 6, 2020
@seanpdoyle seanpdoyle deleted the date-select-support branch August 6, 2020 03:05
seanpdoyle added a commit that referenced this pull request Aug 6, 2020
One major drawback to the original `ViewPartialFormBuilder::FormBuilder`
implementation was its obligation to totally re-create the underlying
`FormBuilder` behavior, including minor implementation details like
calling `objectify_options` and setting and unsetting instance variables
like `@emitted_hidden_id = true if method == :id`.

Another drawback is that if the method wasn't declared, there would be
no means of declaring a corresponding view partial. This is exactly what
happened with the `date_select` helper (fixed in [#13][]).

This new implementation proxies calls to render ActionView instances
through the `ViewPartialFormBuilder::TemplateProxy`, which first
attempts to resolve a view partial that matches the method call.

It is not without its quirks. For example, the `#button` and `#submit`
methods are special case, because they invoke a method on the
`@template` that is suffixed with `_tag`.

Additionally, the `#label` helper is a special case because of the
optional nature of the `text = nil` parameter.

[#13]: #13
seanpdoyle added a commit that referenced this pull request Aug 6, 2020
One major drawback to the original `ViewPartialFormBuilder::FormBuilder`
implementation was its obligation to totally re-create the underlying
`FormBuilder` behavior, including minor implementation details like
calling `objectify_options` and setting and unsetting instance variables
like `@emitted_hidden_id = true if method == :id`.

Another drawback is that if the method wasn't declared, there would be
no means of declaring a corresponding view partial. This is exactly what
happened with the `date_select` helper (fixed in [#13][]).

This new implementation proxies calls to render ActionView instances
through the `ViewPartialFormBuilder::TemplateProxy`, which first
attempts to resolve a view partial that matches the method call.

It is not without its quirks. For example, the `#button` and `#submit`
methods are special case, because they invoke a method on the
`@template` that is suffixed with `_tag`.

Additionally, the `#label` helper is a special case because of the
optional nature of the `text = nil` parameter.

[#13]: #13
seanpdoyle added a commit that referenced this pull request Jan 22, 2023
One major drawback to the original `ViewPartialFormBuilder::FormBuilder`
implementation was its obligation to totally re-create the underlying
`FormBuilder` behavior, including minor implementation details like
calling `objectify_options` and setting and unsetting instance variables
like `@emitted_hidden_id = true if method == :id`.

Another drawback is that if the method wasn't declared, there would be
no means of declaring a corresponding view partial. This is exactly what
happened with the `date_select` helper (fixed in [#13][]).

This new implementation proxies calls to render ActionView instances
through the `ViewPartialFormBuilder::TemplateProxy`, which first
attempts to resolve a view partial that matches the method call.

It is not without its quirks. For example, the `#button` and `#submit`
methods are special case, because they invoke a method on the
`@template` that is suffixed with `_tag`.

Additionally, the `#label` helper is a special case because of the
optional nature of the `text = nil` parameter.

[#13]: #13
seanpdoyle added a commit that referenced this pull request Jan 22, 2023
One major drawback to the original `ViewPartialFormBuilder::FormBuilder`
implementation was its obligation to totally re-create the underlying
`FormBuilder` behavior, including minor implementation details like
calling `objectify_options` and setting and unsetting instance variables
like `@emitted_hidden_id = true if method == :id`.

Another drawback is that if the method wasn't declared, there would be
no means of declaring a corresponding view partial. This is exactly what
happened with the `date_select` helper (fixed in [#13][]).

This new implementation proxies calls to render ActionView instances
through the `ViewPartialFormBuilder::TemplateProxy`, which first
attempts to resolve a view partial that matches the method call.

It is not without its quirks. For example, the `#button` and `#submit`
methods are special case, because they invoke a method on the
`@template` that is suffixed with `_tag`.

Additionally, the `#label` helper is a special case because of the
optional nature of the `text = nil` parameter.

[#13]: #13
seanpdoyle added a commit that referenced this pull request Jan 22, 2023
One major drawback to the original `ViewPartialFormBuilder::FormBuilder`
implementation was its obligation to totally re-create the underlying
`FormBuilder` behavior, including minor implementation details like
calling `objectify_options` and setting and unsetting instance variables
like `@emitted_hidden_id = true if method == :id`.

Another drawback is that if the method wasn't declared, there would be
no means of declaring a corresponding view partial. This is exactly what
happened with the `date_select` helper (fixed in [#13][]).

This new implementation proxies calls to render ActionView instances
through the `ViewPartialFormBuilder::TemplateProxy`, which first
attempts to resolve a view partial that matches the method call.

It is not without its quirks. For example, the `#button` and `#submit`
methods are special case, because they invoke a method on the
`@template` that is suffixed with `_tag`.

Additionally, the `#label` helper is a special case because of the
optional nature of the `text = nil` parameter.

[#13]: #13
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

1 participant