I'm glad you brought this up for discussion. On Tue, Jun 29, 2010 at 11:59 AM, Edmund Haselwanter <[email protected]> wrote: > A question for clarification: > > I like to have options, but sometimes options are a bit confusing. > > On 29 Jun., 06:56, john muhl <[email protected]> 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
