Proposal for 1.0 - Deprecate os:Render tag

goosemanjack

unread,

Oct 7, 2009, 5:16:40 AM10/7/09

to OpenSocial - OpenSocial and Gadgets Specification Discussion

Synopsis:

In practice, we have found the os:Render tag to be redundant to the $
{My} EL construct and a non-obvious mechanism for including local
template data or nested templates. Because all the functionality is
available by using other, simpler mechanisms, we propose it be removed
from the 1.0 version of the spec.

(section proposed for deprecation)
http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/OpenSocial-Templating.html#rfc.section.12

The EL reserved variable ${My} exposes access to local template
instance variables in a much cleaner and more obvious manner.

http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/OpenSocial-Templating.html#rfc.section.7.1.4

Example (from existing section 12)

(DEFINITION)
<script type="text/os-template" tag="myapp:BoxWithTitle"
xmlns:myapp="http://example.com/myapp" xmlns:os="http://
opensocial.org/templates" >
<div class="box-title">${My.title}</div>
<div class="box-content">${My.body}</div>
</script>

(USAGE INLINE)
<script type="text/os-template"
xmlns:myapp="http://example.com/myapp" xmlns:os="http://
opensocial.org/templates" >
<h1>Inline template below</h1>
<myapp:BoxWithTitle>
<myapp:title>This is the title</myapp:title>
<myapp:body>
<div style="font-size:40px">Boo!</div>
<div>from <os:Name person="${Top.Viewer}"/></div>
<myapp:body>
</myapp:BoxWithTitle>
</script>

In the above example, the relevant line changes are in the definition.

From:
<div class="box-title"><os:Render content="title"/></div>
<div class="box-content"><os:Render content="body"/></div>

To:
<div class="box-title">${My.title}</div>
<div class="box-content">${My.body}</div>

The USAGE example XML namespaces the instance variables to a namespace
"myapp". In practice the local variables are registered under the $
{My} variable without XML namespaces, hence <myapp:title>xxx</
myapp:title> is registered as ${My.title} and not ${My.myapp:title}.
In practice, the developer could ignore namespaces entirely in local
template instance value declarations or use attributes for value
declarations:

(USAGE INLINE, sans-namespace)
<myapp:BoxWithTitle>
<title>This is the title</title>
<body>
<div style="font-size:40px">Boo!</div>
<div>from <os:Name person="${Top.Viewer}"/></div>
<body>
</myapp:BoxWithTitle>

In this case the collision between the template-local <body> tag and
the HTML <body> tag is avoided because the template processor resolves
and strips out the template-local tag, replacing it with the rendered
value.

NESTED TEMPLATES:

Nested templates are more elegantly handled simply by using the
declared tag instance instead of os:Render.

EX:

(definitions)

<script type="text/os-template" tag="myapp:SlaveTag" >
Thank you, ${My.masterName}
I will do your bidding, my master.
</script>

<script type="text/os-template" tag="myapp:MasterTag" >
<b>Master:</b> Who do you think you are?
<b>Slave: </b> <myapp:SlaveTag masterName="${My.person.displayName}"
></myapp:SlaveTag>
</script>

(usage)
<script type="text/os-template" >
<h1>Nested tags below</h1>

<myapp:MasterTag>
<person>${Viewer}</person>
</myapp:MasterTag>

</script>

In this case, the ${My} variable has values registered and available
only within the scope of the currently rendering template. Hence, the
value ${My.person} is unavailable while rendering within
<myapp:SlaveTag>, but returns to scope once <myapp:SlaveTag> is fully
rendered and renderer is back in scope of <myapp:MasterTag>. I'll
make a secondary proposal for exposing parent template property values
to ${My} in a different thread.

To date, the only argument I've seen for keeping this tag has to do
with security and escaping of markup. Our position is that this tag
provides no additional value for security because it does not deal
with combinational attacks where two variables are combined to
construct some other tag - example XSS. This tag forces a particular
security design that is sub-optimal and should be handled at a
different level of the app, like by the template rendering engine or
some sandboxing technology such as Caja or Web Sandbox.
--
clc / MySpace

Evan Gilbert

unread,

Oct 7, 2009, 2:27:45 PM10/7/09

to opensocial-an...@googlegroups.com

I think we've found a larger spec area that needs clarification.

The spec currently states that all expressions are evaluated as a string. The only exception is an attribute whose value is just an expression (i.e. <Custom foo="${expr}">). http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/OpenSocial-Templating.html#rfc.section.6.

The intention of this was that this would not generate HTML nodes, only strings as part of text nodes and attribute values. However, this appears not to be clear in the spec.

My preference is to keep ${} for generating text content (with the one exception in the original spec), and use <os:Render> and <os:Html> for generating DOM content.

Also, we need to get a suite of tests with (input -> output) for templates. This will help us catch these differences earlier.

Evan

Lev Epshteyn

unread,

Oct 8, 2009, 10:32:19 AM10/8/09

to opensocial-an...@googlegroups.com

Clearly in these examples, the use of ${My} is more appropriate than <os:Render>. However there are a number of other situations where <os:Render> is absolutely essential. Consider a tag like this:


<script tag="myapp:DisplayCard">
<div class="display-card">
<div class="display-card-top"> </div>
<div class="display-card-middle"><os:Render/></div>
<div class="display-card-bottom"> </div>
</div>
</script>

Here, <os:Render> doesn't refer to a scalar value like in your examples, but to a block of markup inside the custom tag. It enables me to create styling tags that can go around arbitrarily large DOM subtrees.

This is not something that can be done with ${My} alone.

Jorge Reyes

unread,

Oct 8, 2009, 2:41:33 PM10/8/09

to opensocial-an...@googlegroups.com

I think that <os:Render /> with out specifying the content is not allow.

"A template may also define locations to render custom blocks of content. This is done using the <os:Render> tag and the content block is always identified by the @content attribute" we can not identify the content to render with out @content

Looking at your example I assume that this will be call like

<myapp:DisplayCard>

<div> this is the content I want to render<div><a href="${Top.ProfielUrl}">${Top.TumbnailUrl}</a>

</myapp:DisplayCard>

This will cause a problem with variable evaluation. I can not parse the content inside the <myapp:DisplayCard> to add the variable to My. If I do that I will end with something like

My.div = "this is the content I want to render<div><a href=\"http://abc.com/profile.html\">http://abc.com/image.gif</a>"

Forcing having to parse first the tag and then trying to get content and variables that will complicate a lot the implementation.

I agree with Chris

I don't think is any difference between

<div class="display-card-middle">${My.MiddleContent}</div>

and

<myapp:DisplayCard>

<myapp:MiddleContent>

<div> this is the content I want to render<div><a href="${Top.ProfielUrl}">${Top.TumbnailUrl}</a>

</myapp:MiddleContent>

</myapp:DisplayCard>

Jorge

goosemanjack

unread,

Oct 30, 2009, 2:08:15 PM10/30/09

to OpenSocial - OpenSocial and Gadgets Specification Discussion

> Here, <os:Render> doesn't refer to a scalar value like in your examples, but
> to a block of markup inside the custom tag. It enables me to create styling

In your example, using the <os:Html> tag would achieve the same
results (because it would need a variable where content was
contained), as I understand it. I'm still not seeing a use-case where
<os:Render> tag is providing any unique functionality. So far it
still seems to be a niche tag that provides duplicative functionality
without providing clarity.
--
clc

On Oct 8, 7:32 am, Lev Epshteyn <le...@google.com> wrote:
> Clearly in these examples, the use of ${My} is more appropriate than
> <os:Render>. However there are a number of other situations where
> <os:Render> is absolutely essential. Consider a tag like this:
>
> 
> <script tag="myapp:DisplayCard">
> <div class="display-card">
> <div class="display-card-top"> </div>

> <div class="display-card-middle">*<os:Render/>*</div>

> <div class="display-card-bottom"> </div>
> </div>
> </script>
>
> Here, <os:Render> doesn't refer to a scalar value like in your examples, but
> to a block of markup inside the custom tag. It enables me to create styling
> tags that can go around arbitrarily large DOM subtrees.
>
> This is not something that can be done with ${My} alone.
>
> On Wed, Oct 7, 2009 at 5:16 AM, goosemanjack <cc...@myspace.com> wrote:
>
> > Synopsis:
>
> > In practice, we have found the os:Render tag to be redundant to the $
> > {My} EL construct and a non-obvious mechanism for including local
> > template data or nested templates. Because all the functionality is
> > available by using other, simpler mechanisms, we propose it be removed
> > from the 1.0 version of the spec.
>
> > (section proposed for deprecation)
>

> >http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/Ope...

>
> > The EL reserved variable ${My} exposes access to local template
> > instance variables in a much cleaner and more obvious manner.
>

> >http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/Ope...

Lev Epshteyn

unread,

Nov 2, 2009, 8:41:10 AM11/2/09

to opensocial-an...@googlegroups.com

Sorry to have missed this initially - I have some comments inline:

On Thu, Oct 8, 2009 at 1:41 PM, Jorge Reyes <jer...@gmail.com> wrote:

I think that <os:Render /> with out specifying the content is not allow.

"A template may also define locations to render custom blocks of content. This is done using the <os:Render> tag and the content block is always identified by the @content attribute" we can not identify the content to render with out @content

Looking at the spec now I see that this is indeed the case. However, it is an omission. The intent was to allow <os:Render> without a @content attribute, which would implicitly render all of the content. If we decide to keep <os:Render> in the spec, it should be fixed. I believe Shindig's current implementations support such use.

Looking at your example I assume that this will be call like

<myapp:DisplayCard>
<div> this is the content I want to render<div><a href="${Top.ProfielUrl}">${Top.TumbnailUrl}</a>

</myapp:DisplayCard>

This will cause a problem with variable evaluation. I can not parse the content inside the <myapp:DisplayCard> to add the variable to My. If I do that I will end with something like

My.div = "this is the content I want to render<div><a href=\"http://abc.com/profile.html\">http://abc.com/image.gif</a>"

Forcing having to parse first the tag and then trying to get content and variables that will complicate a lot the implementation.

There is no inconsistency here. ${My} is set after the tag is invoked. Markup between the opening and closing tag is first processed within the existing scope, then the result is passed inside of ${My} to the custom tag template being called.

The implementation algorithm is pretty simple. When you encounter a custom tag node:

Process the content between the opening and closing tags
Use the result of this to build the ${My} structure
Process the custom tag template with this structure as ${My}

I don't see the issue here.

I agree with Chris

I don't think is any difference between

<script tag="myapp:DisplayCard">
<div class="display-card">
<div class="display-card-top"> </div>

    <div class="display-card-middle">${My.MiddleContent}</div>

<div class="display-card-bottom"> </div>
</div>
</script>

and

<script tag="myapp:DisplayCard">
<div class="display-card">
<div class="display-card-top"> </div>

    <div class="display-card-middle"><os:Render content="MiddleContent"></div>

<div class="display-card-bottom"> </div>
</div>
</script>

<myapp:DisplayCard>
   <myapp:MiddleContent>

   <div> this is the content I want to render<div><a href="${Top.ProfielUrl}">${Top.TumbnailUrl}</a>

   </myapp:MiddleContent>
</myapp:DisplayCard>

As Chris points out in his reply, this will at least require wrapping the ${My.MiddleContent} call with <os:Html>. However, I do not believe we currently specify that ${var} evaluation resulting in DOM nodes (or a list of them) will render out the markup for those nodes.

Currently, we use ${var} syntax to access scalar or JSON values. Overloading this to also support expanding DOM doesn't seem prudent.

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

goosemanjack

unread,

Nov 2, 2009, 1:34:11 PM11/2/09

to OpenSocial - OpenSocial and Gadgets Specification Discussion

With the behavior you are arguing for, Lev, the presence of
<os:Render> creates a tremendous amount of ambiguity for developers.
In some cases, elements will evaluate to variables attached to ${My},
but in some cases they will be treated as content for processing? You
seem to be trying to have it both ways. As you argue in the Parameter
clarification thread here (http://groups.google.com/group/opensocial-
and-gadgets-spec/browse_thread/thread/69e8ff53f6512b26?hl=en) Shindig
desires multiple elements to be treated as an XML-style declaration of
variable values attached to ${My}, but in this thread you say they
should be treated as markup content. That doesn't seem to add up to
me.

Take this example (assuming <foo:Bar> tag has been declared):

<foo:Bar simpleVar="hello" >
<div>Dog</div>
<div>Cat</div>
<other>Bird</div>
</foo:Bar>

Putting on my developer hat, my expectation is that there will be
three variables created and attached to the ${My} scope, which is then
passed to the template declaration for rendering:

${My.simpleVar} = "hello"
${My.div} = "Cat" (or ["Dog", "Cat"], depending on outcome of other
discussion)
${My.other} = "Bird"

If the <os:Render> tag remains in the spec, it is no longer clear what
the expected behavior will be for the developer. Does the presence of
an <os:Render> tag have a corollary effect of flipping all elements
from variables to content?

As far as EL never being used to access markup, we have a deep
philosophical disagreement with that notion. The <os:HttpRequest>
data tag is analogous to makeRequest and is specifically designed to
handle both text content and JSON content. It will be a very common
use case to request and store markup in the DataContent, later
emitting it into the rendered content. Consider the case of
requesting a third-party news feed that contains embedded links and
images.

Coming back to your previous example of a tag that defines rounded
borders, that is more clearly coded using the <os:Html> tag combined
with ${My.content}

<os:HttpRequest key="news" href="http://news.example.org/latestCard"
format="text" />
...

from os:HttpRequest generated content
...
<myapp:DisplayCard>
<content>${news}</content>
</myapp:DisplayCard>

...
alternately inline:

<myapp:DisplayCard>
<content>Here is some <b>content</b>
</content>
</myapp:DisplayCard>
...
alternately with os:Var

<myapp:DisplayCard>
<os:Var key="content" >Here is some <b>content</b>
</os:Var>
</myapp:DisplayCard>

Clearly there are multiple ways to accomplish the same behavior
without the use of (and ambiguity that comes along with) <os:Render>.
Having the presence of a tag that creates dramatic side effects in the
behavior of other tags and elements around it is going to be a major
source of confusion for developers. Given that there are so many
other mechanisms for accomplishing this behavior that don't required
ambiguous behavior, I simply don't see any value of including the
os:Render tag and continue to see more and more downsides of it
remaining in the spec as we discuss.
--
clc

> - Process the content between the opening and closing tags
> - Use the result of this to build the ${My} structure
> - Process the custom tag template with this structure as ${My}

>
> I don't see the issue here.
>
>
>
> > I agree with Chris
>
> > I don't think is any difference between
>
> > <script tag="myapp:DisplayCard">
> > <div class="display-card">
> > <div class="display-card-top"> </div>

> > <div class="display-card-middle">$*{My.MiddleContent}*</div>

> >> <div class="display-card-middle">*<os:Render/>*</div>

> >> <div class="display-card-bottom"> </div>
> >> </div>
> >> </script>
>
> >> Here, <os:Render> doesn't refer to a scalar value like in your examples,
> >> but to a block of markup inside the custom tag. It enables me to create
> >> styling tags that can go around arbitrarily large DOM subtrees.
>
> >> This is not something that can be done with ${My} alone.
>
> >> On Wed, Oct 7, 2009 at 5:16 AM, goosemanjack <cc...@myspace.com> wrote:
>
> >>> Synopsis:
>
> >>> In practice, we have found the os:Render tag to be redundant to the $
> >>> {My} EL construct and a non-obvious mechanism for including local
> >>> template data or nested templates. Because all the functionality is
> >>> available by using other, simpler mechanisms, we propose it be removed
> >>> from the 1.0 version of the spec.
>
> >>> (section proposed for deprecation)
>

> >>>http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/Ope...

>
> >>> The EL reserved variable ${My} exposes access to local template
> >>> instance variables in a much cleaner and more obvious manner.
>

> >>>http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/Ope...

> > opensocial-and-gadg...@googlegroups.com<opensocial-and-gadgets-spec%2Bunsu...@googlegroups.com>

Jorge Reyes

unread,

Nov 2, 2009, 1:47:55 PM11/2/09

to opensocial-an...@googlegroups.com

I think Render alone with out @content is a bad idea because we don't know if what is inside is a variable declaration or content declaration. As I mention before. I think the tags spec can be cleaner, clearer and easier to implement just if we just provide intent.

I think we can replace

<myapp:DisplayCard>

</myapp:DisplayCard>

with

</tag>

This way we can parse the document more efficiently because we don't have to go element by element looking for tags.

Also

<div>${Top.DisplayName}</div>

</content>

</tag>

We can use either <os:Render> or ${My.} to display the content. What we need to be clear is that this contains HTML that you want to render.

<myapp:DisplayCard>

<div>${Top.DisplayName}</div>

</header>

</myapp:DisplayCard>

the problem with this is that we don't know if header is going to be render as html or you are trying to define a variable. I will need to parse the tag first to try to figure out if header is content that I want to render or a variable. In the following example I don't know what is the difference between using <os:Render content="header" /> and ${My.header}

<os:Render content="header" />

${My.header}

</script>

<myapp:DisplayCard>

<div>${Top.DisplayName}</div>

</header>

</myapp:DisplayCard>

Render with out content is not in the 0.9 spec and also can be a source of confusion

<myapp:DisplayCard>

<div>${Top.DisplayName}</div>

</header>

</myapp:DisplayCard>

<os:Render />

</div>

</script>

This will render

<div>Jorge Reyes</div>

</header>

</div>

The other issue that came was arrays

<myapp:DisplayCard>

<div>${Top.DisplayName}</div>

</header>

</myapp:DisplayCard>

I think a better approach will be to define tags instead of trying to figure out what the developer try to do by parsing the tag and the content.

<array>

</array>

</var>

<div>this is the header</div>

</content>

this is the body

</content>

</tag>

Advantages:

1- We don't need to deal with extra namespaces.

2- The parsing is faster and efficient because we can directly identify this tags an process radder than having to go element by element trying to figure out if is a tag.

3- We avoid confusion by clearly state intent. I think there is not confusion at all with this syntax.

Disadvantages

1- The syntax is a little more verbose.

Is the second time I propose this syntax. The first time I was told version 1.0 was just clean up. In my opinion this is one of the items that needs mayor clean up. We had been discussing this for more than a month and we still can agree. My point of view is that if we can not agree is because the syntax is confusing and way open to interpretation. Lets fix that.

Regards

Jorge Reyes

--

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.

Lev Epshteyn

unread,

Nov 2, 2009, 6:46:57 PM11/2/09

to opensocial-an...@googlegroups.com

As Chris has pointed out, I am trying to argue it both ways :) That is because I believe custom tags need to be a flexible enough mechanism to do two pretty different things well:

Format content (such as with the rounded borders or Box with Title examples)
Take structured input in the form of attributes or child nodes

Usually, the two will not clash. That is, even if a "formatting" custom tag takes some parameters as input, it will likely do so in attributes rather than in child nodes: <my:roundedBox color="red"> ... markup ... </my:roundedBox>

(As an aside, I find such invocation syntax to be much more clear than <tag key="roundedBox"> ... </tag>, but since this is a different proposal, let's not dwell on this)

Much of the added verbosity of Jorge's proposal seems aimed at allowing unambiguous mixing of having content and variables represented as child nodes - a scenario I think will be very rare in real-world usage. I do think it penalizes the simple use cases where there is no ambiguity to begin with.

For example,
<my:Box>${content}</my:Box> is much more palatable than
<my:Box><content key="body">${content}</content><my:Box>

This is the reason I think <os:Render> without a @content attribute which implicitly renders all the content is a good idea - it streamlines a large class of use cases.

I find that the separation between ${My} for variable access and <os:Render> for content rendering is a natural one, but I see that you guys find <os:Render> too complex for what it's doing. Before we decide to drop it entirely, perhaps we can look into how it can be made easier to understand and more consistent in the way it behaves?

Evan Gilbert

unread,

Nov 3, 2009, 2:45:39 PM11/3/09

to opensocial-an...@googlegroups.com

On using <os:Html> in place <os:Render> - the goals of these tags are different. It might be possible to combine the tags, it might require an extra attribute and I'm not sure if it actually clarifies things.

<os:Html>

Goal: Render HTML data provided a string from data pipelining (and possibly from other sources). Needed for showing data from RSS feeds, Atom, or any other data source that sends raw HTML content.

- Input is a string (although we can define this as evaluating the expression as a string)

- Doesn't render inline templates, just HTML

- We may want to support non-wellformed input here - there are many feed sources that are HTML, not XML.

<os:Render>

Goal: Render content passed into a template. Need to allow passing HTML/template content into a template.

- Input is a DOM structure
- No need to support non-wellformed input

- Renders inline templates

On Mon, Nov 2, 2009 at 3:46 PM, Lev Epshteyn <le...@google.com> wrote:

As Chris has pointed out, I am trying to argue it both ways :) That is because I believe custom tags need to be a flexible enough mechanism to do two pretty different things well:

Format content (such as with the rounded borders or Box with Title examples)

Take structured input in the form of attributes or child nodes
Usually, the two will not clash. That is, even if a "formatting" custom tag takes some parameters as input, it will likely do so in attributes rather than in child nodes: <my:roundedBox color="red"> ... markup ... </my:roundedBox>

(As an aside, I find such invocation syntax to be much more clear than <tag key="roundedBox"> ... </tag>, but since this is a different proposal, let's not dwell on this)

Much of the added verbosity of Jorge's proposal seems aimed at allowing unambiguous mixing of having content and variables represented as child nodes - a scenario I think will be very rare in real-world usage. I do think it penalizes the simple use cases where there is no ambiguity to begin with.

Lev summarized my viewpoint well. For the common use cases, these syntaxes work very well. <os:Render> as shorthand for <os:Render content="${My}">, and is really nice for decorators, for example a link formatter, or a custom div. For example, creating a custom bold tag is as simple as <Template tag="superbold"><b class="super"><os:Render></b></Tempalte>.

On the implementation side, it's fairly easy to allow for evaluation of both structured and unstructured references on ${My}. From Chris' example:

<foo:Bar>

<div>Dog</div>
<div>Cat</div>

<other>Bird</other>
</foo:Bar>

Option 1: Lazy evaluation. Evaluate ${My.xxx} on demand.

Option 2: Create hidden ${My.___content} variable that is used for <os:Render>

Jorge Reyes

unread,

Nov 3, 2009, 3:30:47 PM11/3/09

to opensocial-an...@googlegroups.com

Looking at the example

<foo:Bar>

<os:Render />

</script>

we will have

other is not a valid html tag

also My will contain

My.div = "Cat" (Because we have to divs we have Dog and then it change to Cat)

My.other = "Bird"

we can not know if the container element in <foo:bar> are variables or content.

That is why <os:Render> with out @content is not practical

Lev Epshteyn

unread,

Nov 3, 2009, 4:03:18 PM11/3/09

to opensocial-an...@googlegroups.com

On Tue, Nov 3, 2009 at 3:30 PM, Jorge Reyes <jer...@gmail.com> wrote:

Looking at the example

<foo:Bar>

<div>Dog</div>
<div>Cat</div>

<other>Bird</other>
</foo:Bar>

<script .... tag="foo:Bar>

<os:Render />
</script>

we will have

<div>Dog</div>

<div>Cat</div>
<other>Bird</other>

other is not a valid html tag

Tags using <os:Render/> without a @content attribute are going to be formatting tags, similar to HTML's <a> or <b> tag. All of these can theoretically have a user insert some unknown child tag: <b>Hello <other>world</other></b>, so the problem you outline is not inherent in using <os:Render/> in this way.

Just as users are free to put in unsupported tags into standard HTML markup, they will be free to do so for custom tags - nobody really expects this to do anything useful. (Or if they do, it will behave the same way as it would with built-in tags)

also My will contain

My.div = "Cat" (Because we have to divs we have Dog and then it change to Cat)

We had a separate discussion about this where it was agreed that My.div = ["Dog", "Cat"] - this is in the spec, and it was agreed that it would stay there given the introduction of <os:Var> support into 1.0. If you would like to reopen that debate, please let's do it in the appropriate thread.

My.other = "Bird"

we can not know if the container element in <foo:bar> are variables or content.

That is why <os:Render> with out @content is not practical

I don't believe we need to know this ahead of time. If the template calls <os:Render>, that is a directive to treat child elements as content. If ${My} is referenced, they are fetched as variables. If you are concerned about the practicality of computing both, it can be done lazily when either construct is encountered by the template processor.

goosemanjack

unread,

Dec 15, 2009, 1:40:38 PM12/15/09

to OpenSocial - OpenSocial and Gadgets Specification Discussion

> I don't believe we need to know this ahead of time.
> If the template calls <os:Render>, that is a directive to treat child elements as content.

Having this behavior requires the template not be passed not only the
resolved parameters, but much additional data:

1. Resolved parameters
2. Duplicate copy of each parameter as a string, ordered
3. Duplicate copy of entire set of parameters as a string, ordered.

Invoking a template should be analogous to making a function call. In
function calls, things are evaluated right to left, with parameters
being resolved prior to invoking the function and passing the resolved
parameters into the function.

The way <os:Render> is specified breaks this model of treating
template calls as function calls. As pointed out previously, removal
of <os:Render> does not remove the ability to display markup. The
developer simply makes use of the <os:Html> tag, using the parameter
name as content.
--
clc

> >>> As Chris has pointed out, I *am* trying to argue it both ways :) That is

> >>> because I believe custom tags need to be a flexible enough mechanism to do
> >>> two pretty different things well:
>

> >>> - Format content (such as with the rounded borders or Box with Title
> >>> examples)
> >>> - Take structured input in the form of attributes or child nodes

> ...
>
> read more »

Evan Gilbert

unread,

Dec 16, 2009, 5:07:27 AM12/16/09

to opensocial-an...@googlegroups.com

There are a number of use cases the current spec supports that we are not willing to lose the ability to support by deprecating <os:Render>. Examples...

Render all child content:

<JsLink action="navigateToNextPage()">Next</JsLink>
<Template tag="JsLink">

<a href="javascript:void()" onclick="${My.action}"><os:Render/></a>
</Template>

Render one level deep:

<Expando>
  <Title>This is the title</Title>

  <Content>This is the content</Content>
</Expando>

<Template tag="Expando">
  <div><a href="#" onclick="toggleMimizeState()"><os:Render content="${My.Title}"/></a></div>

  <div class="minimizable"><os:Render content="${My.Content}"/></div>
</Template>

Repeat one level deep:

<TabView>
  <Tab><Title>Title</Title><Content>...</Content></Tab>

  <Tab><Title>Title2</Title><Content>...</Content></Tab>
</TabView>

<Template tag="Tabs">
  <div repeat="${My.Tab}"><os:Render select="${Title}"></div>...

</Template>

I'm pretty sure the implementation issues are solvable and don't require particularly complex processing (see notes below). I'd have to see very strong argument for why this is unimplementable in order to support removing this feature from the spec.

On Tue, Dec 15, 2009 at 10:40 AM, goosemanjack <cc...@myspace.com> wrote:

> I don't believe we need to know this ahead of time.
> If the template calls <os:Render>, that is a directive to treat child elements as content.

Having this behavior requires the template not be passed not only the
resolved parameters, but much additional data:

1. Resolved parameters
2. Duplicate copy of each parameter as a string, ordered
3. Duplicate copy of entire set of parameters as a string, ordered.

Invoking a template should be analogous to making a function call. In
function calls, things are evaluated right to left, with parameters
being resolved prior to invoking the function and passing the resolved
parameters into the function.

${My} should be passed around as a NodeList. NodeLists are standard types and don't need to be copied into arrays of strings, etc. when you pass them to a function.

The way <os:Render> is specified breaks this model of treating
template calls as function calls. As pointed out previously, removal
of <os:Render> does not remove the ability to display markup. The
developer simply makes use of the <os:Html> tag, using the parameter
name as content.

To follow on, ${nodeList.foo} would be evaluated differently than ${object.foo}.

Lev Epshteyn

unread,

Dec 16, 2009, 12:16:35 PM12/16/09

to opensocial-an...@googlegroups.com

One thing I'd add is that in all the use cases where Evan has <os:Render>, the examples show simple stings, which can seemingly be replaced with ${My} invocations:

<os:Render content="title"> -> ${My.title}

However this is only so for when the content in question is a string. If the content contained markup, using ${My} as Chris proposes would suddenly make this markup subject to stricter escaping (whereas with <os:Render>, <script> tags can be used if allowed by the page). Similarly, if the content included repeaters, conditionals or nested custom tags (which are explicitly supported today), the ${My} approach breaks down (or at least has not been defined).

goosemanjack

unread,

Dec 17, 2009, 4:18:58 PM12/17/09

to OpenSocial - OpenSocial and Gadgets Specification Discussion

So if I'm to paraphrase back how Shindig views <os:Render> vs
<os:Html>, the breakdown is as follows:

<os:Render> : Displays markup passed in as a parameter to the
template,
running the markup thru the template processor to resolve any
OSML tags.

<os:Html> : Displays markup passed in as a parameter to the
template
WITHOUT running the markup thru the template processor,
subject to restrictions on allowed tags.

Is that more or less accurate? As I look at this, os:Render only
becomes interesting if it ingests markup (that has control tags
embedded) from an external source (ex: markup resulting from an
<os:HttpRequest>). That would allow an external server to feed in
OSML dynamically. Restricting os:Render to markup that is hard-coded
into the gadget definition isn't especially useful, as there are any
number of ways a gadget author could achieve the same behavior as I've
seen so far in all your examples - placing the markup in multiple
custom tag template definitions, creating more granular template
definitions, etc. All those methods allow control structures and
recursive nesting of templates without using this tag.

This also begs the question of why we wouldn't just run all markup
thru the template processor to resolve any OSML markup or custom tags
in every case. The base set of tags is pretty rudimentary, so I don't
see much that would be a security risk. We could disallow dynamic
processing of anything that was a risk (ex: data tags). If there was
a need to allow the author to allow/disallow processing OSML tags,
that could easily be accommodated by an additional attribute on
os:Html (ex: @processOsml="true|false").

Having two tags that are so similar in execution seems unnecessary to
me. In so many scenarios they will evaluate to the same result; we
would be better served by trying to extend <os:Html> to cover the use
cases you feel are currently only satisfied by <os:Render>.
--
clc

> ...
>
> read more »

Evan Gilbert

unread,

Dec 18, 2009, 12:28:13 PM12/18/09

to opensocial-an...@googlegroups.com

<os:Html>

Goal: Render HTML data provided a string from data pipelining (and possibly from other sources). Needed for showing data from RSS feeds, Atom, or any other data source that sends raw HTML content.

-

<os:Render>

On Thu, Dec 17, 2009 at 1:18 PM, goosemanjack <cc...@myspace.com> wrote:

So if I'm to paraphrase back how Shindig views <os:Render> vs
<os:Html>, the breakdown is as follows:

<os:Render> : Displays markup passed in as a parameter to the
template,
running the markup thru the template processor to resolve any
OSML tags.

+ Input is a DOM structure, no need to support non-wellformed input

+ Input is code that the developer is written and is generally trusted at the same level as the developer

<os:Html> : Displays markup passed in as a parameter to the
template
WITHOUT running the markup thru the template processor,
subject to restrictions on allowed tags.

+ Input is a string (although we can define this as evaluating the expression as a string)

+ We may want to support non-wellformed input here - there are many feed sources that are HTML, not XML.

+ Input is data from an unknown source, and generally should be treated as untrusted.

Is that more or less accurate? As I look at this, os:Render only
becomes interesting if it ingests markup (that has control tags
embedded) from an external source (ex: markup resulting from an
<os:HttpRequest>). That would allow an external server to feed in
OSML dynamically. Restricting os:Render to markup that is hard-coded
into the gadget definition isn't especially useful, as there are any
number of ways a gadget author could achieve the same behavior as I've
seen so far in all your examples - placing the markup in multiple
custom tag template definitions, creating more granular template
definitions, etc. All those methods allow control structures and
recursive nesting of templates without using this tag.

This also begs the question of why we wouldn't just run all markup
thru the template processor to resolve any OSML markup or custom tags
in every case. The base set of tags is pretty rudimentary, so I don't
see much that would be a security risk. We could disallow dynamic
processing of anything that was a risk (ex: data tags). If there was
a need to allow the author to allow/disallow processing OSML tags,
that could easily be accommodated by an additional attribute on
os:Html (ex: @processOsml="true|false").

Dynamic OSML is an interesting idea, not sure if the restrictions would be too restrictive. Do you have specific use cases where this might be needed over static OSML content?

Having two tags that are so similar in execution seems unnecessary to
me. In so many scenarios they will evaluate to the same result; we
would be better served by trying to extend <os:Html> to cover the use
cases you feel are currently only satisfied by <os:Render>.

Your arguments make sense in terms of similar functionality.

However, I'm still in favor of the tags being separate because developers need to be aware of the difference between rendering their own markup (<os:Render>) and rendering data that may come from 3rd parties (<os:Html>).

<os:Html> almost didn't add it to the spec - you can do almost everything a developer needs with <os:Render> - but there are a few use cases where a 3rd party sends HTML, especially with RSS feeds. <os:Html> should always trigger a security review, because it is incredibly easy to create an XSS hole. For example, <os:Html code="${address}"> is a virus or privacy leak waiting to happen.

Also, although we could merge the processing models and support the union in a single tag, the only thing these tags really have in common today is that they output HTML.

Pseudocode:

render(RenderingContext context, String path) {

NodeList nl = Context.getMy().getNodeList(path);

for (Node n : nl) {

context.process(nl);

}
}

html(RenderingContext context, String code) {

HTMLElement el = context.getEnclosingElement()

el.innerHTML = code;
}

> ...
>
> read more »

goosemanjack

unread,

Dec 18, 2009, 6:54:08 PM12/18/09

to OpenSocial - OpenSocial and Gadgets Specification Discussion

The term "trusted source" needs to be explored. The paradigm of our
developers is that they have an external server running a large
portion of their app, which should be considered a "trusted source".
There are also some mashup-style apps consuming "untrusted source"
content. In v.Next we would have to accommodate some mechanism for a
developer to white-list urls as "trusted"

This actually breaks down even further:

* Trusted by developer: (any URI to a site they control)

* Trusted by container: (nothing, other than pre-verified content or
partner content)

* Untrusted

This line of conversation, while germane to the broader security
conversation, takes us off into the woods as far as this topic goes a
little bit.

> However, I'm still in favor of the tags being separate because developers
> need to be aware of the difference between rendering their own markup
> (<os:Render>) and rendering data that may come from 3rd parties (<os:Html>).

As we've argued before, that distinction is far too subtle for most
developers to understand. If left as two tags this will be constantly
mis-applied. An attribute marking the content as "trusted" vs
"untrusted" on a singular tag will be much more obvious for most
users. It also leaves open the issue of what happens when a developer
places untrusted content in an <os:Render> tag. Once content is
received, the originating source is not strongly tracked. Inline
content can, or course, be recognized. But as we've said earlier, it
doesn't really add much in the way of utility if all a developer can
do is hard-code in the content. Passing the same content in to a more
cleverly designed set of templates can generate the same result in
almost any scenario.

> Do you have specific use cases where this might be needed
> over static OSML content?

Not really, but our developer usage patterns involve many apps making
use of an external, trusted server. They often iterate more
frequently on the content under the control of their external server
than that of the core app. Most cases can probably be satisfied with
well-authored templates and static parameters. This argument is
mostly put forth for the sake of completeness WRT the functional
behavior of template gadgets. If you're going to argue hard-coded
content should have this functionality accessible, the same
functionality should also be provided to content pulled dynamically
from an external location.
--
clc

> ...
>
> read more »

Evan Gilbert

unread,

Dec 18, 2009, 9:15:35 PM12/18/09

to opensocial-an...@googlegroups.com

On Fri, Dec 18, 2009 at 3:54 PM, goosemanjack <cc...@myspace.com> wrote:

The term "trusted source" needs to be explored. The paradigm of our
developers is that they have an external server running a large
portion of their app, which should be considered a "trusted source".

Sorry, I should have said that the difference is between markup & data.

Even "trusted" sources have data that is untrusted - anything that a user entered is untrusted in this case. In our experience, the most common cause of XSS holes is when the developer has to remember which data is "trusted" and which is "untrusted".

It should be very rare that you render HTML from data parameters - <os:Html> was only added to support the occasional use case of rendering trusted data - for example an RSS feed that you trust has been sanitized.

It's because this distinction is subtle that we need two tags. <os:Html> needs to be marked as an advanced feature and have the big text to say "DON'T USE THIS unless you know what you're doing".

Having one tag that promotes XSS holes doesn't fly. It's one of our most important programming guidelines for security - automatically escape all data that might be user generated.

> ...
>
> read more »

Lev Epshteyn

unread,

Jan 5, 2010, 11:42:23 AM1/5/10

to opensocial-an...@googlegroups.com

Sorry to jump into this two weeks on - I was away for the holidays and am only now catching up...

On Thu, Dec 17, 2009 at 4:18 PM, goosemanjack <cc...@myspace.com> wrote:

So if I'm to paraphrase back how Shindig views <os:Render> vs
<os:Html>, the breakdown is as follows:

<os:Render> : Displays markup passed in as a parameter to the
template,
running the markup thru the template processor to resolve any
OSML tags.

<os:Html> : Displays markup passed in as a parameter to the
template
WITHOUT running the markup thru the template processor,
subject to restrictions on allowed tags.

Is that more or less accurate?

I would phrase it differently, as Evan has: <os:Render> deals with markup - markup that already exists in the gadget spec, so the security considerations are minimal. On the other hand, <os:Html> creates markup from data (be it container data, app data or user data). Because this data was not initially created as markup by the developer, security considerations and red flags apply. For instance, I don't see a reason for allowing OSML control tags to be honored by <os:Html>.

As I look at this, os:Render only
becomes interesting if it ingests markup (that has control tags
embedded) from an external source (ex: markup resulting from an
<os:HttpRequest>). That would allow an external server to feed in
OSML dynamically. Restricting os:Render to markup that is hard-coded
into the gadget definition isn't especially useful, as there are any
number of ways a gadget author could achieve the same behavior as I've
seen so far in all your examples - placing the markup in multiple
custom tag template definitions, creating more granular template
definitions, etc. All those methods allow control structures and
recursive nesting of templates without using this tag.

I don't think that's true, at least not without significant changes to how ${My} works (some of which you are proposing, to be fair). The advantage of <os:Render> is that it allows much better custom tags to be built, and eventually packaged into tag libraries.

I still don't see how we can make something like:

<app:RounderCorners>
<h1>Title</h1>
<os:Repeat expression="${bullets}"><li>${Cur}</li></os:Repeat>
</app:RoundedCorners>

work without <os:Render>.

This also begs the question of why we wouldn't just run all markup
thru the template processor to resolve any OSML markup or custom tags
in every case. The base set of tags is pretty rudimentary, so I don't
see much that would be a security risk. We could disallow dynamic
processing of anything that was a risk (ex: data tags). If there was
a need to allow the author to allow/disallow processing OSML tags,
that could easily be accommodated by an additional attribute on
os:Html (ex: @processOsml="true|false").

I'm not sure if I understand you correctly... Are you suggesting that if I have <os:Html content="${user.info}"/> and user sets his info to be something like "<os:Repeat expression="${Top.friends}">${Cur.name}</os:Repeat>", than that should be expanded by <os:Html>? If so, I'd like to know your reasoning. This seems like a pretty serious security problem waiting to happen if you ask me.

Having two tags that are so similar in execution seems unnecessary to
me. In so many scenarios they will evaluate to the same result; we
would be better served by trying to extend <os:Html> to cover the use
cases you feel are currently only satisfied by <os:Render>.

I think the argument Evan and I are trying to make is that while it may seem like for some non-advanced use cases these tags overlap functionally, they are really designed to do sufficiently different things, and encourage the developer to think differently about their own markup and third/second party data. Do you not find this a worthwhile distinction to codify?

> ...
>
> read more »

goosemanjack

unread,

Jan 8, 2010, 1:40:49 AM1/8/10

to OpenSocial - OpenSocial and Gadgets Specification Discussion

Based on all the discussions and the phone conference and general lack
of support for deprecation, we've decided to kill this proposal for
the 1.0 round.
--
clc

On Jan 5, 8:42 am, Lev Epshteyn <le...@google.com> wrote:
> Sorry to jump into this two weeks on - I was away for the holidays and am
> only now catching up...
>
>
>
> On Thu, Dec 17, 2009 at 4:18 PM, goosemanjack <cc...@myspace.com> wrote:
> > So if I'm to paraphrase back how Shindig views <os:Render> vs
> > <os:Html>, the breakdown is as follows:
>
> > <os:Render> : Displays markup passed in as a parameter to the
> > template,
> > running the markup thru the template processor to resolve any
> > OSML tags.
>
> > <os:Html> : Displays markup passed in as a parameter to the
> > template
> > WITHOUT running the markup thru the template processor,
> > subject to restrictions on allowed tags.
>
> > Is that more or less accurate?
>
> I would phrase it differently, as Evan has: <os:Render> deals with markup -
> markup that already exists in the gadget spec, so the security