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. ;)


-Chris
_______________________________________________
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

Reply via email to