prepend_before_filter get_profile etc. - unnecessary database hits?
Victor
I would like to use Lovdbyless, but there are a few things that I fail
to appreciate.
1) Most of rails apps seems to standardize on restful authentication,
using less authentication - makes me feel uncomfortable. I love to see
more standard components.
2) prepend_before_filter get_profile and before_filter setup: these
are in many controllers, blog, messsage, photo, etc. I am guessing the
benefit is to have cleaner code. The downside is that there are extra
database hits when not needed (say edit/delete a blog).
3) because of 2), you need to supply profile_id when it is not needed
(say delete a blog)
4) It's also hard to get use to the url style /profile/2/blogs/3
etc. Why not just /blogs/3? Or /steve/blogs/3?
Like I said, I would like to use it. If it is more along the standard
approach, it would be easier for people to adopt it. If these are the
good things about Lovebyless and I have failed to appreciate them, can
you please explain? I am guessing that others feel the same way
because we all did the same Rails exercise from the same books.
With Love,
Victor
Steven A Bristol
Hi Victor,
You raise some good points.
1. Less Authentication is based on acts_as_authenticated, which is the
same thing that Restful Authentication is based on. The truth is that
I didn't the other two auth plugins log the user out of one machine
once they log in from an other. Meaning if I am working at my computer
and go to lunch and then while I lunch I access the site from my
iPhone, then when I get back from lunch and sit down at my laptop I
have to log in again. And although there is certainly an argument that
can be made about security, I have yet to write a rails app that needs
this level of security when compared with a better user experience.
2. Looking at the before filter code in the controller I agree that it
could use some refactoring. Please feel free to write a patch and I'll
take a look. You can usually find me in #lovdbyless on freenode if you
have questions or want to talk something through.
3. See #2.
4. I'd be happy for a patch that changed the nested urls into
something more like /profiles/steve/blogs/3. I'm not such a fan of
/steve/blogs/3. It looks much nicer than having /profiles/steve, but
it will create a name clash between controller names and users names.
Rails isn't for everyone and neither is lovdbyless. But I'd be happy
to take some patches to make lovd more the way you'd like it. I really
appreciate you taking the time to write.
Love you too,
steve
Sazima
Victor has good arguments, let me also post some ideas on the items
below:
1) What I miss the most is a state machine for the enrollment process,
like what Bala Paranj did (http://bparanj.blogspot.com/2007/12/simply-
rich-authenticator-using-rails.html). This would be extremely useful
for more sophisticated enrollment processes.
2 & 3) Agree, putting all those filters in the application controller
causes lots of useless DB hits. Another example is ":check_featured".
4) Agree with you.
All in all, thank you very much for Lovd, it's a fantastic start
point. I'm just concerned that after branching away from your code, it
won't be possible to keep up with the platform evolution in any easy
way...
Cheers, Sazima
On Jul 16, 8:50 am, "Steven A Bristol" <st...@lesseverything.com>
wrote:
Steven A Bristol
>
> Steve,
>
> Victor has good arguments, let me also post some ideas on the items
> below:
>
> 1) What I miss the most is a state machine for the enrollment process,
> like what Bala Paranj did (http://bparanj.blogspot.com/2007/12/simply-
> rich-authenticator-using-rails.html). This would be extremely useful
> for more sophisticated enrollment processes.
His svn repo seems to be down. It sounds like an interesting concept.
Feel free to grab me to talk about it. I might be up for moding Less
Authentication to work like that.
>
> 2 & 3) Agree, putting all those filters in the application controller
> causes lots of useless DB hits. Another example is ":check_featured".
Here is my best DHH impression: PDI
>
> 4) Agree with you.
Me too. ;)
>
> All in all, thank you very much for Lovd, it's a fantastic start
> point. I'm just concerned that after branching away from your code, it
> won't be possible to keep up with the platform evolution in any easy
> way...
I think this is a valid concern and quite frankly if anyone strays to
far then branching will be difficult. I sleep well with the belief
that lovd gave them a good start.
I know I am slow at reviewing/accepting changes, but please do
contribute. Feel free to dig in there. Fork Lovd and make it better.
Maybe your branch will become the new master. I am not working on any
lovd projects right now, so I am not doing any development on it.
Please don't let that stop you. Feel free to be inspired and make it
better. Spread the luv :)
Steve
Victor
Steve:
Yes. Thank you for the Lovd. And thank you for taking the comments in
a positive way! I will see what I can do to on the patches.
The main point is if we can use de facto standard components (which
represent the best practices) then we all evolve together with the
standard components. There used to be a bunch of pagination plugins.
Now people seem to standardize on mislev-will-pagination. This is a
good example.
Regarding to 1), Steve's point about login/logout is a very good
point.
Regarding to 4), URLs like lovd.com/steve is much cleaner than
lovd.com/profiles/steve, from users point of view. Of course, the
developers will have to deal with the name clash. I don't have a
solution yet. What is the best practice on issue? I hope that more
people will contribute on this topic.
With Lovd,
Victor
On Jul 17, 12:04 am, "Steven A Bristol" <st...@lesseverything.com>
wrote:
Steven A Bristol
> The main point is if we can use de facto standard components (which
> represent the best practices) then we all evolve together with the
> standard components. There used to be a bunch of pagination plugins.
> Now people seem to standardize on mislev-will-pagination. This is a
> good example.
>
I fully support doing things the rails way except when they clash with
the steve way, like in the auth stuff. :)
>
> Regarding to 4), URLs like lovd.com/steve is much cleaner than
> lovd.com/profiles/steve, from users point of view. Of course, the
> developers will have to deal with the name clash. I don't have a
> solution yet. What is the best practice on issue? I hope that more
> people will contribute on this topic.
I would love to have them be prettier, but the name clashes is too
high to pay (IMO). My own Less apps have renamed the profiles
controller to people so the urls are now /people/1-steve. In these
terms /people/steve is perfectly acceptable. We can do the same thing
in lovd without renaming, just by modifying the route. This would be a
breaking change because profile_path would no longer work (person_path
would work) and I'm not sure it's worth the pain.
I would be fine with /profiles/steve, but I'd like to hear the
preference of others, what level of change/pain are they up for?
steve
Raavin
can't remember exactly what I did. I'll try to lovdize it and see if
it fits. I think I added a column with a sanitized version of the
name. (Actually I just had a quick look and I didn't get around to
managing name clashes but it's not insurmountable.) I don't reckon you
can go on forever with addresses like mysite.com/profile/8765839-my-
name-is-this, when you could have mysite.com/mynameisthis or
mysite.com/mynameisthis2008 or whatever do get over name clashes...for
what it's worth. I'll be workin' on it personally anyway as a high
priority.
Jason :)
On Jul 22, 12:24 am, "Steven A Bristol" <st...@lesseverything.com>
wrote:
Steven A Bristol
>
> Bring on the pain :) I modified insoshi to use mysite.com/steve but I
> can't remember exactly what I did. I'll try to lovdize it and see if
> it fits. I think I added a column with a sanitized version of the
> name. (Actually I just had a quick look and I didn't get around to
> managing name clashes but it's not insurmountable.) I don't reckon you
> can go on forever with addresses like mysite.com/profile/8765839-my-
> name-is-this, when you could have mysite.com/mynameisthis or
> mysite.com/mynameisthis2008 or whatever do get over name clashes...for
> what it's worth. I'll be workin' on it personally anyway as a high
> priority.
>
> Jason :)
Did you ever get a chance to look into this? Do you want some help
from me? Find me in #lovdbyless if you want to talk this through.
steve
Jason Keenan
Jason Keenan
Steven A Bristol
against current controller names, but I don't like having to check for
existing paths before creating a new controller. This is too much pain
for me as a developer.
steve
Jason Keenan
I get not being a fan of the implementation, I'm never a fan of my
implementations. Using and Australianism, I'm a 'pissweak',
programmer, but I'm not sure what you mean about 'having to check for
existing paths before creating a new controller'? Using
'ActionController::Routing.possible_controllers' means...ahh just
realised you mean that you have to check that a new controller name
doesn't match a user defined path.
Mmmm, yes. I get how that would be annoying. I'll have a think about it.
Jason :)
Jason Keenan
Not ideal but what if you had a luvd controller naming convention
where controller names were prefixed with 'luvd' then excluded user
paths with a 'luvd' prefix??
Jason
Steven A Bristol
>
> Steve,
>
> Not ideal but what if you had a luvd controller naming convention
> where controller names were prefixed with 'luvd' then excluded user
> paths with a 'luvd' prefix??
>
> Jason
That's one way to go, but I don't think that is as nice as
/p/user_name or something very easy. What do you think?
Steve
Jason Keenan
Hey Steve,
I suppose I'm a fan of having the simpler site.com/username so I'm pushing
that barrow ;) At the end of the day she's your baby so I'm happy to work
toward site.com/home/username or some such thing. I'll just go the other
route on my own fork. I'll probably look at letting the user choose whether
their 'home' page points to their bio or their blog too.
Jason
Steven A Bristol
>
>
> Hey Steve,
>
> I suppose I'm a fan of having the simpler site.com/username so I'm pushing
> that barrow ;) At the end of the day she's your baby so I'm happy to work
> toward site.com/home/username or some such thing. I'll just go the other
> route on my own fork. I'll probably look at letting the user choose whether
> their 'home' page points to their bio or their blog too.
>
> Jason
>
Sounds good. I'm just not too interested in all that added complexity.
I don't think /user_name vs. /u/user_name is worth it.
steve
Jason Keenan
Cool. I'll get crackin' then :)
Jason