Re: [Radiant] SnS Requests Anyone?
Sent from my iPhone On 13-Nov-08, at 9:13 PM, Chris Parrish [EMAIL PROTECTED] wrote: Adam van den Hoven wrote: Things I would like: something like a separate field for copyright notices so that you can minimize the JS/CSS without loosing (someone else's) copyright notice. You can accomplish this today by bundling multiple assets. For instance: --- JS file #1: prototype.js (not minified) --- /* Prototype JavaScript framework, version 1.6.0 * (c) 2005-2007 Sam Stephenson * * Prototype is freely distributable under the terms of an MIT-style license. * For details, see the Prototype web site: http:// www.prototypejs.org/ * *-- --- - */ r:javascript name=prototype.js.content / --- JS file #2: prototype.js.content (this has 'minify?' checked) --- ... the rest of the prototype lib goes in here ... That would serve up the prototype library just as you requested as 'prototype.js' Duh! That never occurred to me. support for external libraries I really just want 1 tag to use for all these assets they can be always as link If you really want to be cool, know ahead of time all the important libraries and their versions (kinda like how the google Ajax Libraries API works -- http://code.google.com/apis/ajaxlibs/) so I can do r:javascript library=jquery version=2.6 minimized='true' / But also just r:javascript url=http://scriptsite.com/ somelibrary / Sounds neat -- though I'm *positive* you don't want me anywhere near any project that requires constant maintenance to keep up-to-date with the latest libraries. Couple of questions, though: * If you know the url, what's the benefit of using the r:javascript / tag? I mean sure, it renders the link for you but that's not so bad to type manually. * How would it be helpful for SnS to have it's own list of libraries when the Google api you offered already does this? I'm really not trying to beat the you can already do this drum, but why not just type: script src=http://www.google.com/jsapi;/script script type=text/javascript google.load(prototype, 1.6); google.load(scriptaculous, 1.8.1); /script Perhaps I'm over doing it. I generally like having on way to do things, so using r:javascript and script together violates my sense of aesthetics. But maintaining a list of libraries is probably bad. How about importing from remote URL so we don't have to download then up load? Or, if you want to keep your list of google.load's in their own javascript file (named, say, google.loads), you could just: script src=http://www.google.com/jsapi;/script r:javascript name=google.loads as=inline / I want to make sure I'm understanding your ideas. (Thanks for the tip on google, BTW. I've never used that and think that it'd be a nice addition -- looks like they even minify stuff for us). I tend to toss ideas out to see what's good or not. This was probably not. What about interacting paperclipped? Not the bucket, per se, but the tags for sure are useful. ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] SnS Requests Anyone?
On Wed, Nov 12, 2008 at 11:32 PM, Chris Parrish [EMAIL PROTECTED] wrote: I'm getting ready to roll out a new SnS version this weekend with some bug fixes and a column name change (requested and implemented by Andrew Neil to help it work with his file_system extension). I am having problems using files uploaded/created with the import_export extension. I create my apps on my laptop then use import_export to pull the db content into the file system and add that to my subversion repo. The problem is that when I cap deploy the app to the production server and use import_export to rake the db content into the production server the class info for the css and js files is set as null which means that they don't show up in the admin portion of the app. The effectively_updated_at fields are also null in the text_asset_dependencies table. I don't know if that's a SnS issue or an import_export issue, but I thought I would mention it as long as you are asking for requests. Thanks, Nate ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] SnS Requests Anyone?
Adam van den Hoven wrote: support for external libraries I really just want 1 tag to use for all these assets they can be always as link If you really want to be cool, know ahead of time all the important libraries and their versions (kinda like how the google Ajax Libraries API works -- http://code.google.com/apis/ajaxlibs/) so I can do r:javascript library=jquery version=2.6 minimized='true' / But also just r:javascript url=http://scriptsite.com/somelibrary; / Sounds neat -- though I'm *positive* you don't want me anywhere near any project that requires constant maintenance to keep up-to-date with the latest libraries. Couple of questions, though: * If you know the url, what's the benefit of using the r:javascript / tag? I mean sure, it renders the link for you but that's not so bad to type manually. * How would it be helpful for SnS to have it's own list of libraries when the Google api you offered already does this? I'm really not trying to beat the you can already do this drum, but why not just type: script src=http://www.google.com/jsapi;/script script type=text/javascript google.load(prototype, 1.6); google.load(scriptaculous, 1.8.1); /script Perhaps I'm over doing it. I generally like having on way to do things, so using r:javascript and script together violates my sense of aesthetics. Ah. Makes sense. Actually I lean towards John and Sean's suggestions that tags not render markup (that way you can use them safely with filters or in pages that aren't html). That's why my tags just render the content by default and offer an as=url to render that property. Whereas the as=inline and as=link are viewed more as bonus or convenience tools. But maintaining a list of libraries is probably bad. How about importing from remote URL so we don't have to download then up load? Hmm. If you already have a URL why not point your browser there and copy the contents from your browser window (not download into a file). Then paste the body of a new javascript in the Radiant UI? Or do you mean SnS keeping a catalog of URLs so you wouldn't have to know that off-hand? But that's beginning to sound like maintaining a list again. Or, if you want to keep your list of google.load's in their own javascript file (named, say, google.loads), you could just: script src=http://www.google.com/jsapi;/script r:javascript name=google.loads as=inline / I want to make sure I'm understanding your ideas. (Thanks for the tip on google, BTW. I've never used that and think that it'd be a nice addition -- looks like they even minify stuff for us). I tend to toss ideas out to see what's good or not. This was probably not. No worries. I'm the same actually. Sometimes things get clearer in the communicating. It's challenging on my end too because I can come across as beating down all your ideas which can be discouraging. In my book if I throw out 200 dumb ideas and come up with one really usable one, that's a win. So keep 'em coming. What about interacting paperclipped? Not the bucket, per se, but the tags for sure are useful. Big on my list. Same with Page Attachments. -Chris ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] SnS Requests Anyone?
On 14-Nov-08, at 3:01 PM, Chris Parrish wrote: Adam van den Hoven wrote: support for external libraries I really just want 1 tag to use for all these assets they can be always as link If you really want to be cool, know ahead of time all the important libraries and their versions (kinda like how the google Ajax Libraries API works -- http://code.google.com/apis/ ajaxlibs/) so I can do r:javascript library=jquery version=2.6 minimized='true' / But also just r:javascript url=http://scriptsite.com/ somelibrary / Sounds neat -- though I'm *positive* you don't want me anywhere near any project that requires constant maintenance to keep up-to- date with the latest libraries. Couple of questions, though: * If you know the url, what's the benefit of using the r:javascript / tag? I mean sure, it renders the link for you but that's not so bad to type manually. * How would it be helpful for SnS to have it's own list of libraries when the Google api you offered already does this? I'm really not trying to beat the you can already do this drum, but why not just type: script src=http://www.google.com/jsapi;/script script type=text/javascript google.load(prototype, 1.6); google.load(scriptaculous, 1.8.1); /script Perhaps I'm over doing it. I generally like having on way to do things, so using r:javascript and script together violates my sense of aesthetics. Ah. Makes sense. Actually I lean towards John and Sean's suggestions that tags not render markup (that way you can use them safely with filters or in pages that aren't html). That's why my tags just render the content by default and offer an as=url to render that property. Whereas the as=inline and as=link are viewed more as bonus or convenience tools. Possibly but I find script src=r:javascript name=foo as=url //script not just unaesthetic, its offensive. If you're using a tag paradigm to encapsulate functional bits, then mixing those tags into attribute values are only confusing and you will not be able to leverage an existing tool (like an extensible XML base WYSIWIG component... not that there are many but I can dream). IMO, if you're following this paradigm you should be thinking in terms of extending HTML not doing something independent of HTML. But maintaining a list of libraries is probably bad. How about importing from remote URL so we don't have to download then up load? Hmm. If you already have a URL why not point your browser there and copy the contents from your browser window (not download into a file). Then paste the body of a new javascript in the Radiant UI? Or do you mean SnS keeping a catalog of URLs so you wouldn't have to know that off-hand? But that's beginning to sound like maintaining a list again. Sorry. I jumped to a new idea. I should have signaled that better ;) I mean that I want to use jQuery and the Metadata plugin. JQuery comes from a public CDN so I can use it externally (unless I'm behind HTTPS) but even if there is a public copy of the meta plugin, I probably shouldn't be stealing someone else's bandwidth. So I need to import that into my machine. Right now, I have to download then upload it. But if I can just point to the tarball or bare code, on the originating server ( and easily update to the latest version) I can save a lot of time. But there is no maintaining lists. I give you the URL of some file or GIT repository which you then download, decompose and copy the contents into the appropriate asset Or, if you want to keep your list of google.load's in their own javascript file (named, say, google.loads), you could just: script src=http://www.google.com/jsapi;/script r:javascript name=google.loads as=inline / I want to make sure I'm understanding your ideas. (Thanks for the tip on google, BTW. I've never used that and think that it'd be a nice addition -- looks like they even minify stuff for us). I tend to toss ideas out to see what's good or not. This was probably not. No worries. I'm the same actually. Sometimes things get clearer in the communicating. It's challenging on my end too because I can come across as beating down all your ideas which can be discouraging. In my book if I throw out 200 dumb ideas and come up with one really usable one, that's a win. So keep 'em coming. What about interacting paperclipped? Not the bucket, per se, but the tags for sure are useful. Big on my list. Same with Page Attachments. So this is brings up something similar to what I just said previously. There are some javascript plugins that you are going to download that have some skinning. So you have javascript, css and images all in one tarball (or something similar)... when you explode the tarball, if you could present a tree view of the data and allow the user to select which bits to import, rewrite URLs in the CSS... Ok. maybe thats WAY too complicated.
Re: [Radiant] SnS Requests Anyone?
Adam van den Hoven wrote:
Possibly but I find
script src=r:javascript name=foo as=url //script
not just unaesthetic, its offensive. If you're using a tag paradigm to
encapsulate functional bits, then mixing those tags into attribute
values are only confusing and you will not be able to leverage an
existing tool (like an extensible XML base WYSIWIG component... not
that there are many but I can dream). IMO, if you're following this
paradigm you should be thinking in terms of extending HTML not doing
something independent of HTML.
I agree. I'm not offended per se, but I do find it really hard to
follow visually.
In fact I find myself wondering whether radius could easily be tweaked
to parse something different (I mean, we can easily change it to accept
oo:title instead of using 'r' could we also do {{title}} or !
content (part = 'sidebar') ! or [insert your idea here].
Of course, once I open that door, I start wondering about languages like
liquid -- some sort of more well-rounded tool. I created the
conditional_tags extension to address one of these needs but you'll
never make radius pull off stuff like if/else if/else behavior.
But I'm way off topic now.
Sorry. I jumped to a new idea. I should have signaled that better ;)
I mean that I want to use jQuery and the Metadata plugin. JQuery comes
from a public CDN so I can use it externally (unless I'm behind HTTPS)
but even if there is a public copy of the meta plugin, I probably
shouldn't be stealing someone else's bandwidth. So I need to import
that into my machine. Right now, I have to download then upload it.
But if I can just point to the tarball or bare code, on the
originating server ( and easily update to the latest version) I can
save a lot of time.
But there is no maintaining lists. I give you the URL of some file or
GIT repository which you then download, decompose and copy the
contents into the appropriate asset
I'd love to see that -- but I'm not sure I'd build it. From the average
user's perspective, not much time is spent with radiant mucking around
with css and js. For a brief period of time during each project, we're
really focused there, then it's off to the important stuff. I guess
that makes my threshold for pain is higher for those elements.
So on this one I'd probably pull out the we're accepting patches card ;-).
Actually it would probably be better as an extension -- SnS is fully
extendable, you know. I worked shards into it so you can override
elements, insert partials, the whole bit.
-Chris
___
Radiant mailing list
Post: Radiant@radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] SnS Requests Anyone?
I'm getting ready to roll out a new SnS version this weekend with some bug fixes and a column name change (requested and implemented by Andrew Neil to help it work with his file_system extension). As Chris says, I have been working on integrating file_system functionality into SnS. The column name change was simply to avoid a naming conflict between the two extensions, but it shouldn't cause any perceptible change in the behaviour of SnS. My file_system/SnS integration is not ready for release yet, but I shall announce it here when it is. Since I'm doing that, are there any other issues/feature requests out there? Now would be a good time to entertain those. I was going to suggest asset packaging... but then I had another look at the README and saw that it was already there! Cheers, Drew ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] SnS Requests Anyone?
Things I would like: something like a separate field for copyright notices so that you can minimize the JS/CSS without loosing (someone else's) copyright notice. support for external libraries I really just want 1 tag to use for all these assets they can be always as link If you really want to be cool, know ahead of time all the important libraries and their versions (kinda like how the google Ajax Libraries API works -- http://code.google.com/apis/ajaxlibs/) so I can do r:javascript library=jquery version=2.6 minimized='true' / But also just r:javascript url=http://scriptsite.com/somelibrary; / Adam On 13-Nov-08, at 3:31 PM, Andrew Neil wrote: I'm getting ready to roll out a new SnS version this weekend with some bug fixes and a column name change (requested and implemented by Andrew Neil to help it work with his file_system extension). As Chris says, I have been working on integrating file_system functionality into SnS. The column name change was simply to avoid a naming conflict between the two extensions, but it shouldn't cause any perceptible change in the behaviour of SnS. My file_system/SnS integration is not ready for release yet, but I shall announce it here when it is. Since I'm doing that, are there any other issues/feature requests out there? Now would be a good time to entertain those. I was going to suggest asset packaging... but then I had another look at the README and saw that it was already there! Cheers, Drew ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] SnS Requests Anyone?
Adam van den Hoven wrote: Things I would like: something like a separate field for copyright notices so that you can minimize the JS/CSS without loosing (someone else's) copyright notice. You can accomplish this today by bundling multiple assets. For instance: --- JS file #1: prototype.js (not minified) --- /* Prototype JavaScript framework, version 1.6.0 * (c) 2005-2007 Sam Stephenson * * Prototype is freely distributable under the terms of an MIT-style license. * For details, see the Prototype web site: http://www.prototypejs.org/ * *--*/ r:javascript name=prototype.js.content / --- JS file #2: prototype.js.content (this has 'minify?' checked) --- ... the rest of the prototype lib goes in here ... That would serve up the prototype library just as you requested as 'prototype.js' support for external libraries I really just want 1 tag to use for all these assets they can be always as link If you really want to be cool, know ahead of time all the important libraries and their versions (kinda like how the google Ajax Libraries API works -- http://code.google.com/apis/ajaxlibs/) so I can do r:javascript library=jquery version=2.6 minimized='true' / But also just r:javascript url=http://scriptsite.com/somelibrary; / Sounds neat -- though I'm *positive* you don't want me anywhere near any project that requires constant maintenance to keep up-to-date with the latest libraries. Couple of questions, though: * If you know the url, what's the benefit of using the r:javascript / tag? I mean sure, it renders the link for you but that's not so bad to type manually. * How would it be helpful for SnS to have it's own list of libraries when the Google api you offered already does this? I'm really not trying to beat the you can already do this drum, but why not just type: script src=http://www.google.com/jsapi;/script script type=text/javascript google.load(prototype, 1.6); google.load(scriptaculous, 1.8.1); /script Or, if you want to keep your list of google.load's in their own javascript file (named, say, google.loads), you could just: script src=http://www.google.com/jsapi;/script r:javascript name=google.loads as=inline / I want to make sure I'm understanding your ideas. (Thanks for the tip on google, BTW. I've never used that and think that it'd be a nice addition -- looks like they even minify stuff for us). ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
[Radiant] SnS Requests Anyone?
I'm getting ready to roll out a new SnS version this weekend with some bug fixes and a column name change (requested and implemented by Andrew Neil to help it work with his file_system extension). Since I'm doing that, are there any other issues/feature requests out there? Now would be a good time to entertain those. P.S. I just released a new version of the SnS Sass Filter which has much-improved error reporting (as in: it no longer blows up your app). So if you use that extension, I'd update it as sass can be finicky and prone to throwing those errors. Thanks, Chris ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
