Skip to content

Commit

Permalink
proper Status lookup
Browse files Browse the repository at this point in the history
  • Loading branch information
saturnflyer committed Jun 24, 2010
1 parent 38d49d0 commit 488c2a4
Showing 1 changed file with 2 additions and 2 deletions.
4 changes: 2 additions & 2 deletions app/controllers/site_controller.rb
Expand Up @@ -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]})

This comment has been minimized.

Copy link
@seancribbs

seancribbs Jun 24, 2010

Contributor

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

This comment has been minimized.

Copy link
@jlong

jlong Jun 24, 2010

Member

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

This comment has been minimized.

Copy link
@saturnflyer

saturnflyer Jun 24, 2010

Author Member

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?

This comment has been minimized.

Copy link
@seancribbs

seancribbs Jun 24, 2010

Contributor

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

This comment has been minimized.

Copy link
@spanner

spanner 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.

This comment has been minimized.

Copy link
@mislav

mislav Jun 24, 2010

Contributor

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.

This comment has been minimized.

Copy link
@jlong

jlong Jun 27, 2010

Member

@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.

This comment has been minimized.

Copy link
@saturnflyer

saturnflyer Jun 28, 2010

Author Member

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.

This comment has been minimized.

Copy link
@jlong

jlong Jun 28, 2010

Member

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

This comment has been minimized.

Copy link
@saturnflyer

saturnflyer Jun 28, 2010

Author Member

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

This comment has been minimized.

Copy link
@jlong

jlong Jun 28, 2010

Member

Mmm. So the next release should be 1.0?

This comment has been minimized.

Copy link
@mislav

mislav Jun 28, 2010

Contributor

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

This comment has been minimized.

Copy link
@saturnflyer

saturnflyer Jun 28, 2010

Author Member

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

This comment has been minimized.

Copy link
@jlong

jlong Jun 28, 2010

Member

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.

This comment has been minimized.

Copy link
@spanner

spanner 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.

This comment has been minimized.

Copy link
@jlong

jlong Jun 28, 2010

Member

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.

This comment has been minimized.

Copy link
@mislav

mislav Jun 28, 2010

Contributor

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.

This comment has been minimized.

Copy link
@jlong

jlong Jun 28, 2010

Member

@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
Expand Down

0 comments on commit 488c2a4

Please sign in to comment.