On 22 December 2010 19:07, Dan Croak <dcr...@thoughtbot.com> wrote:
I am not sure why this is necessary but your email blog post will explain
the same, I hope.
I would suggest creating another gem called "clearance_extension" or
something similar (which is what Rails 3 did when it took out
form.error_messages). This gem could hold all the functionality that is not
part of the main clearance gem for example: email confirmation bit. If a
user wants to keep the email_confirmation bit then they need to install this
gem. I know this will create a responsibility of maintaining an additional
gem, but I would like to put my name forward for creating and maintaining it
should thoughtbot decide to go down this route. Anyway, I will have a go at
It's been overdue and I would like to see how bundler can be used for
development in a Rails Engine. I tried few experiments of using bundler for
developing a Rails engine and then in the test rails app and for some reason
or other it would just error out. I looked at Spree's code and it took me
ages to get bundler set up with it and just felt wrong. It could be me but
it was just convoluted.
> 3) Remove 403::Forbidden
> This is related to #1. Setting the 403 status code has turned out to
> be an awful user experience in some browsers such as Chrome on Windows
> machines. This is a relatively benign change that shouldn't affect
> developers using Clearance in their apps but should result in a better
> user experience for users of applications that use Clearance.
> 4) Remove deprecations
> Many methods in the library were deprecated over a year or more. We're
> going to finally remove those methods as the warning time has been
> Once we complete #1, #2, #3, and #4, we will probably release
> Clearance 1.0. We feel the removal of the email confirmations is a big
> enough API change to warrant it.
> After 1.0 is released, we have some ideas for 1.1. They include:
> * Removing dependency on default_url_options. This has been a major
> cause of problems according to reports in Github Issues. This should
> be an easy and benign change.
* Removing the views generator. With email confirmation gone, the
> views are pretty simple. The only tricky form is the password reset.
> We have a formatastic generator that seems like overkill and there are
> open patches for a Haml generator that we're concerned we'd be bad
> about maintaining since we don't use Haml. Does anyone have ideas
> here? This is feeling like a "good documentation" task rather than a
> "generators which need to be well-tested and maintained" task to me.
> * Removing password confirmation. Controversial and we've barely
> talked about it but while we're streamlining, we should talk about it.
All these things that are on the borderline and do not fit the current
thoughtbot workflow can all go into clearance_extension gem. This would
really move the noise out of clearance and leave it with core functionality
to deal with. If for some reason, a need arises (or you feel) to bring some
functionality in the clearance_extension into the clearance gem, then it can
be moved and made part of the core.
> Depending on how those go, we have some ideas for later releases,
> version numbers pending, but maybe 2.0. They include:
> * Switching to BCrypt. The Ruby community seems headed that way, for
> seemingly good reasons, and we're happy to follow their lead.
I think I created this issue based on some suggestion in the ML.
* Making Clearance::User database-agnostic. We've used it on Mongo
> apps and it wasn't bad to alter it outside the library so it might
> make sense to formalize it in the library.
That would be amazing.
* Use Rack for session/cookie storage. This is also the direction
> libraries like Devise/Warden are going. From a code purity standpoint,
> we like this idea but in practice it hasn't really been an issue so
> has always been low priority. I don't think we're interested in adding
> a Warden dependency to Clearance but looking for feedback here as
I think if you don't feel the need for it, don't do it. Let the requirements
and the community opinion drive the clearance development.
We recognize Clearance is a very opinionated library that won't meet
> everyone's needs but that's okay in an environment with other options
> like Devise, Authlogic, and Restful Authentication. We want to have a
> simple, small, well-tested, and useful authentication library that
> fits most of our goals across the 30 or so Rails apps we work on every
> year. If we hit those goals, we feel others will benefit as well.
> That's been true in the library's life so far and we hope that will
clearance_extension gem solves this problem as well as it will allow users
to add new functionalities and at the same time keep the clearance core
clean. However, this will have to be controlled in some fashion otherwise
this can get out of hands easily and I am more than willing to manage it.
> Let us know what you think.
I am for one is quite relieved because clearance repository has been quite
for a while with not much going on and I am looking forward to the
amendments and modifications.
Please give your feedback on my thoughts.
> Rails, jQuery, and vim training from thoughtbot, the makers of Clearance:
> To unsubscribe from this group, send email to
> firstname.lastname@example.org<thoughtbot-clearance%2Bun email@example.com>