On Tue, Jun 29, 2010 at 2:24 PM, Haselwanter Edmund <[email protected]> wrote: > > 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 :-)
SNS needs some more thought (which I happen to be doing http://www.saturnflyer.com/blog/jim/2010/06/29/ruby-metaprogramming-is-awesome/ ) but I see that as a necessity for managing a site (along with image/file management of course). > > "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. This is definitely a good idea. I've been working on breaking all features up into extensions http://github.com/radiant/radiant/issues#issue/23 So turning things on or off like we do with the translations will be easier. > >> 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) There definitely needs to be something bundled and all of John's points are spot on. > >>> 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 ;-) Yes, but partly because paperclipped had so much more done. Keith did a great job creating it and it's feature set blows page_attachments out of the water, but as I've heard John Muhl point out, some users find the interface (like the assets bucket) confusing and the simplicity of a list on a page (a la page_attachments) is very easy to understand. > >> 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 :-) With each project I do, I add to the extensions that I use. So, at least for me, it moves things forward in a way that's dictated by real projects. This might mean slow progress on one hand, but the progress is based on real usage and not dreaming up nice to have ideas. (I'm not suggesting that's what anyone is doing, I'm implying what I am not doing). > >>> 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 Seriously!? "No end user will use this!" I don't know who, other than end users, actually use any Radiant project I've worked on. > >> 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. Yes. Jason's work is great. But the toolbar he had been working on for the core would work with Markdown or Textile and would eventually allow other text filtering types too. > >>> - 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. That's been an official goal for years, but nobody has tackled it. If you've got the time or inclination, it would be great to see it started in a fork somewhere. > >> 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. I agree. > >>> 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! Now I'm confused. > >> 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/ > > > > > -- Jim Gay Saturn Flyer LLC http://www.saturnflyer.com 571-403-0338
