Permalink
Browse files

proper Status lookup

  • Loading branch information...
1 parent 38d49d0 commit 488c2a49c40ced133d3c4abebb66e55fc2df9e6c @saturnflyer saturnflyer committed Jun 24, 2010
Showing with 2 additions and 2 deletions.
  1. +2 −2 app/controllers/site_controller.rb
@@ -31,10 +31,10 @@ def show_page
private
def batch_page_status_refresh
@changed_pages = []
- @pages = Page.find(:all, :conditions => {:status_id => 90})
+ @pages = Page.find(:all, :conditions => {:status_id => Status[:scheduled]})
@seancribbs

seancribbs Jun 24, 2010

Owner

Can we start to discourage the use of find(:all) in our core code? Its past time we had some named scopes anyway.

@jlong

jlong Jun 24, 2010

Owner

Seems like it might be useful to have a Radiant Refactor Day to deal with some of this stuff as a community.

@saturnflyer

saturnflyer Jun 24, 2010

Owner

Is it worth it? I'd like to move to Rails 3 and use ARel, so removing the find(:all) would be just a useless exercise. Want to hack on mislav's Rails 3 branch instead?

@seancribbs

seancribbs Jun 24, 2010

Owner

Not for this release - but named_scope is easily changed to scoped (or whatever the class method is called)

@ghost

ghost Jun 24, 2010

I'm very keen to see more named_scope in there. I find it strange not being able to use them. I think it's more than a day, though. There's a lot of old code in eg. standard_tags. But count me in for a refactoring day or two after 0.9.

@mislav

mislav Jun 24, 2010

Member

I plan to finalize the Rails 3 migration after they release an RC. The rails3 branch would also be a good place to do any refactoring like this. I agree that no needles code changes should be made for this 0.9 release.

@jlong

jlong Jun 27, 2010

Owner

@mislav, would it be possible to get your changes merged over into a 'rails3' branch on the main account? @saturnflyer I'm thinking a simple push to Rails 3 should be the primary focus of the next release and after that we can do another release for breaking things down into engines. Does that sound good? I would really love to shorten the release cycle somehow.

@saturnflyer

saturnflyer Jun 28, 2010

Owner

Definitely faster release cycles are in order. I see a move to Rails 3 as a 1.0 thing but actually think 1.0 should have happend a long time ago.

@jlong

jlong Jun 28, 2010

Owner

@saturnflyer are you suggesting that we call the next release 1.0 or that we delay the move to Rails 3?

@saturnflyer

saturnflyer Jun 28, 2010

Owner

No. I'm suggesting that Rails 3 in Radiant is Radiant 1.0

@jlong

jlong Jun 28, 2010

Owner

Mmm. So the next release should be 1.0?

@mislav

mislav Jun 28, 2010

Member

Apart from possible bugfix releases, why not? But we should take this to the mailing list maybe :)

@saturnflyer

saturnflyer Jun 28, 2010

Owner

If people want to discuss it on the mailing list, that's fine with me, but 1.0 means whatever we want. Moving to Rails 3 is a big change and we're already at 0.9 so we might as well get this mean-whatever-you-want milemarker behind us. We've already had API breaking changes that justify going from one major version to another, yet we're still in "prerelease".

Then next releases can be 0.9.2, 0.9.3, etc, but Rails 3 is a major change and justifies changing the major version number. When we have breaking changes, we should bump the major version.

I wholeheartedly agree with John Trupiano about versioning: http://github.com/jtrupiano/i_dont_trust_your_code/blob/master/4-release/1-versions.md

@jlong

jlong Jun 28, 2010

Owner

1.0 is going to be a huge thing for us, so while my views on versioning and what we should have done with Radiant have changed, I think we should hold off on 1.0 until things are a little more stable (particularly with extensions). To me this means that 0.10.0 should be Rails 3 followed by 1.0 with the segmented core.

@ghost

ghost Jun 28, 2010

"It defines an API that won't break without a good reason (and another major version bump)"

would imply quite a lot of documentation, and rightly, I think. I don't mind working on that. If we document a formal API and feature set then we'll have much more freedom to change the underlying structure.

@jlong

jlong Jun 28, 2010

Owner

That would be cool. RDoc would be a great place to start. You might also have a look at what the Rails team has done with Rails Guides. That code is all open source.

@mislav

mislav Jun 28, 2010

Member

What do you mean with "segmented core"?

Regarding versioning, I like SemVer. And when I suggested the mailing list I thought it would be best to take a lengthy discussion there because it's easier to reply, and gets our dev community aware of how the core guys envision the roadmap for the project to be.

@jlong

jlong Jun 28, 2010

Owner

@mislav I am referring to ticket #23. I like semver too.

@pages.each do |page|
if page.published_at <= Time.now
- page.status_id = 100
+ page.status_id = Status[:published]
page.save
@changed_pages << page.id
end

0 comments on commit 488c2a4

Please sign in to comment.