I'm glad you brought this up for discussion.

On Tue, Jun 29, 2010 at 11:59 AM, Edmund Haselwanter
<edm...@haselwanter.com> wrote:
> A question for clarification:
>
> I like to have options, but sometimes options are a bit confusing.
>
> On 29 Jun., 06:56, john muhl <johnm...@gmail.com> wrote:
>> Jim (saturnflyer) and i have been working (most of the important work
>> is Jim's) on a branch of page_attachments that adds some new interface
>> features to the page_attachments extension
>
> so here is the question on options:
>
> wouldn't it be wise to concentrate on just one (nifty) asset
> extension?
> I see an asset extension as a vital part of a CMS (=> see, it says
> content ;-)

Yes.
Check out the prototype http://github.com/radiant/radiant-prototype

And there are tickets like
http://github.com/radiant/radiant/issues#issue/28 (sns) and
http://github.com/radiant/radiant/issues#issue/92 (paperclipped)

>
> or the other way round: what would you suggest to use in the future?
>
> - page_attachements
> - paperclipped (and there are some extensions which extend
> paperclipped)
> - gallery (ok. its just for images ..)
> - MediaMaid

The greatness behind paperclipped is paperclip (not to take away from
all the work that Keith and many others put in to make a really useful
extension). I like page_attachments too and recently did a lot of work
to change it on my fork with John Muhl's help, but for a recent
project I was again looking for an asset manager and even though I did
all that work to update page_attachments (and it still needs more) I
chose paperclipped because of paperclip.
I've not used gallery and have only perused the code of MediaMaid but
plan to look at them more in the future.

I wish there was an easy answer, but keeping things simple is hard
work. One of the tickets I mentioned above suggests pulling in
paperclipped as it is just because so many use it and it would do the
job. But Radiant has gained popularity due to it's simplicity, so
"just because" isn't good enough.

>
> and with this comes another question:
>
> Ok, I know that Radiant is "different". And I love it. I recently did
> a
> presentation in my web 2.0 community meeting about radiant. And one
> statement
> burned so hard: No end user will use this!

Bullshit. It's just not true. I've had plenty of non-technical,
non-tech-savvy users enjoying Radiant.
But I will say that it is very easy to look at Radiant, and probably
look at the presentation you put together, and claim that no end user
would use it, but that's mere conjecture.
Take what people say with a grain of salt if they haven't actually
used the software.

That said, there is always room for improvement and there are plenty
of people working on improving it.

>
> Why do I come up with this? And why now? Because I followed the
> discussion about radiant
> version numbers.

For others, this is a reference to a discussion in the comments an
unrelated commit on github
http://github.com/radiant/radiant/commit/488c2a49c40ced133d3c4abebb66e55fc2df9e6c

Hilariously, it was suggested in the thread to move to the mailing
list for discussion, but nobody did it except of course someone who
wasn't in on the thread.
Thank you Edmund!

>
> And here goes my suggestion:
>
> Radiant 1.0 should:
>
> - be Rails3 based
> - have some core asset handling features (doesn't matter if this is an
> extension)
> - have one WYSIWYG Editor integrated with this assets and other
> ressources (e.g. allow for search pages and insert a link)

see this http://github.com/radiant/radiant/issues/#issue/26 and this
http://github.com/radiant/radiant/issues/#issue/33

> - should define a way on how to do i18n content (not admin area)
> - should have some eyecandy like a HUD were you can search a page
> based e.g. on the title (a nvaigation alternative, if you like)
> - should define a blogging API so that it can be used with some
> standard blogging tools.

I'm very interested in how Rails will lead the way with REST and
http://github.com/caelum/restfulie
There is a Ruby Summer of Code project to fix up ActiveResource to do
REST properly with restfulie.

1.0 is whatever we say it is.
And to quote DHH, "I've long been impressed and puzzled by the power
of big version numbers. To open source projects like Ruby on Rails,
it's such a divorced measure of quality of features that I feel we
need to take it's importance down a few notches."

http://www.loudthinking.com/posts/20-dont-overestimate-the-power-of-versions

So 1.0 can come whenever we want. If everyone wants all those things
to be in 1.0, fine, that'll be 1.0 but 1.0 will only arrive when those
things do. That's why I'm in favor of moving to 1.0 with Rails 3 and
calling it a day. "1.0" in particular is so overblown that by the time
Radiant reaches "1.0" there will be plenty of complaints about how it
doesn't have this or that feature which could, of course, easily come
at 1.1, 2.0 or version 999.

Radiant is over 4 years old now and is used in hundreds of production sites.

>
> And again: I love Radiant. I use it very much. I do contribute back. I
> want to make it better.

And thank you for your contributions! It's because of contributions
that bugs are fixed, libraries are updated, and features are added.

>
> So what do you think about it?

It sucks. :-D

>
> cu edi
>

And John Long mentioned in that github commit thread that 1.0 should
happen when things are more stable with regard to extensions. I agree,
but I see the move to Rails 3 requiring a rework of the extension
system, so to me a move to Rails 3 is inclusive of that.

-Jim

-- 
Jim Gay
Saturn Flyer LLC
http://www.saturnflyer.com
571-403-0338

Reply via email to