[Seaside] IALink for <link> element

[Avi Bryant]

> Kamil Kukura wrote:
> > Here is IALink for <link> element which is in fact same to IAImage but
> > with 'href' atribute. Also IASession>>urlForResourceNamed: is fixed
> > little bit.

Yes, as Julian pointed out there's already a <link> element in SSVS, since
we were playing with CSS support - more on that in a following email.

> > I was thinking that for these elements there could be classes
> > IAExternalSRC (for elements with src="" attribute), IAExternalHREF (for
> > elements with href="" attribute) and then extra IAApplet and IAObject.

Seems reasonable, yes.

>Julian Fitzell wrote:
>> Oh, what is the reason for your naming scheme addition to
>> urlForResourceNamed: ?  I can't quite figure it out.

Looks like full urls get used untouched.  This is solved differently in
SSVS right now - img, link, etc, have a "resource" binding which, if set,
uses urlForResourceNamed, but you can also just set "src" or "href"
directly to a literal if you don't want the document root to get used.
IE,

(template elementNamed: 'myImage')
  set: #resource to: 'someImage.gif'

vs.

(template elementNamed: 'myImage')
  set: #src to: 'http://foo/someImage.gif'

However, having a naming scheme for resources themselves strikes me as a
good idea.  I would like to be able to have resources stored either in the
image, perhaps as a method on session or application (which could also be
useful for dynamically generating images, for example), or maybe in the
local filesystem, or at an external url as now.  So it seems like maybe
resource names should be urls like 'session:foo', 'file:foo.css',
'http://beta4.com/seaside/poweredby.png'.  Which means that seaside needs
some way of generating and handling urls for semi-static content,
which raises some questions about how static these urls should be, since
for a .css file, for example, you want the browser to load it once at the
beginning of the session and cache it from then on.  But a generated image
is a different story.

Thoughts?