On 29.06.2010, at 19:47, Jim Gay wrote: > I'm glad you brought this up for discussion.
It just felt right after following the github discussion :-) > > On Tue, Jun 29, 2010 at 11:59 AM, Edmund Haselwanter > <[email protected]> wrote: >> A question for clarification: [ .. snippet .. ] >> 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 <quote jlong> jlong February 18, 2010 | link There's a little more work to do on this in the prototype, mainly the upload interface. I believe Chris Parish has had ambitions for simplifying his styles 'n scripts extension to serve this purpose. If it is going to make it into 0.9 it should be implemented as an extension that ships with the core. </quote jlong> That's exactly how I see it too :-) "If it is going to make it into 0.9 it should be implemented as an extension that ships with the core." ==> some extensions for some tasks which are really really common should ship with core. just to make it easier for adoption. > http://github.com/radiant/radiant/issues#issue/92 (paperclipped) <quote jlong> • Has graceful support situations where you don't have ImageMagick or something similar for thumbnails • Allows you to attach files to a page and view all of your files in a browser of some kind • Allows you to easily insert an image into the content of your page </quote jlong> And again: jlong rocks the house :) It doesn't matter to me that much if its based on paperclipped, page_attachments, or something else. I'd just love to see a solution shipping with core. not in core, just with core. Or it might be just a suggestion (get xxxx for assets) >> 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. Yes. You are right. And there are some extensions which add to paperclipped. This is some kind of vote of the community, isn't it ;-) > 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. yeah, but I think SOME asset managing facility should be "near" the core. To all the love of option. Some people just want to get up and running. They should be able to have images, css, javascript right from the start me thinks :-) >> 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. Hm. Its not bullshit. It's how some people see it. I had to fight 20 people to suggest that it would be much more easier to educate people to use textile than to have a WYSIWYG Editor. I'm a textile fan. It just would be create to "have" a solution for this feature request. but ok. there are some extensions out there. must not be in the core neither a core extension > 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. ;-) I do. > That said, there is always room for improvement and there are plenty > of people working on improving it. yesch :-) >> 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 Yeah. And i used the textile toolbar extension. that is nice. >> - 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 I looked at that once. Quite interesting. But I'm more concerned with implementing a an API for e.g. Marsedit or something else. > There is a Ruby Summer of Code project to fix up ActiveResource to do > REST properly with restfulie. interesting. > 1.0 is whatever we say it is. you are right. > 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. I think it is ready for 1.0. Right now. Just to take that number ;-) But with all this mayor numbers, a move to Rails3 should be indicated with this major number. Be it from 0.10 to 1.0 with Rails3 or call it 1.0 now and 2.0 after Rails3/extension-rework. >> 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 really? I don't get it! > 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. that's my 1.0 vs. 2.0 for Rails3 rework. cu edi -- DI Edmund Haselwanter, [email protected], http://edmund.haselwanter.com/
