Catch up time
27 views
Skip to first unread message
Sam Whited
Sep 3, 2013, 7:31:06 PM9/3/13
to Radiant CMS: Dev
Can someone catch me up on the state of Radiant development? I'd like
to do some work this weekend if I get a chance, but have been out of
the loop.
What's on master right now?
What version of Rails are we targeting?
What version of Ruby?
More generally:
What works and what doesn't (I see there's some engine code now, but
the generators are still Rails 2.x generators which are deprecated)?
Are the specs up to date and correct for where we want to go (even if
they're not passing)?
Is there any sort of overall roadmap?
Thanks (and sorry in advance for the ridiculously open ended/generic questions).
—Sam
--
Sam Whited
pub 4096R/EC2C9934
https://samwhited.com/contact
to do some work this weekend if I get a chance, but have been out of
the loop.
What's on master right now?
What version of Rails are we targeting?
What version of Ruby?
More generally:
What works and what doesn't (I see there's some engine code now, but
the generators are still Rails 2.x generators which are deprecated)?
Are the specs up to date and correct for where we want to go (even if
they're not passing)?
Is there any sort of overall roadmap?
Thanks (and sorry in advance for the ridiculously open ended/generic questions).
—Sam
--
Sam Whited
pub 4096R/EC2C9934
https://samwhited.com/contact
Jim Gay
Sep 4, 2013, 9:53:38 AM9/4/13
to radiant...@googlegroups.com
Thanks for jumping back in. I'll answer inline below.
On Tue, Sep 3, 2013 at 7:31 PM, Sam Whited <s...@samwhited.com> wrote:
> Can someone catch me up on the state of Radiant development? I'd like
> to do some work this weekend if I get a chance, but have been out of
> the loop.
>
> What's on master right now?
Master is whatever needs to be done to move to rails 3 (preferably 4).
The goal is: get specs passing, get the app working as an engine.
This means that some things will need to be moved around. We're
dropping dataset. I attempted to rescue it for a while, I think it's a
great project, but it's too much yak shaving.
Benny brought in FactoryGirl which is working fine.
With that though, we should be wary of making too many factories.
Simple and few factories is good, and make alterations required for
the specs as local to the spec as is reasonable. In other words,
initialize your objects in the spec and change their attributes there
where you need to see the change.
With dataset, we had too many fixtures that you had to know existed or
forced you to go off and read the dataset file to understand. Also,
there are plenty of places where we simply don't need records in the
database at all.
This change will help us keep requirements local to the specs and help
kill off unnecessary database access.
> What version of Rails are we targeting?
Right now it's 3.2, but I'd rather it be 4. It is only 3.2 because 4
is so new and 3.2 was already in the Gemfile. It's likely that getting
3.2 working will be hard enough, and that moving to 4 after that will
be simple. I encourage any contribution to move it toward 4 without
putting any more serious burden on the project that still doesn't run
3 yet. I'd say that things like targeting 3 but aliasing the methods
for 4 would be good. An example would be changes in controllers from
before_filter to before_action. We can do both.
> What version of Ruby?
I think we should drop 1.8.7 and only shoot for 1.9.3 and above.
Shortly after release we should push to 2.x.
>
> More generally:
>
> What works and what doesn't (I see there's some engine code now, but
> the generators are still Rails 2.x generators which are deprecated)?
Anything that is Rails 2 should be changed or ripped out. If you want
to tackle generators, please do.
> Are the specs up to date and correct for where we want to go (even if
> they're not passing)?
Mostly. Through some of my work I found that I had to delete tests or
move them to new specs.
Everything is (or should be) under the radiant namespace now, but we
may have arguments about that here.
For example the controllers are all under radiant. So we have
radiant/admin/pages_controller.rb and radiant/site_controller.rb.
But should the models do that as well? If you add Radiant to your
project as an engine, would you expect that Page is a top level name?
Or should it be Radiant::Page? The latter means we'll need to change a
lot of view code to support the forms and ensure that each model has
the proper table name. And should the tables be renamed like
radiant_pages?
I'm leaving that stuff up for thought and debate until we have specs
running on rails 3 or 4 first.
> Is there any sort of overall roadmap?
No. The github issues is the current place but I've personally only
been trying to get it upgraded without worrying about feature
additions or changes.
Perhaps a new ROADMAP file is the best place for now, but throw out
any suggestion you have.
>
> Thanks (and sorry in advance for the ridiculously open ended/generic questions).
Thank YOU!
> --
--
Write intention revealing code #=> http://www.clean-ruby.com
Jim Gay
Saturn Flyer LLC
571-403-0338
On Tue, Sep 3, 2013 at 7:31 PM, Sam Whited <s...@samwhited.com> wrote:
> Can someone catch me up on the state of Radiant development? I'd like
> to do some work this weekend if I get a chance, but have been out of
> the loop.
>
> What's on master right now?
The goal is: get specs passing, get the app working as an engine.
This means that some things will need to be moved around. We're
dropping dataset. I attempted to rescue it for a while, I think it's a
great project, but it's too much yak shaving.
Benny brought in FactoryGirl which is working fine.
With that though, we should be wary of making too many factories.
Simple and few factories is good, and make alterations required for
the specs as local to the spec as is reasonable. In other words,
initialize your objects in the spec and change their attributes there
where you need to see the change.
With dataset, we had too many fixtures that you had to know existed or
forced you to go off and read the dataset file to understand. Also,
there are plenty of places where we simply don't need records in the
database at all.
This change will help us keep requirements local to the specs and help
kill off unnecessary database access.
> What version of Rails are we targeting?
is so new and 3.2 was already in the Gemfile. It's likely that getting
3.2 working will be hard enough, and that moving to 4 after that will
be simple. I encourage any contribution to move it toward 4 without
putting any more serious burden on the project that still doesn't run
3 yet. I'd say that things like targeting 3 but aliasing the methods
for 4 would be good. An example would be changes in controllers from
before_filter to before_action. We can do both.
> What version of Ruby?
I think we should drop 1.8.7 and only shoot for 1.9.3 and above.
Shortly after release we should push to 2.x.
>
> More generally:
>
> What works and what doesn't (I see there's some engine code now, but
> the generators are still Rails 2.x generators which are deprecated)?
to tackle generators, please do.
> Are the specs up to date and correct for where we want to go (even if
> they're not passing)?
move them to new specs.
Everything is (or should be) under the radiant namespace now, but we
may have arguments about that here.
For example the controllers are all under radiant. So we have
radiant/admin/pages_controller.rb and radiant/site_controller.rb.
But should the models do that as well? If you add Radiant to your
project as an engine, would you expect that Page is a top level name?
Or should it be Radiant::Page? The latter means we'll need to change a
lot of view code to support the forms and ensure that each model has
the proper table name. And should the tables be renamed like
radiant_pages?
I'm leaving that stuff up for thought and debate until we have specs
running on rails 3 or 4 first.
> Is there any sort of overall roadmap?
been trying to get it upgraded without worrying about feature
additions or changes.
Perhaps a new ROADMAP file is the best place for now, but throw out
any suggestion you have.
>
> Thanks (and sorry in advance for the ridiculously open ended/generic questions).
> --
--
Write intention revealing code #=> http://www.clean-ruby.com
Jim Gay
Saturn Flyer LLC
571-403-0338
Sam Whited
Sep 4, 2013, 9:59:49 AM9/4/13
to Radiant CMS: Dev
On Wed, Sep 4, 2013 at 9:53 AM, Jim Gay <j...@saturnflyer.com> wrote:
> Thanks for jumping back in. I'll answer inline below.
Wow, I've got a hell of a lot of catching up to do. Thanks for the
> Thanks for jumping back in. I'll answer inline below.
responses! It may be that I should wait on pulling auth/users out into
extensions until after we have something that at least runs (so I can
test). I'll work on some of the specs for now, and maybe tackle
generators if I get a chance (though I have no desire to learn Rails
3/4... I gave up on Rails ages ago; oh well).
Reply all
Reply to author
Forward
0 new messages