Rails - Mar 2006 - How painful is the 1.0 -> 1.1 upgrade going to be?

Does anyone have a sense for how painful the 1.0 -> 1.1 upgrade is
going to be for existing apps?  I''m finishing up my first real RoR
application with Rails 1.0.  I can live with it staying at that level,
but I really want to use the has_many :through attribute to clean up
some of my code.

I''m not particularly interested in edge Rails, mainly because the
documentation for installing it seems to be lacking.  I''d rather work
on my app than dink around with modifying various files to get 1.1
working.

Assuming 1.1 comes as a gem update, how much chaos is going to be
injected into my app by running it?

-- James

2006/3/5, James Ludlow <jamesludlow@gmail.com>:
> Assuming 1.1 comes as a gem update, how much chaos is going to be
> injected into my app by running it?
Probably very close to zero chaos.  Don''t quote me on that, though :) 
I''ve been living on the edge since almost day one.  Haven''t
had much
problems.

Seriously, you''ll need Rake 0.7.0 because of the new namespace feature
that is used for the rake tasks.

Bye !
--
Fran?ois Beausoleil
http://blog.teksol.info/

On 3/5/06, Francois Beausoleil <francois.beausoleil@gmail.com>
wrote:
> 2006/3/5, James Ludlow <jamesludlow@gmail.com>:
> > Assuming 1.1 comes as a gem update, how much chaos is going to be
> > injected into my app by running it?
>
> Probably very close to zero chaos.  Don''t quote me on that, though
:)
> I''ve been living on the edge since almost day one. 
Haven''t had much
> problems.
I wouldn''t be worried if I had started with edge.  I''m more
concerned
with what happens when a 1.0 app meets Rails 1.1 cold.
> Seriously, you''ll need Rake 0.7.0 because of the new namespace
feature
> that is used for the rake tasks.
Yep.  I''m running rake 0.7.0.

-- James

On 3/5/06, James Ludlow <jamesludlow@gmail.com>
wrote:
>
> I''m not particularly interested in edge Rails, mainly because the
> documentation for installing it seems to be lacking.  I''d rather
work
> on my app than dink around with modifying various files to get 1.1
> working.
>
If you want to try out Edge Rails it is very easy if you have
subversion installed, just type the following command inside of a
rails project.

rake freeze_edge

--
Joe Clarke
RailsPlayground.com

On 3/5/06, James Ludlow <jamesludlow@gmail.com>
wrote:
> Does anyone have a sense for how painful the 1.0 -> 1.1 upgrade is
> going to be for existing apps?  I''m finishing up my first real RoR
> application with Rails 1.0.  I can live with it staying at that level,
> but I really want to use the has_many :through attribute to clean up
> some of my code.
>
> I''m not particularly interested in edge Rails, mainly because the
> documentation for installing it seems to be lacking.  I''d rather
work
> on my app than dink around with modifying various files to get 1.1
> working.
>
> Assuming 1.1 comes as a gem update, how much chaos is going to be
> injected into my app by running it?
>
> -- James
I can''t think of anything.  The upgrade to 1.0 was nasty with all the
environment changes, new scripts, rake tasks, etc, but it was all for
a good cause.  Future upgrades will be painless.

But, don''t take my word for it.  Do a rake freeze_edge and report back
with problems.

--
Rick Olson
http://techno-weenie.net

On 3/5/06, Rick Olson <technoweenie@gmail.com>
wrote:
> On 3/5/06, James Ludlow <jamesludlow@gmail.com> wrote:
> > Does anyone have a sense for how painful the 1.0 -> 1.1 upgrade is
> > going to be for existing apps?  I''m finishing up my first
real RoR
> > application with Rails 1.0.  I can live with it staying at that level,
> > but I really want to use the has_many :through attribute to clean up
> > some of my code.
> >
> > I''m not particularly interested in edge Rails, mainly because
the
> > documentation for installing it seems to be lacking.  I''d
rather work
> > on my app than dink around with modifying various files to get 1.1
> > working.
> >
> > Assuming 1.1 comes as a gem update, how much chaos is going to be
> > injected into my app by running it?
> >
> > -- James
>
> I can''t think of anything.  The upgrade to 1.0 was nasty with all
the
> environment changes, new scripts, rake tasks, etc, but it was all for
> a good cause.  Future upgrades will be painless.
>
> But, don''t take my word for it.  Do a rake freeze_edge and report
back
> with problems.
I have no problem with getting rails into my vendor directory via
either freeze_edge or svn update (with the externals).  However, my
WEBrick server then fails to start.  Using either method, I end up
with this when trying to start my app.  This is in development mode.

./script/../config/../vendor/rails/activesupport/lib/active_support/dependencies.rb:125:in
`const_missing'': uninitialized constant LoadingModule (NameError)
        from
./script/../config/../vendor/plugins/engines/lib/dependencies_extensions.rb:76
[-- cut stack trace --]

This is the code that fails:

  class RootLoadingModule < LoadingModule
    # hack to allow adding to the load paths within the Rails
Dependencies mechanism.
    # this allows Engine classes to be unloaded and loaded along with standard
    # Rails application classes.
    def add_path(path)
      @load_paths << (path.kind_of?(ConstantLoadPath) ? path :
ConstantLoadPath.new(path))
    end
  end


Did I miss something obvious regarding edge Rails and engines?

-- James

> Did I miss something obvious regarding edge Rails and engines?
Oh, engines depend on a low level feature of Rails and won''t work.  I
think they''re working on fixing it (if it hasn''t been
already).  I
think the new changes will make Rails Engines even better though.

Ahem... so the *public* API hasn''t changed :)

--
Rick Olson
http://techno-weenie.net

Rick Olson wrote:
> I can''t think of anything.  The upgrade to 1.0 was nasty with all
the
> environment changes, new scripts, rake tasks, etc, but it was all for
> a good cause.  Future upgrades will be painless.
>
> But, don''t take my word for it.  Do a rake freeze_edge and report
back
> with problems.
>   
I hate to rain on the parade, but when I tried doing a rake freeze_edge, 
rails stopped working.  It was because there was some conflict between 
gem rails and edge rails on the same machine.  IOW, rake freeze_edge 
doesn''t work on a Windows environment with the 1.8.4beta2 one-click 
install of Ruby and Gem rails 1.0 installed.  It may work on other 
platforms, but on this one it tries to use both edge rails and gem rails 
classes together and it doesn''t work.  That''s the kind of 
incompatibility that I''m running into.

It shouldn''t behave like that, but for some reason it does.

On 3/5/06, Berin Loritsch <bloritsch@d-haven.org>
wrote:
> Rick Olson wrote:
> > I can''t think of anything.  The upgrade to 1.0 was nasty with
all the
> > environment changes, new scripts, rake tasks, etc, but it was all for
> > a good cause.  Future upgrades will be painless.
> >
> > But, don''t take my word for it.  Do a rake freeze_edge and
report back
> > with problems.
> >
> I hate to rain on the parade, but when I tried doing a rake freeze_edge,
> rails stopped working.  It was because there was some conflict between
> gem rails and edge rails on the same machine.  IOW, rake freeze_edge
> doesn''t work on a Windows environment with the 1.8.4beta2
one-click
> install of Ruby and Gem rails 1.0 installed.  It may work on other
> platforms, but on this one it tries to use both edge rails and gem rails
> classes together and it doesn''t work.  That''s the kind of
> incompatibility that I''m running into.
>
> It shouldn''t behave like that, but for some reason it does.
That''s odd.  I don''t recall having issues like that when I
used
windows.  Though, I never actually used freeze_edge, I would
symlink[1] the directory from a common checkout of rails into my
application.  I''ll try this out on my laptop and see if I get the same
behavior.

At any rate, try installing the beta gems.  I''m not sure what the
schedule is for their release, but the latest one is from revision
3780.

gem update rails --source http://gems.rubyonrails.org --include-dependencies

Note: this will then upgrade all your apps.  Remove the specific version with:

gem uninstall rails

--
Rick Olson
http://techno-weenie.net

Rick Olson wrote:
> On 3/5/06, Berin Loritsch <bloritsch@d-haven.org> wrote:
>   
>> Rick Olson wrote:
>>     
>>> I can''t think of anything.  The upgrade to 1.0 was nasty
with all the
>>> environment changes, new scripts, rake tasks, etc, but it was all
for
>>> a good cause.  Future upgrades will be painless.
>>>
>>> But, don''t take my word for it.  Do a rake freeze_edge and
report back
>>> with problems.
>>>
>>>       
>> I hate to rain on the parade, but when I tried doing a rake
freeze_edge,
>> rails stopped working.  It was because there was some conflict between
>> gem rails and edge rails on the same machine.  IOW, rake freeze_edge
>> doesn''t work on a Windows environment with the 1.8.4beta2
one-click
>> install of Ruby and Gem rails 1.0 installed.  It may work on other
>> platforms, but on this one it tries to use both edge rails and gem
rails
>> classes together and it doesn''t work.  That''s the
kind of
>> incompatibility that I''m running into.
>>
>> It shouldn''t behave like that, but for some reason it does.
>>     
>
> That''s odd.  I don''t recall having issues like that when
I used
> windows.  Though, I never actually used freeze_edge, I would
> symlink[1] the directory from a common checkout of rails into my
> application.  I''ll try this out on my laptop and see if I get the
same
> behavior.
>
> At any rate, try installing the beta gems.  I''m not sure what the
> schedule is for their release, but the latest one is from revision
> 3780.
>
> gem update rails --source http://gems.rubyonrails.org
--include-dependencies
>
> Note: this will then upgrade all your apps.  Remove the specific version
with:
>
> gem uninstall rails
>   
I''ll try that.  I''d like to try using the better
acts_as_taggable
plugin--but that uses features from an unreleased version of rails.

> I''ll try that.  I''d like to try using the better
acts_as_taggable
> plugin--but that uses features from an unreleased version of rails.
It should work fine with that gem version.


--
Rick Olson
http://techno-weenie.net

Absolutely correct Rick,

The quirky dependency [re]loading mechanism that Rails had grown has
been replaced with a much simpler and smoother system (which is great
for me because it makes my life a lot easier!)

James - have a gander at this page on the engines site: 
http://rails-engines.org/wiki/pages/Using+Engines+with+Edge+Rails

On 3/6/06, Rick Olson <technoweenie@gmail.com>
wrote:
> > Did I miss something obvious regarding edge Rails and engines?
>
> Oh, engines depend on a low level feature of Rails and won''t work.
I
> think they''re working on fixing it (if it hasn''t been
already).  I
> think the new changes will make Rails Engines even better though.
>
> Ahem... so the *public* API hasn''t changed :)
>
> --
> Rick Olson
> http://techno-weenie.net
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

--
* J *
  ~

On Mar 6, 2006, at 5:01 AM, James Adam wrote:
> Absolutely correct Rick,
>
> The quirky dependency [re]loading mechanism that Rails had grown has
> been replaced with a much simpler and smoother system (which is great
> for me because it makes my life a lot easier!)
Can you expand on this a bit please? or point me someplace that talks  
about it? A "much simpler smoother system" sounds very good :-)
I''ve
been thinking about -- and putting off -- support for the mechanism  
used by Rails 1.0 in xampl.

Cheers,
Bob

>
> James - have a gander at this page on the engines site:
> http://rails-engines.org/wiki/pages/Using+Engines+with+Edge+Rails
>
> On 3/6/06, Rick Olson <technoweenie@gmail.com> wrote:
>>> Did I miss something obvious regarding edge Rails and engines?
>>
>> Oh, engines depend on a low level feature of Rails and won''t
work.  I
>> think they''re working on fixing it (if it hasn''t been
already).  I
>> think the new changes will make Rails Engines even better though.
>>
>> Ahem... so the *public* API hasn''t changed :)
>>
>> --
>> Rick Olson
>> http://techno-weenie.net
>> _______________________________________________
>> Rails mailing list
>> Rails@lists.rubyonrails.org
>> http://lists.rubyonrails.org/mailman/listinfo/rails
>>
>
>
> --
> * J *
>   ~
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
----
Bob Hutchison                  -- blogs at <http://www.recursive.ca/ 
hutch/>
Recursive Design Inc.          -- <http://www.recursive.ca/>
Raconteur                      -- <http://www.raconteur.info/>
xampl for Ruby                 -- <http://rubyforge.org/projects/xampl/>

> > The quirky dependency [re]loading mechanism that Rails had grown has
> > been replaced with a much simpler and smoother system (which is great
> > for me because it makes my life a lot easier!)
>
> Can you expand on this a bit please? or point me someplace that talks
> about it? A "much simpler smoother system" sounds very good :-)
I''ve
> been thinking about -- and putting off -- support for the mechanism
> used by Rails 1.0 in xampl.
>
> Cheers,
> Bob
http://weblog.techno-weenie.net/2006/2/21/unitialized-constant-technoweenie

Please post any additional questions in the comments or on the list
and I''ll do my best to answer.


--
Rick Olson
http://techno-weenie.net

On 3/5/06, Rick Olson <technoweenie@gmail.com>
wrote:
> > Did I miss something obvious regarding edge Rails and engines?
>
> Oh, engines depend on a low level feature of Rails and won''t work.
I
> think they''re working on fixing it (if it hasn''t been
already).  I
> think the new changes will make Rails Engines even better though.
>
> Ahem... so the *public* API hasn''t changed :)
The two engines I was using were LoginEngine and UserEngine.  I''m
currently looking at a combination of acts_as_authenticated and
acl_system to replace these.  Looks simple enough, although the
link_if_authorized tags in UserEngine are really nice and clean, and
there doesn''t appear to be a similar alternative.

Basically, I decided that I wanted to use :through badly enough that
I''d go ahead and switch to edge Rails now, rather than after
I''m done.

-- James

It shouldn''t be too hard to port the link_if_authorized method over to
another system... however, the major disadvantage of the acl_system is
that it''s all declarative and tied to the controller using filters.
The permissions are therefore a bit hard to query from other
controllers, methods and in particular, views in your application.

When I get a chance I''ll produce my own ACL DSL (TLAs, gotta love
''em)
notation which matches the UserEngine''s authorisation scheme, just to
clarify in my mind how it differs from Ezra''s system - intuitively I
think it will differ, since the UserEngine stores its permission
structure in data rather than code. The differences might be small
enough to consolidate and then possibly add helper methods like
''authorized?(controller, action)''. The link_if_authorized
action might
then collapse to link_to_unless authorized?(controller, action),
although in THAT case the syntax is a bit wordy and you also don''t get
the small benefit of having *no* text produced in the event that the
user shouldn''t be able to perform the given action.

Anyway, I''ve started to ramble - if you do decide to stick with the
engines and have any problems, you can always post to our seperate
lists (http://rails-engines.org/wiki/pages/Mailing+Lists for more
info) and we''ll do our best to sort out any problems there. FYI
I''m
using both with Edge Rails without issue at the moment.

- james

On 3/6/06, James Ludlow <jamesludlow@gmail.com>
wrote:
> On 3/5/06, Rick Olson <technoweenie@gmail.com> wrote:
> > > Did I miss something obvious regarding edge Rails and engines?
> >
> > Oh, engines depend on a low level feature of Rails and won''t
work.  I
> > think they''re working on fixing it (if it hasn''t
been already).  I
> > think the new changes will make Rails Engines even better though.
> >
> > Ahem... so the *public* API hasn''t changed :)
>
> The two engines I was using were LoginEngine and UserEngine.  I''m
> currently looking at a combination of acts_as_authenticated and
> acl_system to replace these.  Looks simple enough, although the
> link_if_authorized tags in UserEngine are really nice and clean, and
> there doesn''t appear to be a similar alternative.
>
> Basically, I decided that I wanted to use :through badly enough that
> I''d go ahead and switch to edge Rails now, rather than after
I''m done.
>
> -- James
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

--
* J *
  ~

On 3/6/06, James Adam <james.adam@gmail.com>
wrote:
> It shouldn''t be too hard to port the link_if_authorized method
over to
> another system... however, the major disadvantage of the acl_system is
> that it''s all declarative and tied to the controller using
filters.
> The permissions are therefore a bit hard to query from other
> controllers, methods and in particular, views in your application.
Yes, I definitely prefer the way that UserEngine keeps this in the
database.  My app is simple enough that it''s not really a crisis
either way, but after sleeping on it I''m not sure that acl_system is
going to work for me.  I have a lot of conditional links in my views.
> Anyway, I''ve started to ramble - if you do decide to stick with
the
> engines and have any problems, you can always post to our seperate
> lists (http://rails-engines.org/wiki/pages/Mailing+Lists for more
> info) and we''ll do our best to sort out any problems there. FYI
I''m
> using both with Edge Rails without issue at the moment.
Thanks, I''ll look into that.  It''s interesting that
you''re able to use
both LoginEngine and UserEngine with Edge Rails.  I think I''ll give it
another shot, as maybe I was just doing something dumb the last time.

-- James

I recently added a method like your talking about for conditional  
view display. Its pretty simple and works like this:


     <% restrict_to "admin | moderator" do %>
        <%= link_to "Destroy" %>
     <% end %>

	That method will get the current_user behind the scene and compare  
the users roles with the permissions string in the restrict_to  
method. So the body of the block will only get executed if the user  
has a role that when evaluated with the logic string, returns true.

	This works good for conditional blocks of code or html in the view.  
And the declarative style of access_control in the controller will  
keep users out of controller/actions that they have no right to see.  
But some actions need to be seen by many roles but have certain links  
like destroy that can only be used by one or two roles.



Cheers-
-Ezra

On Mar 6, 2006, at 8:14 AM, James Adam wrote:
> It shouldn''t be too hard to port the link_if_authorized method
over to
> another system... however, the major disadvantage of the acl_system is
> that it''s all declarative and tied to the controller using
filters.
> The permissions are therefore a bit hard to query from other
> controllers, methods and in particular, views in your application.
>
> When I get a chance I''ll produce my own ACL DSL (TLAs, gotta love
''em)
> notation which matches the UserEngine''s authorisation scheme, just
to
> clarify in my mind how it differs from Ezra''s system - intuitively
I
> think it will differ, since the UserEngine stores its permission
> structure in data rather than code. The differences might be small
> enough to consolidate and then possibly add helper methods like
> ''authorized?(controller, action)''. The link_if_authorized
action might
> then collapse to link_to_unless authorized?(controller, action),
> although in THAT case the syntax is a bit wordy and you also don''t
get
> the small benefit of having *no* text produced in the event that the
> user shouldn''t be able to perform the given action.
>
> Anyway, I''ve started to ramble - if you do decide to stick with
the
> engines and have any problems, you can always post to our seperate
> lists (http://rails-engines.org/wiki/pages/Mailing+Lists for more
> info) and we''ll do our best to sort out any problems there. FYI
I''m
> using both with Edge Rails without issue at the moment.
>
> - james
>
> On 3/6/06, James Ludlow <jamesludlow@gmail.com> wrote:
>> On 3/5/06, Rick Olson <technoweenie@gmail.com> wrote:
>>>> Did I miss something obvious regarding edge Rails and engines?
>>>
>>> Oh, engines depend on a low level feature of Rails and
won''t
>>> work.  I
>>> think they''re working on fixing it (if it hasn''t
been already).  I
>>> think the new changes will make Rails Engines even better though.
>>>
>>> Ahem... so the *public* API hasn''t changed :)
>>
>> The two engines I was using were LoginEngine and UserEngine. 
I''m
>> currently looking at a combination of acts_as_authenticated and
>> acl_system to replace these.  Looks simple enough, although the
>> link_if_authorized tags in UserEngine are really nice and clean, and
>> there doesn''t appear to be a similar alternative.
>>
>> Basically, I decided that I wanted to use :through badly enough that
>> I''d go ahead and switch to edge Rails now, rather than after
I''m
>> done.
>>
>> -- James
>> _______________________________________________
>> Rails mailing list
>> Rails@lists.rubyonrails.org
>> http://lists.rubyonrails.org/mailman/listinfo/rails
>>
>
>
> --
>
> * J *
>   ~
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
-Ezra Zygmuntowicz
Yakima Herald-Republic
WebMaster
http://yakimaherald.com
509-577-7732
ezra@yakima-herald.com

On 3/6/06, Ezra Zygmuntowicz <ezra@yakima-herald.com>
wrote:
>         I recently added a method like your talking about for conditional
> view display. Its pretty simple and works like this:
>
>
>      <% restrict_to "admin | moderator" do %>
>         <%= link_to "Destroy" %>
>      <% end %>
>
>         That method will get the current_user behind the scene and compare
> the users roles with the permissions string in the restrict_to
> method. So the body of the block will only get executed if the user
> has a role that when evaluated with the logic string, returns true.
Thanks.  Please don''t take this as a complaint or whining, but this
isn''t as DRY as link_if_authorized.  The rights for a given action
have to be defined in the controller and the view (and many times if
you have a lot of conditional RHTML), as opposed to only one place for
UserEngine.

I''m not saying that this is a deal breaker for acl_system, but
it''s
part of the pros and cons that I''m currently weighing.


-- James

On Mar 6, 2006, at 1:41 PM, James Ludlow wrote:
> On 3/6/06, Ezra Zygmuntowicz <ezra@yakima-herald.com> wrote:
>>         I recently added a method like your talking about for  
>> conditional
>> view display. Its pretty simple and works like this:
>>
>>
>>      <% restrict_to "admin | moderator" do %>
>>         <%= link_to "Destroy" %>
>>      <% end %>
>>
>>         That method will get the current_user behind the scene and  
>> compare
>> the users roles with the permissions string in the restrict_to
>> method. So the body of the block will only get executed if the user
>> has a role that when evaluated with the logic string, returns true.
>
> Thanks.  Please don''t take this as a complaint or whining, but
this
> isn''t as DRY as link_if_authorized.  The rights for a given action
> have to be defined in the controller and the view (and many times if
> you have a lot of conditional RHTML), as opposed to only one place for
> UserEngine.
>
> I''m not saying that this is a deal breaker for acl_system, but
it''s
> part of the pros and cons that I''m currently weighing.
>
>
> -- James
	No offense taken, I''m thick skinned ;) I see what you are talking  
about now. I had never looked at the user engine before. It wouldn''t  
be too hard at all to add something like this if you would use it.  
Let me know and I can add a method for you. Also this weekend will be  
the next release of a newer version of acl_system with a bunch more  
functionality including individual model record protection.

Cheers-
-Ezra Zygmuntowicz
Yakima Herald-Republic
WebMaster
http://yakimaherald.com
509-577-7732
ezra@yakima-herald.com

On 3/6/06, Ezra Zygmuntowicz <ezra@yakima-herald.com>
wrote:
>
> On Mar 6, 2006, at 1:41 PM, James Ludlow wrote:
>
> > On 3/6/06, Ezra Zygmuntowicz <ezra@yakima-herald.com> wrote:
> >>         I recently added a method like your talking about for
> >> conditional
> >> view display. Its pretty simple and works like this:
> >>
> >>
> >>      <% restrict_to "admin | moderator" do %>
> >>         <%= link_to "Destroy" %>
> >>      <% end %>
I updated to your latest code and this is working fine.  I''m sure you
knew that, but there''s a field test for what it''s worth.

[snip -- restrict_to isn''t DRY ]
>  No offense taken, I''m thick skinned ;) I see what you are talking
> about now. I had never looked at the user engine before. It
wouldn''t
> be too hard at all to add something like this if you would use it.
> Let me know and I can add a method for you. Also this weekend will be
> the next release of a newer version of acl_system with a bunch more
> functionality including individual model record protection.
If you wrote it, I''d use it and appreciate it greatly.  I''m
also very
interested in your new code coming this weekend.

Since you said that you hadn''t looked at UserEngine, here''s a
couple tidbits.

UserEngine has a Permissions class in addition to the Role and User. 
A Permission is a combination of role, controller, and action.  This
all gets stored in the database, so it''s only defined once. 
It''s not
as expressive as what you have, where you can easily combine roles
logically.  But it seemed to be great for simple mappings of Role X
can do Action Y.

The two main helper methods were a big selling point for me though.
authorized?(:controller => ''foo'', :action =>
''bar'')
link_if_authorized("Some Page", {:controller =>
''foo'', :action => ''bar''})


Thank you for what you''ve already done.  This alone is enough to get
me started on plugging everything together.

-- James