Rails render buttons by really complex condition
up vote
0
down vote
favorite
My rails application members may have one of the two different roles: vip_lite and vip.
They can subscribe plan to renew their authorizing.
We also have four types plan: vip_lite/monthly, vip_lite/yearly, vip/monthly, vip/yearly.
A vip user might be subscribing one of the four plans, so does vip_lite.
Member with different roles and different plans can see different buttons in plan page(e.g. vip_lite and subscribing vip_lite/monthly member can see 'upgrade' button in vip plan page).
see the following sample code: (currently write in helper)
def plan_action_button(user)
if user.vip? && user.subscribing_plan?(:vip_lite, :monthly)
'button_a'
elsif user.vip? && user.subscribing_plan?(:vip_lite, :yearly)
'button_b'
elsif user.vip? && user.subscribing_plan?(:vip, :monthly)
'button_c'
elsif user.vip? && user.subscribing_plan?(:vip, :monthly)
'button_d'
elsif user.vip_lite? && user.subscribing_plan?(:vip, :monthly)
'button_e'
elsif user.vip_lite? && user.subscribing_plan?(:vip, :yearly)
'button_e'
... and so on...
end
end
So I have to deal with 2 * 4 = 8 conditions for each button in these pages. Is there a good pattern in rails for dealing with such case? Thanks
ruby-on-rails design-patterns
add a comment |
up vote
0
down vote
favorite
My rails application members may have one of the two different roles: vip_lite and vip.
They can subscribe plan to renew their authorizing.
We also have four types plan: vip_lite/monthly, vip_lite/yearly, vip/monthly, vip/yearly.
A vip user might be subscribing one of the four plans, so does vip_lite.
Member with different roles and different plans can see different buttons in plan page(e.g. vip_lite and subscribing vip_lite/monthly member can see 'upgrade' button in vip plan page).
see the following sample code: (currently write in helper)
def plan_action_button(user)
if user.vip? && user.subscribing_plan?(:vip_lite, :monthly)
'button_a'
elsif user.vip? && user.subscribing_plan?(:vip_lite, :yearly)
'button_b'
elsif user.vip? && user.subscribing_plan?(:vip, :monthly)
'button_c'
elsif user.vip? && user.subscribing_plan?(:vip, :monthly)
'button_d'
elsif user.vip_lite? && user.subscribing_plan?(:vip, :monthly)
'button_e'
elsif user.vip_lite? && user.subscribing_plan?(:vip, :yearly)
'button_e'
... and so on...
end
end
So I have to deal with 2 * 4 = 8 conditions for each button in these pages. Is there a good pattern in rails for dealing with such case? Thanks
ruby-on-rails design-patterns
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
My rails application members may have one of the two different roles: vip_lite and vip.
They can subscribe plan to renew their authorizing.
We also have four types plan: vip_lite/monthly, vip_lite/yearly, vip/monthly, vip/yearly.
A vip user might be subscribing one of the four plans, so does vip_lite.
Member with different roles and different plans can see different buttons in plan page(e.g. vip_lite and subscribing vip_lite/monthly member can see 'upgrade' button in vip plan page).
see the following sample code: (currently write in helper)
def plan_action_button(user)
if user.vip? && user.subscribing_plan?(:vip_lite, :monthly)
'button_a'
elsif user.vip? && user.subscribing_plan?(:vip_lite, :yearly)
'button_b'
elsif user.vip? && user.subscribing_plan?(:vip, :monthly)
'button_c'
elsif user.vip? && user.subscribing_plan?(:vip, :monthly)
'button_d'
elsif user.vip_lite? && user.subscribing_plan?(:vip, :monthly)
'button_e'
elsif user.vip_lite? && user.subscribing_plan?(:vip, :yearly)
'button_e'
... and so on...
end
end
So I have to deal with 2 * 4 = 8 conditions for each button in these pages. Is there a good pattern in rails for dealing with such case? Thanks
ruby-on-rails design-patterns
My rails application members may have one of the two different roles: vip_lite and vip.
They can subscribe plan to renew their authorizing.
We also have four types plan: vip_lite/monthly, vip_lite/yearly, vip/monthly, vip/yearly.
A vip user might be subscribing one of the four plans, so does vip_lite.
Member with different roles and different plans can see different buttons in plan page(e.g. vip_lite and subscribing vip_lite/monthly member can see 'upgrade' button in vip plan page).
see the following sample code: (currently write in helper)
def plan_action_button(user)
if user.vip? && user.subscribing_plan?(:vip_lite, :monthly)
'button_a'
elsif user.vip? && user.subscribing_plan?(:vip_lite, :yearly)
'button_b'
elsif user.vip? && user.subscribing_plan?(:vip, :monthly)
'button_c'
elsif user.vip? && user.subscribing_plan?(:vip, :monthly)
'button_d'
elsif user.vip_lite? && user.subscribing_plan?(:vip, :monthly)
'button_e'
elsif user.vip_lite? && user.subscribing_plan?(:vip, :yearly)
'button_e'
... and so on...
end
end
So I have to deal with 2 * 4 = 8 conditions for each button in these pages. Is there a good pattern in rails for dealing with such case? Thanks
ruby-on-rails design-patterns
ruby-on-rails design-patterns
edited Nov 15 at 3:15
asked Nov 14 at 17:24
洪梓凱
156
156
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
up vote
0
down vote
There are some interesting patterns that you can use here. Let's see what's repeated the most: user.vip?
Let's start the method with a guard clause
def plan_action_button(user)
return 'whatever you need to return' unless user.vip?
if user.subscribing_plan?(:vip_lite, :monthly)
'button_a'
[...]
Then because there's a lot of combinaisons, it's hard to tell what changes and what remains the same for those buttons. Is it a I18n key? Is is the button tag with different links? Do you have access to those parts separately like user.plan_name
and user.plan_frequency
?
Answering those questions would help you a lot in seeing emerge a pattern.
The subscribing_plan?(xxx) combined with use.vip? or user.vip_lite? returns different buttons, so set guard clause for only user.vip? can not reduce the complexity I think. I've updated my code sample for more detailed description.
– 洪梓凱
Nov 15 at 3:20
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
There are some interesting patterns that you can use here. Let's see what's repeated the most: user.vip?
Let's start the method with a guard clause
def plan_action_button(user)
return 'whatever you need to return' unless user.vip?
if user.subscribing_plan?(:vip_lite, :monthly)
'button_a'
[...]
Then because there's a lot of combinaisons, it's hard to tell what changes and what remains the same for those buttons. Is it a I18n key? Is is the button tag with different links? Do you have access to those parts separately like user.plan_name
and user.plan_frequency
?
Answering those questions would help you a lot in seeing emerge a pattern.
The subscribing_plan?(xxx) combined with use.vip? or user.vip_lite? returns different buttons, so set guard clause for only user.vip? can not reduce the complexity I think. I've updated my code sample for more detailed description.
– 洪梓凱
Nov 15 at 3:20
add a comment |
up vote
0
down vote
There are some interesting patterns that you can use here. Let's see what's repeated the most: user.vip?
Let's start the method with a guard clause
def plan_action_button(user)
return 'whatever you need to return' unless user.vip?
if user.subscribing_plan?(:vip_lite, :monthly)
'button_a'
[...]
Then because there's a lot of combinaisons, it's hard to tell what changes and what remains the same for those buttons. Is it a I18n key? Is is the button tag with different links? Do you have access to those parts separately like user.plan_name
and user.plan_frequency
?
Answering those questions would help you a lot in seeing emerge a pattern.
The subscribing_plan?(xxx) combined with use.vip? or user.vip_lite? returns different buttons, so set guard clause for only user.vip? can not reduce the complexity I think. I've updated my code sample for more detailed description.
– 洪梓凱
Nov 15 at 3:20
add a comment |
up vote
0
down vote
up vote
0
down vote
There are some interesting patterns that you can use here. Let's see what's repeated the most: user.vip?
Let's start the method with a guard clause
def plan_action_button(user)
return 'whatever you need to return' unless user.vip?
if user.subscribing_plan?(:vip_lite, :monthly)
'button_a'
[...]
Then because there's a lot of combinaisons, it's hard to tell what changes and what remains the same for those buttons. Is it a I18n key? Is is the button tag with different links? Do you have access to those parts separately like user.plan_name
and user.plan_frequency
?
Answering those questions would help you a lot in seeing emerge a pattern.
There are some interesting patterns that you can use here. Let's see what's repeated the most: user.vip?
Let's start the method with a guard clause
def plan_action_button(user)
return 'whatever you need to return' unless user.vip?
if user.subscribing_plan?(:vip_lite, :monthly)
'button_a'
[...]
Then because there's a lot of combinaisons, it's hard to tell what changes and what remains the same for those buttons. Is it a I18n key? Is is the button tag with different links? Do you have access to those parts separately like user.plan_name
and user.plan_frequency
?
Answering those questions would help you a lot in seeing emerge a pattern.
answered Nov 14 at 19:24
Sophie Déziel
404211
404211
The subscribing_plan?(xxx) combined with use.vip? or user.vip_lite? returns different buttons, so set guard clause for only user.vip? can not reduce the complexity I think. I've updated my code sample for more detailed description.
– 洪梓凱
Nov 15 at 3:20
add a comment |
The subscribing_plan?(xxx) combined with use.vip? or user.vip_lite? returns different buttons, so set guard clause for only user.vip? can not reduce the complexity I think. I've updated my code sample for more detailed description.
– 洪梓凱
Nov 15 at 3:20
The subscribing_plan?(xxx) combined with use.vip? or user.vip_lite? returns different buttons, so set guard clause for only user.vip? can not reduce the complexity I think. I've updated my code sample for more detailed description.
– 洪梓凱
Nov 15 at 3:20
The subscribing_plan?(xxx) combined with use.vip? or user.vip_lite? returns different buttons, so set guard clause for only user.vip? can not reduce the complexity I think. I've updated my code sample for more detailed description.
– 洪梓凱
Nov 15 at 3:20
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53305672%2frails-render-buttons-by-really-complex-condition%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown