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/
version="2.6" minimized='true' />
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
/> 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
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:
Perhaps I'm over doing it. I generally like having on way to do
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
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
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
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
No worries. I'm the same actually. Sometimes things get clearer in
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.
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. ;)
Radiant mailing list
Radiant mailing list