Re: [Radiant] What is Radiant 1.0 and which Asset extension to use, was: page_attachments interface enhancements
On 30 Jun 2010, at 02:04, Jim Gay wrote: On Tue, Jun 29, 2010 at 8:50 PM, Jeff Casimir j...@casimircreative.com wrote: I'd like to see radiant follow some of the footsteps from merb and have two gems: radiant-core and radiant-more. The 'radiant' gem would snip To me, radiant-more would be the part that adds snippets, layouts, users, image/file management, stylesheet/javascript management, and perhaps other things. Other people might not see it that way, but by far one of the most popular questions I get about Radiant has to do with adding it to an rails app, rather than shoe-horning a rails app into it. The biggest sticking point is the User system. I completely agree here, except that I think a page-management engine has to be able to work with layouts, and I'd like to see versioning in core. Then a -more gem could add: - users - assets - snippets and js/css - sites - configuration - dashboard If it did that in a modular way that allowed areas of functionality to be omitted or supplanted: radiant.handle :images, :with = DragonflyExtension radiant.handle :authorization, :with = RbacExtension radiant.handle :dashboard, :with = MyLocalExtension radiant.unhandle :configuration then radiant could realistically offer to drop in anywhere and manage pages for any app, which would be a splendid thing indeed. will
Re: [Radiant] What is Radiant 1.0 and which Asset extension to use, was: page_attachments interface enhancements
On Tue, Jun 29, 2010 at 8:50 PM, Jeff Casimir j...@casimircreative.com wrote: I'd like to see radiant follow some of the footsteps from merb and have two gems: radiant-core and radiant-more. So one other idea I had on about this is to add the ability to the extension registry for users to create lists of extensions. If you couple this with the radiant command you could then do something like this on install: radiant -d sqlite3 --extensions jlong:fancypants path/to/radiant/project Which would install all of the gems for extensions from my fancypants list in addition to creating and configuring my Radiant project. Then add a radiant user in the extension registry and radiant-more becomes: radiant -d sqlite3 -e radiant:more path/to/radiant/project -- John Long http://wiseheartdesign.com http://recursivecreative.com
Re: [Radiant] What is Radiant 1.0 and which Asset extension to use, was: page_attachments interface enhancements
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
Re: [Radiant] What is Radiant 1.0 and which Asset extension to use, was: page_attachments interface enhancements
On Tue, Jun 29, 2010 at 2:31 PM, Marshal Linfoot mlinf...@gmail.com wrote: On Tue, Jun 29, 2010 at 1:47 PM, Jim Gay j...@saturnflyer.com wrote: I'm glad you brought this up for discussion. ... Check out the prototype http://github.com/radiant/radiant-prototype Very nice! Can't wait to see this in a release soon. I also want to say thank you to the developers/contributors to the Radiant project for all their excellent work. Radiant has simplified the management of my (modest) website and it has been a pleasure to use. I'm not a programmer but would like to contribute in some way. What kind of help do you need? Find bugs, request features argue about why things should be added, changed or removed. Developers are always good, but the application can really grow when there is a determined direction. Good arguments based on real-world usage lead to good features. If you have an opinion, please express it here and on the github issues, just do so with thought and well-reasoned arguments. We definitely need more of that. -- marshal -- Jim Gay Saturn Flyer LLC http://www.saturnflyer.com 571-403-0338
Re: [Radiant] What is Radiant 1.0 and which Asset extension to use, was: page_attachments interface enhancements
On Tue, Jun 29, 2010 at 8:50 PM, Jeff Casimir j...@casimircreative.com wrote: I'd like to see radiant follow some of the footsteps from merb and have two gems: radiant-core and radiant-more. The 'radiant' gem would become alias to radiant-more which would be core plus a few of the most common extensions (SnS, some kind of attachments, chronicle?, etc). Now that extensions can be gemified, I think this shouldn't be that hard. And if someone really wants a stripped down version they can just install radiant-core, barebones but fully functional. Yeah, definitely. This has been talked about and requested by many. And recently there's been a lot of activity in creating extensions that manage Layouts from the file system. So I've been thinking about what I see as the true core of Radiant and that is: Pages. Snippet and layout mechanisms can be swapped out according to whatever you like. And you might even have the need for a different type of User system. So to me, radiant-core would be the ability to manage pages, and the extendable UI. Loading of extensions I see as something that ought to be generic and is going to move into Rails Engines. Stripping it down to those features means it would be easier to integrate them into existing rails projects rather than having to turn a rails project into an extension. I'm sure there are things I haven't considered, but that's why I've been working out the ideas on separating the features in http://github.com/radiant/radiant/issues#issue/23 : so I have real experience on which I can base the decision-making. To me, radiant-more would be the part that adds snippets, layouts, users, image/file management, stylesheet/javascript management, and perhaps other things. Other people might not see it that way, but by far one of the most popular questions I get about Radiant has to do with adding it to an rails app, rather than shoe-horning a rails app into it. The biggest sticking point is the User system. But you're right, with extensions as gems, this is much easier and no matter what decision is made about what goes into radiant-more, it will be very easy to make radiant-less, radiant-awesome, radiant-whatever and write your own custom gem. - Jeff On Tue, Jun 29, 2010 at 8:24 PM, Jim Gay j...@saturnflyer.com wrote: On Tue, Jun 29, 2010 at 2:31 PM, Marshal Linfoot mlinf...@gmail.com wrote: On Tue, Jun 29, 2010 at 1:47 PM, Jim Gay j...@saturnflyer.com wrote: I'm glad you brought this up for discussion. ... Check out the prototype http://github.com/radiant/radiant-prototype Very nice! Can't wait to see this in a release soon. I also want to say thank you to the developers/contributors to the Radiant project for all their excellent work. Radiant has simplified the management of my (modest) website and it has been a pleasure to use. I'm not a programmer but would like to contribute in some way. What kind of help do you need? Find bugs, request features argue about why things should be added, changed or removed. Developers are always good, but the application can really grow when there is a determined direction. Good arguments based on real-world usage lead to good features. If you have an opinion, please express it here and on the github issues, just do so with thought and well-reasoned arguments. We definitely need more of that. -- marshal -- Jim Gay Saturn Flyer LLC http://www.saturnflyer.com 571-403-0338 -- Jim Gay Saturn Flyer LLC http://www.saturnflyer.com 571-403-0338
Re: [Radiant] What is Radiant 1.0 and which Asset extension to use, was: page_attachments interface enhancements
On Tue, Jun 29, 2010 at 7:51 PM, Jim Gay j...@saturnflyer.com wrote: On Tue, Jun 29, 2010 at 2:24 PM, Haselwanter Edmund edm...@haselwanter.com 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 edm...@haselwanter.com 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). having your css and js in the admin interface is a necessity? i tried to love sns but never could find any benefit to not having the files on disk. perhaps the extension has matured since i last looked (an admittedly long time ago). if anybody has a compelling reason why it's better to have that stuff in radiant than on disk i'd be happy to give it another try. the only reason for having your css/js in radiant i could ever dream up was being able to stick radius tags in your css or js but that didn't work with sns...until today. in the past when i ran into a place where i needed that functionality i would just stick that little bit of css/js inline in a layout or snippet; i think i needed to do that once or twice in three years and more sites than i can remember. 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. it's true. i've tried paperclipped on three occasions and all three times it ended up being pulled due to the commoners not really getting the interface. with p_a they get it almost immediately; it's like attachments in email and everybody seems to understand that. i have an extension tied up in a client site that uses carrierwave http://github.com/jnicklas/carrierwave and provides a similar experience to page_attachments that i could try to get permission to extract and open source if there is any interest in yet another file manager (i can't imagine there would be but who knows) and honestly it doesn't do anything more interesting than p_a but at least it's not dependent on attachment_fu :) 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. ditto what Jim said. it requires more work on the developer's side but once you work with enough clients you get a feel for how non-technical users expect things to work (e.g. no magic page parts, no `r:blahblah` etc) and radiant's minimal core lets you bend it to meet those expectations without
Re: [Radiant] What is Radiant 1.0 and which Asset extension to use, was: page_attachments interface enhancements
On Tue, Jun 29, 2010 at 7:50 PM, Jeff Casimir j...@casimircreative.com wrote: I'd like to see radiant follow some of the footsteps from merb and have two gems: radiant-core and radiant-more. The 'radiant' gem would that sounds like a fine idea; and has been discussed in the past but it wasn't particularly feasible until recently And if someone really wants a stripped down version they can just install radiant-core, barebones but fully functional. radiant-core would be for the hardcore :) seriously though i think you'd have radiant-blog, radiant-portfolio, radiant-catalog etc. springing up then which would be a killer feature in my opinion.
