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 much hoop jumping.
