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 L. [email protected]:
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 !
On 3/5/06, Francois B. [email protected] wrote:
2006/3/5, James L. [email protected]:
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 L. [email protected] wrote:
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 O.
http://techno-weenie.net
On 3/5/06, James L. [email protected] 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 C.
On 3/5/06, Rick O. [email protected] wrote:
working.
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 O.
http://techno-weenie.net
Rick O. 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.
Rick O. wrote:
It shouldn’t behave like that, but for some reason it does.
-
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.
On 3/5/06, Berin L. [email protected] wrote:
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 O.
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 O. [email protected] wrote:
http://techno-weenie.net
Rails mailing list
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/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 O.
http://techno-weenie.net
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 O.
http://techno-weenie.net
On 3/5/06, Rick O. [email protected] 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
On Mar 6, 2006, at 5:01 AM, James A. 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
–
Rails mailing list
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails
Bob H. – 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/
On 3/6/06, James A. [email protected] 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
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.
On 3/6/06, James L. [email protected] wrote:
currently looking at a combination of acts_as_authenticated and
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails
–
On 3/6/06, Ezra Z. [email protected] wrote:
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 L. wrote:
That method will get the current_user behind the scene and
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 Z.
Yakima Herald-Republic
WebMaster
509-577-7732
[email protected]
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 A. wrote:
structure in data rather than code. The differences might be small
info) and we’ll do our best to sort out any problems there. FYI I’m
think they’re working on fixing it (if it hasn’t been already). I
Basically, I decided that I wanted to use :through badly enough that
–
Rails mailing list
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails
-Ezra Z.
Yakima Herald-Republic
WebMaster
509-577-7732
[email protected]