Cool. I wish Desert/Rails had a better ability to override filters from plugins; maybe it's something we'll have to implement as part of CE. There's a similar problem with validations on models; they aren't easy to override in your application.
Thanks, Bruno On Wed, Nov 4, 2009 at 8:09 AM, GregL <[email protected]> wrote: > > I was able to simply do it with > > def my_login_required > login_required > end > > because CE's login_required is implemented in lib/ and so it's visible > to my base_controller. > > Thanks! > > On Nov 3, 10:10 pm, GregL <[email protected]> wrote: >> Oh! For some reason I thought Desert was just handling the models, and >> the rest was from Rails' built-in engines support. I'm very glad to >> know that because it will help me in future googling :) >> >> I will run with your idea to create my own login_required so I have my >> own parallel universe for the filter. >> >> On Nov 3, 9:32 pm, Bruno Bornsztein <[email protected]> >> wrote: >> >> >> >> > Yeah, unfortunately overriding filters is one of the weaknesses of >> > Desert (remember, CE uses Desert, not Engines). What you really want >> > to do is just add your own filter in your BaseController, so: >> >> > class BaseController < ApplicationController >> >> > before_filter :my_login_required >> >> > def my_login_required >> > ... your logic here, try looking at the original login_required to >> > see how it's done ... >> > end >> >> > end >> >> > Good luck, >> > Bruno >> >> > On Tue, Nov 3, 2009 at 8:28 PM, GregL <[email protected]> wrote: >> >> > > That works, thanks. >> >> > > Now my problem is that I need to do that for users, clippings, posts, >> > > photos, ... everything. They are all written with before_filters that >> > > list all the mutating actions in an :only list, so I have to gather >> > > all those specific lists and copy them into my controllers, then edit >> > > them. That's going to create so much fragility that I want to seek a >> > > better solution if I can. >> >> > > What I don't understand, and have not found with Google, is a >> > > definitive statement about how filters behave between engines and the >> > > app. I want to override the filters, so it feels like saying >> > > "before_filter :login_required" in my copy of base_controller.rb (or >> > > users_controller.rb) ought to fire the filter before :show and all the >> > > other methods not mentioned in CE's :only list, but somehow the fact >> > > that CE uses :only makes that trump instead. >> >> > > On Nov 3, 8:30 pm, Jim Ruther Nill <[email protected]> wrote: >> > >> Try this. >> >> > >> Copy the before_filter :login_required line in the users controller in >> > >> the >> > >> CE plugin. >> > >> paste it in users_controller and add the show action. >> >> > >> before_filter :login_required, :only => [:edit, :edit_account, :update, >> > >> :welcome_photo, :welcome_about, >> > >> :welcome_invite, :return_admin, :assume, :featured, >> > >> :toggle_featured, :edit_pro_details, :update_pro_details, :dashboard, >> > >> :deactivate, >> > >> :crop_profile_photo, :upload_profile_photo, :show] >> >> > >> that should keep anonymous users to browse user profiles. >> >> > >> On Wed, Nov 4, 2009 at 9:14 AM, GregL <[email protected]> wrote: >> >> > >> > Thank you Jim, that was very helpful. I want my site to be completely >> > >> > hidden from non-logged-in users, so I needed to know which was the >> > >> > appropriate before_filter for that. Sounds like login_required is the >> > >> > best, though adding it to my override of base_controller did not stop >> > >> > me from being able to see a user's profile ('/username', the show >> > >> > action of the users controller), so I'm still debugging that. >> >> > >> > On Nov 2, 10:19 pm, Jim Ruther Nill <[email protected]> wrote: >> > >> > > find_user: >> > >> > > - finds the user whose login_slug is <APP_URL>/<login_slug> >> > >> > > - used mostly in the users controller to determine to whom a >> > >> > > certain >> > >> > blog, >> > >> > > photo, clipping, etc belongs to. >> >> > >> > > require_current_user >> > >> > > - first finds user whose login_slug is <APP_URL>/<login_slug> and >> > >> > compares >> > >> > > it with current user >> > >> > > - mostly used in actions that requires the current_users permission >> > >> > (edit, >> > >> > > update, create, new) >> >> > >> > > login_required >> > >> > > - user needs to be logged in before performing a certain action >> > >> > > like >> > >> > > creating a comment. >> >> > >> > > the conditions >> >> > >> > > if logged_in? >> > >> > > if current user >> >> > >> > > are basically the same. :D >> >> > >> > > On Tue, Nov 3, 2009 at 10:53 AM, GregL <[email protected]> wrote: >> >> > >> > > > Could someone help me understand the different use cases for these >> > >> > > > methods: >> >> > >> > > > find_user >> > >> > > > require_current_user >> > >> > > > login_required >> >> > >> > > > For example, all three of those are used inside the >> > >> > > > photos_controller >> > >> > > > as before filters and I don't understand why. I want to make sure >> > >> > > > I >> > >> > > > have consistent behavior between the built-in CE areas and my own >> > >> > > > app's areas, so I need to understand the purpose of these to be >> > >> > > > able >> > >> > > > to use them correctly. >> >> > >> > > > And also, in some views like _header.html.haml, I see two similar- >> > >> > > > looking conditions like: >> >> > >> > > > if logged_in? >> > >> > > > if current_user >> >> > >> > > > I can read the code for these, but it would be super-helpful if >> > >> > > > someone could give me the high-level idea. >> >> > >> > > -- >> > >> > > "We do not believe in ourselves until someone reveals that deep >> > >> > > inside us >> > >> > is >> > >> > > valuable, worth listening to, worthy of our trust, sacred to our >> > >> > > touch." >> > >> > - >> > >> > > E. E. Cummings >> >> > >> -- >> > >> "We do not believe in ourselves until someone reveals that deep inside >> > >> us is >> > >> valuable, worth listening to, worthy of our trust, sacred to our >> > >> touch." - >> > >> E. E. Cummings > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CommunityEngine" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/communityengine?hl=en -~----------~----~----~----~------~----~------~--~---
