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

Access to cookies in a widget #149

Open
mbajur opened this issue Mar 28, 2014 · 5 comments
Open

Access to cookies in a widget #149

mbajur opened this issue Mar 28, 2014 · 5 comments

Comments

@mbajur
Copy link

mbajur commented Mar 28, 2014

Hello!
I've found a similar topic on google groups, it's a bit old and i'm not sure if google groups is an official way for asking questions but so i'll ask again here.

I'm trying to use a cookies variable in my widget view and it's impossible due to Unknown method 'cookies' exception. In the previously mentioned topic, Nick suggests to use the following code in my widget:

delegate :cookies, :to => :parent_controller
helper_method :cookies

However, it's not working. Right now, i'm getting private method 'cookies' called for #<VideosController:0x0000010ab7fdf8>

Have you any idea how can i deal with that?
Thanks in advance.

@apotonick
Copy link
Owner

You can do parent_controller.send(:cookies). I officially wanna state that I don't like the idea of view components (aka "widgets") have access to the cookies hash.

@andreorvalho
Copy link

@apotonick I have an example where I need to set a cookie for an action that happens on a widget, how would you work around calling parent_controller.send(:cookies) ?

I have encapsulated it on a method in the parent controller. so I dont directly call cookies inside my widget, like

class SignupWidget < Apotomo::Widget
  responds_to_event :subscribe

  def display
  end

  def subscribe 
    parent_controller.set_cookie(args)
  end
end

def ApplicationController <  ActionController::Base

  def set_cookie(args)
    cookies[:whatever] = args[:whatever]
  end
end

But still not sure this is the correct solution! if you have any other options I would like to hear about it!

@apotonick
Copy link
Owner

I personally don't have any solution for that as I think a widget should not know about HTTP cookies. But I like how you introduce a certain level of encapsulation, though.

Do you need this in one place, only, or is this a common requirement in your app? Anyways, I think what you do is correct! 😁

@andreorvalho
Copy link

  1. Yea this was a common requirement. I use it everywhere where a user has to insert an email.
  2. about what you said here: "...I think a widget should not know about HTTP cookies...". I am not sure I understand apotomo 100% but isnt it basically calling js, that makes an ajax request so it acts like a "controller"?
    So maybe we could give a mechanism for telling the controller responsible for that request to set cookies?

Or do you still think that's a bad idea? I have seen I am not the only one asking for this, as I found more posts about this problem/need.
If you think this is something you would include I can try and work on the PR.

@apotonick
Copy link
Owner

The wiring of AJAX --> controller --> widget and back is one thing in Apotomo. The other main concept is that of a widget, and a widget in Apotomo is not supposed to know anything about HTTP. This is what makes it different to Rails where every "MVC" "component" knows about every other layer.

Apotomo and Cells try to get away from the concept of an all-mighty "controller". Maybe it's easier to understand if you think of a widget in other environments: imagine an Apotomo widget being part of a native GUI application. There is no such thing as "cookies" in a native app, and that's where we want to get with Apotomo.

I guess the dependency to parent_controller is sufficient. Can I ask you what exactly you set in the cookie? I want to understand the need for this.... thanks!!!

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

No branches or pull requests

3 participants