Content data specified by URLs

[Henry Stapp]

Problem: If a developer wants to use the same content on multiple
views, they currently have to copy and paste their content as CDATA
sections into multiple content elements, this is inconvenient and
error prone. Also, in general editing !CDATA sections within the XML
document is not as easy as editing a separate html document and
linking it in via a URI.
Proposed Solution: As an interim solution, we propose allowing
developers to specify the content for a content section by using a
URI. In combination with the "type" attribute, this would allow a
container to either point to content (as an IFRAME pointing to an
external source), or retrieve the content and serve it as normal app
content.
Here are proposed combinations of attributes for the Content element:
- type="url" href="<uri >": Content is rendered as an IFRAME with
src=<uri> (currently part of spec)

- type="html" href="<uri>": Container retrieves content from <uri>
and renders it normally (optionally caching the content based on the
container's caching policy). (addition to spec).

- type="html" href missing: Container looks in CDATA section within
Content element, and renders this content normally (optionally caching
the content based on the container's caching policy). (currently part
of spec)


Brian Frisch & Henry Stapp
MySpace

[Paul Lindner]

Can't you just use the comma separated list of views for this purpose?

<Content view="foo,bar">
...
</Content>

type="url" gadgets are a whole other thing.

> You received this message because you are subscribed to the Google Groups "OpenSocial and Gadgets Specification Discussion" group.
> To post to this group, send email to opensocial-an...@googlegroups.com
> To unsubscribe from this group, send email to opensocial-and-gadg...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en
> -~----------~----~----~----~------~----~------~--~---
>

--
Paul Lindner ||||| | | | | | | | | |
lin...@inuus.com

[Henry Stapp]

Hi Paul,

The feeling we had was that using a structure of XML elements was preferable to using a comma separated list in an attribute, since it allows the logical structure of the XML to convey the intended meaning.

As far as type="url" gadgets, I'm in agreement that specifying type="url" designates a whole different thing, and I believe we are not proposing a change to that. What we are suggesting is that the new usage of (type="html" plus href) be allowed, so that developers can keep the actual content data separate from the rest of the gadget spec (if they wish).

What do you think?

Thanks,

Henry

[Nat Brown (ilike.com)]

in the context of the myspace application editor i certainly agree
that copy/paste is a p.i.t.a. this drives me nuts and is error-prone.

but i'm having a hard time imagining a problem with this repetition in
most other cases of gadget spec construction since anybody repeating
complex content in multiple sections who is _not_ using template
expansion / server-includes in their server logic for spec delivery
should probably do so.

nevertheless, +1 from me on
type="html" href="<uri>"

to deal with repetition in Content sections though i might prefer
type="html" src="<uri>"

thx, n@

On Apr 15, 10:01 pm, "Henry Stapp" <hst...@gmail.com> wrote:
> Hi Paul,
>
> The feeling we had was that using a structure of XML elements was preferable
> to using a comma separated list in an attribute, since it allows the logical
> structure of the XML to convey the intended meaning.
>
> As far as type="url" gadgets, I'm in agreement that specifying type="url"
> designates a whole different thing, and I believe we are not proposing a
> change to that. What we are suggesting is that the new usage of (type="html"
> plus href) be allowed, so that developers can keep the actual content data
> separate from the rest of the gadget spec (if they wish).
>
> What do you think?
>
> Thanks,
>
> Henry
>

> > lind...@inuus.com

[Henry Stapp]

I like src better too. Anyone else have input on this?

[Kevin Brown]

On Wed, Apr 16, 2008 at 12:44 PM, Henry Stapp <hst...@gmail.com> wrote:

I like src better too. Anyone else have input on this?

I prefer src as well, but href is already there, so we may as well stick with it.

--
~Kevin

[Cassie]

To update on current status: we have 3 +1s, Paul thinks this is unnecessary, and we need to decide on "src" vs "href".

Can someone convince Paul (or vice versa) and can we resolve the name issue?
Thanks.

- Cassie

[Cassie]

Paul - do you think you can throw in a quick opinion here? Would it be okay to go forward with this change?

As for "src" vs "href". Unless someone feels very strongly, "href" is already there in the spec, so it probably does make more sense to use what we already have.
More thoughts please?

Thanks.

- Cassie

[Cassie]

This issue is closed for 0.8 but we should continue the conversation so that we can get this into 0.9
Thanks.

- Cassie

[Eric Staats]

Understanding that this is closed for 0.8, I'm troubled by the notion
of having a hodgepodge of content sections defined inline within a
gadget and externally located at a href.

For example, when you consider concatenation, imagine an inline
content section being concatenated with a remote content section; how
can a developer manage synchronization of the two views?

I also think it becomes a pain to source control your gadget when the
content gets scattered.

Thoughts?

~eric

On May 1, 1:29 am, Cassie <d...@google.com> wrote:
> This issue is closed for 0.8 but we should continue the conversation so that
> we can get this into 0.9
> Thanks.
>
> - Cassie
>

> On Mon, Apr 28, 2008 at 2:50 PM, Cassie <d...@google.com> wrote:
> > Paul - do you think you can throw in a quick opinion here? Would it be okay
> > to go forward with this change?
>
> > As for "src" vs "href". Unless someone feels very strongly, "href" is
> > already there in the spec, so it probably does make more sense to use what
> > we already have.
> > More thoughts please?
>
> > Thanks.
>
> > - Cassie
>

> > On Mon, Apr 21, 2008 at 11:34 AM, Cassie <d...@google.com> wrote:
>
> >> To update on current status: we have 3 +1s, Paul thinks this is
> >> unnecessary, and we need to decide on "src" vs "href".
>
> >> Can someone convince Paul (or vice versa) and can we resolve the name
> >> issue?
> >> Thanks.
>
> >> - Cassie
>

[ZeroSleep]

+1 from me...

I'd also find a unique ID useful when I had multiple screens within my
canvas
that could each be designed in separate locations:

<Content type="html" view="canvas" id="canvaspage1" display="none"
url="http://mysite.com/canvaspage1.html" />
<Content type="html" view="canvas" id="canvaspage2" display="none"
url="http://mysite.com/canvaspage2.html" />
<Content type="html" view="canvas" id="canvaspage3" display="none"
url="http://mysite.com/canvaspage3.html" />

My code could hide/show these layers when needed or use them as
templates. My designers can work on these resources independently and
my app spec would no longer be a jumbled mess of settings and HTML.
Sorry to chime in so late, I was sent here from my original post:

http://groups.google.com/group/opensocial-api/browse_thread/thread/b42244c55b5f62c0/4d650d82e543f17e#4d650d82e543f17e

[Kevin Brown]

The notion of opaque identifiers for views has been brought up before, but we concluded that there isn't really any functionality there that you couldn't get by just adding a variable to the top of the view's markup. Did you have another use case for these identifiers?

[ZeroSleep]

Yes, for example -- my app has several virtual pages (or screens if
you will) within the canvas view. Each of these pages is represented
by a different .html file. The separation of files is so that I can
have more than one designer work on these assets separately. Combined,
the HTML for all "pages" is just too unwieldy to put into the app xml.
The point of the identifier and default display state would be so that
my code could hide/show the "pages" at will. The container would
prefetch and render the pages. It would combine them into one unit by
view name. I could even see an extension to the opensocial namespace
for this:

opensocial.pages.showPage('canvaspage1', opt_parms); // this method
would be smart and automatically hide the currently visible page

Maybe it's overkill -- but I'd use it =)

-brian

On Jun 2, 4:28 pm, "Kevin Brown" <e...@google.com> wrote:
> The notion of opaque identifiers for views has been brought up before, but
> we concluded that there isn't really any functionality there that you
> couldn't get by just adding a variable to the top of the view's markup. Did
> you have another use case for these identifiers?
>

> On Mon, Jun 2, 2008 at 2:22 PM, ZeroSleep <bclari...@gmail.com> wrote:
>
> > +1 from me...
>
> > I'd also find a unique ID useful when I had multiple screens within my
> > canvas
> > that could each be designed in separate locations:
>
> > <Content type="html" view="canvas" id="canvaspage1" display="none"
> > url="http://mysite.com/canvaspage1.html" />
> > <Content type="html" view="canvas" id="canvaspage2" display="none"
> > url="http://mysite.com/canvaspage2.html" />
> > <Content type="html" view="canvas" id="canvaspage3" display="none"
> > url="http://mysite.com/canvaspage3.html" />
>
> > My code could hide/show these layers when needed or use them as
> > templates. My designers can work on these resources independently and
> > my app spec would no longer be a jumbled mess of settings and HTML.
> > Sorry to chime in so late, I was sent here from my original post:
>

> >http://groups.google.com/group/opensocial-api/browse_thread/thread/b4...

[Kevin Brown]

On Tue, Jun 3, 2008 at 8:13 AM, ZeroSleep <bcla...@gmail.com> wrote:

Yes, for example -- my app has several virtual pages (or screens if
you will) within the canvas view. Each of these pages is represented
by a different .html file. The separation of files is so that I can
have more than one designer work on these assets separately. Combined,
the HTML for all "pages" is just too unwieldy to put into the app xml.
The point of the identifier and default display state would be so that
my code could hide/show the "pages" at will. The container would
prefetch and render the pages. It would combine them into one unit by
view name. I could even see an extension to the opensocial namespace
for this:

You could achieve this by having one primary page for the canvas that did the bootstrapping work (setting up the page navigation), and then having tabs or something dynamically switch the 'pages'. This would mean a big up front hit (all the pages would be downloaded at once).

What you probably really want is to use type=url, but unfortunately there are several issues around type=url that still have to be resolved to make this viable for you.

[ZeroSleep]

RE: bootstrapping

Yes, this is sortof what we do now -- using makeRequest to retrieve
the "templates" when needed. Obviously it's not ideal.

I like the idea of having all my content (html, templates, etc)
managed and served by the container -- but I'm just looking at ways to
get better performance while separating the design assets from the app
definition itself.

Thanks for the feedback.

-bcc

On Jun 3, 11:23 am, "Kevin Brown" <e...@google.com> wrote:

> ...
>
> read more »