Re: [opensocial-and-gadgets-spec] Proposal for 1.0 - <os:Var>

[Lev Epshteyn]

Here are my comments on the proposal at  http://wiki.opensocial.org/index.php?title=Temporary_vars_in_templates_and_data_pipelining&oldid=3812:

• Allowing both <os:Var key="a" value="${foo}"/> and <os:Var key="a">${foo}</os:Var> seems redundant. Let's pick one. Which one depends on the kinds of usages we want.
  
• The array examples show defining constant arrays. They should show how a dynamic array can be made. For example, are repeaters expected to work inside <os:Var>?
• The syntax for defining arrays looks overly verbose, and, arbitrarily, favors arrays but not dictionaries. Perhaps allowing JSON would be better? I really dislike defining "special" tags like <Array> and <Item>.

In general, I liked Adam's original proposal of <os:Var key="a" value="${foo}"/>, where value could evaluate to an object. Putting value in the content seems like a workable solution - as long as the content gets EL expressions evaluated.

Adding @type and special array syntax seems like a lot of complexity, and I'm not sure I see the advantage, since this doesn't really show how to create complex objects other than hard-coding them.

[Evan Gilbert]

I'd like the value of <os:Var> be immutable when rendering a template. You lose the ability to process templates non-iteratively without this characteristic. So I don't think we should support the example in 1.2.

In general, the goal of templates is to do computation before passing into the template. You end up needing full expression support for common HTML use cases (mod operator for alternating background colors, + operator for correct pagination if it is 0 based), but I don't think we should try to support all programming use cases - templates are a poor programming language.

If we want to support users creating computed data based on Data Pipelining content, think it would be more useful to put this into the Data Pipelining spec, and I think this would be a great addition to the spec. But I also think this is a long discussion, because you end up wanting a real programming language, first class functions, etc.

More comments inline

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

Here are my comments on the proposal at  http://wiki.opensocial.org/index.php?title=Temporary_vars_in_templates_and_data_pipelining&oldid=3812:

• Allowing both <os:Var key="a" value="${foo}"/> and <os:Var key="a">${foo}</os:Var> seems redundant. Let's pick one. Which one depends on the kinds of usages we want.
  
• The array examples show defining constant arrays. They should show how a dynamic array can be made. For example, are repeaters expected to work inside <os:Var>?

-1 on dynamic arrays inside templates. As mentioned above - maybe in Data Pipelining?

• The syntax for defining arrays looks overly verbose, and, arbitrarily, favors arrays but not dictionaries. Perhaps allowing JSON would be better? I really dislike defining "special" tags like <Array> and <Item>.

Preference for JSON - +1 JSON, +0 on XML.

In general, I liked Adam's original proposal of <os:Var key="a" value="${foo}"/>, where value could evaluate to an object. Putting value in the content seems like a workable solution - as long as the content gets EL expressions evaluated.

If this meets enough use cases, using just @value would be a great first step in defining <os:Var>. This is hard functionality to get right, and I'd like to start with the most minimal spec change that meets the use cases.

 

Adding @type and special array syntax seems like a lot of complexity, and I'm not sure I see the advantage, since this doesn't really show how to create complex objects other than hard-coding them.

+1 for no @type. 

--

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]

• The array examples show defining constant arrays. They should show how a dynamic array can be made. For example, are repeaters expected to work inside <os:Var>?

-1 on dynamic arrays inside templates. As mentioned above - maybe in Data Pipelining?

Not sure "dynamic" was the right word to use. I just meant arrays with non-hardcoded values.

So, <os:Var key="foo" value="['A', 'B', 'C']"/> seems like a straightforward way to define an array of ['A', 'B', 'C'], but this is hardly ever needed in real-world.

A possibility is saying you can only do <os:Var key="foo" value="${bar}"/> and if ${bar} evaluates to an array, that's the only way to set an array variable.

I imagine Chris' proposal for array syntax is motivated by a real need to create arrays at runtime in some cases - would like to see what those situations are so we can see how to best acommodate them.

[goosemanjack]

Comments below

> - Allowing both <os:Var key="a" value="${foo}"/>

> and <os:Var key="a">${foo}</os:Var> seems redundant.
> Let's pick one. Which one depends on the kinds of usages we want.

It is redundant, but it is also the behavior allowed by template
parameters, where values may be referenced from elements or
attributes. I view the attribute syntax as being a shorthand syntax
for simple cases. The element syntax is also required if your desire
is to create arrays that reference objects in the DataContext.

<os:Var key="somevar">
<Array>
<Item>${friends[0]}</Item>
<Item>${friends[3]}</Item>
<Item>${friends[5]}</Item>
</Array>
</os:Var>

> Adding @type and special array syntax seems like
> a lot of complexity, and I'm not sure I see the advantage,

It's a processing hint that allows for clarity of intent and headroom
for future expansion. The thought is that at some point in the future
we may with to add JSON literal support, but I didn't want to burden
this proposal with JSON support since server-side processing would
need to parse and construct the object as well. In general it is not
needed in most cases. It is a useful hint if the value is a simple
string literal that contains commas. The @type allows the dev to
distinguish between what should be treated as an array and what should
be treated as a string.

> As mentioned above - maybe in Data Pipelining?

The os:Var patch is actually much more clear than the original wiki
doc and catches most of the edge cases you mention. It includes
language about how to use os:Var in Data Pipelining and what the
expected behavior will be. If you have trouble with merging and
reading the patch (http://codereview.appspot.com/143075) I can update
the wiki docs as well.

> You end up needing full expression support for common HTML use
> cases (mod operator for alternating background colors, + operator for
> correct pagination if it is 0 based),

The alternating color row is one of the prime use cases for defining
literal arrays. I firmly believe we will see the EL and templating
drift toward a full programming language over time. Once it achieve
adequate functionality there will be many use cases where use of
Javascript is disallowed.

> A possibility is saying you can only do <os:Var key="foo" value="${bar}"/>
> and if ${bar} evaluates to an array, that's the only way to
> set an array variable.

Making that change is akin to making os:Var useless. If the object
being assigned is already an array, why would I ever both re-assigning
it to another variable name. Our offer to accept the param-as-XML-
elements argument for creating arrays that is going on in the thread
on clarifying template parameters is contingent on os:Var including an
alternate syntax for creating complex array constructs. Lev has
stated at least twice he finds the syntax too verbose, so we are open
to hearing an alternative syntax proposed, but we're not willing to
strike the array syntax in its entirety.
--
clc


On Nov 3, 9:45 am, Lev Epshteyn <le...@google.com> wrote:
> >>    - The array examples show defining constant arrays. They should show

[goosemanjack]

For those stumbling on this thread, please also cross-reference this
thread

https://groups.google.com/group/opensocial-and-gadgets-spec/browse_thread/thread/eb3606b9caa9e348

[Evan Gilbert]

That makes sense. My key goal was to not have <os:Repeat> or <os:If> inside <os:Var> statements in templates. These might make sense in Data Pipelining, as they could be evaluated once, globally, on the server.

(fyi - codereview wasn't easy to read, might be worth copying to the wiki)

 

> You end up needing full expression support for common HTML use
> cases (mod operator for alternating background colors, + operator for
> correct pagination if it is 0 based),

The alternating color row is one of the prime use cases for defining
literal arrays.

I've been using the following for alternating rows:

<div repeat="${people}" class="{Context.Index % 2 == 1 ? 'dark' : 'light'}">

  ${displayName}

</div>

 

 I firmly believe we will see the EL and templating
drift toward a full programming language over time.  Once it achieve
adequate functionality there will be many use cases where use of
Javascript is disallowed.

I think that the data pipelining should allow for full programming at some point, probably using a programming language (JS?). Template languages are not great for performing calcluations - you often end up with inefficient processing and ugly code.

Use cases would help here.

> A possibility is saying you can only do <os:Var key="foo" value="${bar}"/>
> and if ${bar} evaluates to an array, that's the only way to
> set an array variable.

Making that change is akin to making os:Var useless.  If the object
being assigned is already an array, why would I ever both re-assigning
it to another variable name.

Convenience - your ${saveKeystrokes} example.

Use cases would also help here - it makes sense to me that array literals could be useful, but I've never run into a case where I felt they were needed.

 

[Lev Epshteyn]

On Tue, Nov 3, 2009 at 7:24 PM, goosemanjack <cc...@myspace.com> wrote:

 

> A possibility is saying you can only do <os:Var key="foo" value="${bar}"/>
> and if ${bar} evaluates to an array, that's the only way to
> set an array variable.

Making that change is akin to making os:Var useless.  If the object
being assigned is already an array, why would I ever both re-assigning
it to another variable name.  Our offer to accept the param-as-XML-
elements argument for creating arrays that is going on in the thread
on clarifying template parameters is contingent on os:Var including an
alternate syntax for creating complex array constructs.  Lev has
stated at least twice he finds the syntax too verbose, so we are open
to hearing an alternative syntax proposed, but we're not willing to
strike the array syntax in its entirety.

Would something like <os:Var key="foo" value="['A', 'B', 'C']" /> work for your needs?

I struggle to see how the proposed syntax can be used to make non-hardcoded arrays. Admittedly, my proposal fails there as well, but it does so with far less typing, and without inventing new markup formats. JSON will feel much more natural to our developers than XML for defining complex data objects. As for processing on the server, I believe all server languages have existing libraries for working with JSON (whereas an XML format we invent would need to have a custom parser created).

However, I'd like to go back to discussing the use cases we need to enable - I do see the value of hardcoded arrays, but as I mentioned they don't need such an elaborate syntax to create. From what I can tell, this syntax allows us to create hardcoded objects, or reassign existing objects for easier access, but creating objects at runtime is not possible. Personally, I am OK with that, but wanted to see if that's what the intent was.

[Lane LiaBraaten]

This is becoming a pretty large change.  Introducing new tags and syntax is the type of thing that needs to be prototyped and should really be vetted by real world use -- hence my inclination to approach this as an extension rather than adopting it into the core spec on the first pass.

Shindig has already implemented a <osx:Variable> tag that supports the basic saveKeyStrokes [1] and sum values [2] use cases.  I'd be comfortable adopting the <os:Var key="foo" value="bar"/> functionality now and building on that in future versions.

-Lane

[1]
  <os:Var key="saveKeystrokes" value="${a.really.long.expression.that.is.used.repeatedly}"/>
  ${saveKeystrokes.aProperty}  ${saveKeystrokes.anotherProperty}



[2]
  <os:Var key="sum" value="0"/>
  <os:Repeat expression="${some.list.of.integers}">
     <os:Var key="sum" value=${sum + Cur}/>
  </os:Repeat>

[goosemanjack]

I've created an updated wiki page that contains just the contents of
the patch.

http://wiki.opensocial.org/index.php?title=Os:Var_variables_in_templates_and_data_pipelining

As you suggested, Lev, it allows for the syntax <os:Var key="foo"
value="['A', 'B', 'C']" />. This is in the patch, but it might need
to be updated to include the wrapping brackets. In particular this is
a situation where I see the need for the @type="array" attribute as in
the below example.

<os:Var key="anarray" type="array" value="['I am in', 'an array of
values', 'but I don't mind']" />

versus

<os:Var key="anarray" value="['I am not in', 'an array of values',
'because I want to be a literal string']" />

The first tag creates an array with three strings. The second tag
creates one string with embedded quotes and commas. The presence of
the @type="array" setting clarifies both to the developer and to the
parser how this value should be interpreted.

It sounds to me like this proposal is just extending what Shindig
already has implemented. If there is a strong feeling against
requiring support for the element-array syntax would everyone be
accepting of making the array syntax a MAY as far as support within
os:Var? The downside of considering array support an extension to
os:Var is if MySpace and Shindig come up with a slightly different
syntax for expressing things.
--
clc

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

[Lev Epshteyn]

Perhaps we can remove ambiguity by saying that @value will

1. Be processed to replace ${} markup
2. For a single EL value, return the resulting object
   
3. Attempt to parse it as a JSON value
   
4. Returned as a string as the last resort
   

I think it would also be nice to line up the @value processing of <os:Var> with the attribute processing of custom tags - this will enable us to not special case <os:Var> inside custom tags. I dislike such support because of its ambiguity:

<my:Bold>
   <!-- Here, the user variable is defined for use in the content of <my:Bold>, not as an input to it -->
   <os:Var key="user" value="${viewerFriends[currentFriendIndex]}"/>
   More information on , <os:Badge person="${user}"/> 
</my:Bold>

<my:Bold>
   <!-- Here, the color variable is defined as an input to the <my:Bold> tag -->
   <os:Var key="color" value="green"/>
   More information on , <os:Badge person="${user}"/> 
</my:Bold>

These two use cases are impossible to distinguish between.

To unsubscribe from this group, send email to opensocial-and-gadg...@googlegroups.com.

[goosemanjack]

Those rules sound good. I'll update the patch to include this
information. I'll also re-read the examples you flag to see if I can
make them more clear.
--
clc

On Nov 10, 5:31 pm, Lev Epshteyn <le...@google.com> wrote:
> Perhaps we can remove ambiguity by saying that @value will
>

>    1. Be processed to replace ${} markup
>    2. For a single EL value, return the resulting object
>    3. Attempt to parse it as a JSON value
>    4. Returned as a string as the last resort

>
> I think it would also be nice to line up the @value processing of <os:Var>
> with the attribute processing of custom tags - this will enable us to not
> special case <os:Var> inside custom tags. I dislike such support because of
> its ambiguity:
>
> <my:Bold>
>    <!-- Here, the user variable is defined for use in the content of
> <my:Bold>, not as an input to it -->
>    <os:Var key="user" value="${viewerFriends[currentFriendIndex]}"/>
>    More information on , <os:Badge person="${user}"/>
> </my:Bold>
>
> <my:Bold>
>    <!-- Here, the color variable is defined as an input to the <my:Bold> tag
> -->
>    <os:Var key="color" value="green"/>
>    More information on , <os:Badge person="${user}"/>
> </my:Bold>
>
> These two use cases are impossible to distinguish between.
>
> On Wed, Nov 4, 2009 at 5:09 PM, goosemanjack <cc...@myspace.com> wrote:
> > I've created an updated wiki page that contains just the contents of
> > the patch.
>

> >http://wiki.opensocial.org/index.php?title=Os:Var_variables_in_templa...

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

[Evan Gilbert]

It seems like we may be converging on here, but I'm not sure what the result is.

A few things I'd like to see:

- Ability to shorten long variables <os:Var key="user" value="${some.long.expr.to.create.a.shortcut.for}">

- Some ability to define constant values beyond strings (arrays/objects). I have a preference for only allowing this in Data Pipelining, as these are constants and should be able to be globally declared. However, with use cases I could see adding to inline variables

- No ability to set the value of an <os:Var> more than once when rendering a template. I'd like to push processing of data inside of data pipelining and add richer support in the future. Specific example I don't want to support is:

  <os:Repeat expression="${some.list.of.integers}">

     <os:Var key="sum" value=${sum + Cur}/>
  </os:Repeat>

Evan

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=.

[Lev Epshteyn]

What is your objection to this example? I think it is ok to support this, not because I care strongly about being able to have this type of dynamic calculations within templates, but rather because the chosen syntax suggests that it is supported.

Lack of support in this use case may be unexpected for the users, and seem arbitrary.

For more options, visit this group at http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en.

[Evan Gilbert]

On Tue, Nov 24, 2009 at 1:31 PM, Lev Epshteyn <le...@google.com> wrote:

What is your objection to this example?

From earlier in the thread - you lose the ability to process templates non-iteratively. This has implications both for total processing time and for user interactions. 

For example:

- UI shows a list of friends

- User adds a friend

- You want the code to update the friend list on the client side.

In this case, you want to update by adding a single DOM element for the new friend and not by recomputing the whole list. As soon as you have variables whose values can change, you have to iterate through the entire list to update based on the change to this one piece of data.

[Lev Epshteyn]

Hmm.. Ok... I think such optimized processing may be very difficult in the ad-hoc world of templates (I was once involved in implementing something similar in a much more structured setting). But yes, it would be completely impossible with the accumulator use case above.

But what about using <os:Var> inside of loops like this:

<div repeat="${friends}">
   <os:Var key="address" value="${Cur.addresses[0]}"/>
   ${Cur.name} lives at ${address.street} in ${address.city}
</div>

Perhaps we should say that <os:Var> works in the local scope of the innermost repeater or custom tag?

This would make the define-once restriction easier to swallow.

[Evan Gilbert]

On Tue, Nov 24, 2009 at 2:14 PM, Lev Epshteyn <le...@google.com> wrote:

Hmm.. Ok... I think such optimized processing may be very difficult in the ad-hoc world of templates (I was once involved in implementing something similar in a much more structured setting). But yes, it would be completely impossible with the accumulator use case above.

But what about using <os:Var> inside of loops like this:

<div repeat="${friends}">
   <os:Var key="address" value="${Cur.addresses[0]}"/>
   ${Cur.name} lives at ${address.street} in ${address.city}
</div>

Perhaps we should say that <os:Var> works in the local scope of the innermost repeater or custom tag?

I agree we should try to find a way to support the use case above.

Think we need to have a crisper way to describe this - the "innermost repeater" was a little unclear (although examples will help). 

Possibly we can say that:

1. <os:Var> is scoped to it's containing XML element, and

2. An <os:Var> can only refer to other <os:Var>s in an enclosing scope - it cannot refer to <os:Var>s at the same or narrower scope.

[goosemanjack]

It seems to me that it's actually extra work to deny re-assignment to
a variable. The loop assignment to a variable in repeaters is
absolutely required, IMO. Disallowing it outside repeaters seems
somewhat arbitrary. Content blocks are processed sequentially. Loops
execute sequentially. (Inline) templates are rendered sequentially.
If we use the javascript API to assign values to the data context,
that happens sequentially in the execution of the page (albeit on the
client).

I'm not seeing what the downside is to allowing reassignment to a
variable. In fact, making this restriction doesn't seem to really add
anything and could be the source of confusion to developers. About
the only place I see any case to making the key immutable would be
within a Data Pipeline script block, since these tags are supposed to
be interpreted "all at once". We could make os:Var in data pipeline
blocks throw an error. That would make sense. This should also be a
rule applied to all data pipeline tags, not just os:Var.

I don't like the "innermost repeater" restriction either. It's seem
hard to explain to a developer why this restriction is in place.

Evan, I tend to disagree with the suggestions as they're written. In
the first one, "scoped to it's containing XML element" is fairly
ambiguous. Do you mean any markup, any OSML tag, or any Content
block? The choice of scoping to template was made because the
mechanism for scoping to template is already in place via the ${My}
variable and handling for custom tags. All inline templates valid for
a view are treated as a single unit for the purposes of scoping in the
current proposal.

On the second item, I think that restriction doesn't make sense when
compared to variable scoping used in other programming languages. In
compiled languages you get something similar, but variables can always
refer to other variables in the same scope. In dynamic languages
there really aren't any scoping restrictions like you've outlined.
The system simply tries to resolve the variable value at that moment
during runtime. We're approaching the EL and data pipelining as more
of an interpreted, dynamic language. This path makes more sense in my
mind - particularly when a large portion of our developers are web
developers who are most familiar with the JavaScript paradigm of
dynamic interpretation.
--
clc

> ...
>
> read more »

[Evan Gilbert]

I'm fairly strongly opposed to a formulation of <os:Var> that prevents us from incrementally re-rendering the page when a single item in a list changes. Incremental redraw (and the associated ability to parallelize processing) is needed to scale up to the needs of more complex web applications.

I'm flexible on what approach we use to support this - there are probably a number of options.

I agree the limitations we may impose on <os:Var> may feel arbitrary from the developer perspective, but that's a downside I'm willing to take for the processing benefits.

 

[Lev Epshteyn]

Personally, I don't like the scope-to-xml approach either. While I don't feel as strongly as Evan about disallowing reassignment, I do think it can be useful with a more advanced processor.

Adding XML-level scoping however introduces a new concept - currently, scopes are only created at template/tag invocation (${My}) and inside repeaters (${Cur}) - I propose that if we limit reassignment by scope, then these are the scopes we use. While the definition may seem a bit fuzzy, I think it's consistent with existing scoping behavior.

[goosemanjack]

Just to do a quick checkpoint summary, these are the changes I'll make
to the patch proposal:

1. Eliminate the XML array syntax and replace it with JSON support
2. Eliminate the @type attribute and replace it with the processing
rules Lev proposed

to address Evan's concern -

3. Disallow multiple assignments to the same key within Data Pipeline
tags


And on the incremental redraw point, comments below

> I'm fairly strongly opposed to a formulation of <os:Var> that
> prevents us from incrementally re-rendering the page
> when a single item in a list changes.
> Incremental redraw (and the associated ability to
> parallelize processing) is needed to scale up to the needs
> of more complex web applications.

I don't see allowing re-assignment to a key with os:Var within
template blocks as in any way disallowing incremental redraw/
reprocess. Any incremental redraw is most likely to happen on the
client, so there is a completely divorced processing model that will
happen. On a render pass (depending on specific implementation), the
gadget will perform a sequential render, with all key assignments
occurring in sequence. On the use case of a template re-render
triggering off a data listener, this will happen in one of two ways:

1. The listener will trigger in the client-side JavaScript, processing
after all the inline templates, but in a non-deterministic order from
any other async listeners.

2. The listener will be handled on the server, in which case it will
either also process after the first linear render pass or it could
create the kinds of problems anyone who does much async processing
will already be familiar with.

I definitely can see the issue of multiple key assignments being
problematic in data pipeline blocks. We should address that as a
global clarification in the DP spec, since the error could occur with
any DP tag, not just os:Var. WRT in-template reassignment, I think
this is a red herring. A developer could conceivably already create
multiple key assignments using inline javascript within a re-rendered
template. If an implementer thinks multi-threaded rendering on the
server is the best path, they're already going to have a number of
technical hurdles around just managing the ${My}/${Cur} context when
there could be multiple loops/templates executing concurrently.
Writing a look-ahead validator to insure a key doesn't create
assignment collisions (or allowing behavior that could be expected
from a multi-threaded environment) does not preclude this sort of an
implementation. Realistically, tho, I don't see this as being a
problem.

Any significantly large and complex gadget is going to be executing
client-side in a browser using single-threaded JavaScript. I suppose
you could dredge of web workers as being the introduction of multi-
threading, but realistically os:Var allowing reassignment is not
introducing a problem that doesn't exist already. Any async XHR call
creates pseudo-critical section problems already. We're not going to
disallow using the client-side data context API within reprocessed
templates, so a developer could already code up script to do key re-
assignment within a template:

os.data.getDataContext().putDataSet("keyAlreadyHere", {"newValue": "I
just stomped on your people list"});


I'm not convinced there's actually a reason to disallow reassignment
to a key within a template using os:Var.
--
clc

> ...
>
> read more »

[Evan Gilbert]

This is the case where we need efficient processing. Concrete example:

<div repeat="${activities}">

  ${title}

</div>

Then the user posts a new activity on the client, and you add this to the activities JS object and want to re-render on the client side.

For many reasons, you only want the client to just add a <div> for the new activity. If you redraw the whole list, it is slow, can cause a flickering effect in the browser, and can lose the user's scroll position. This is from experience- I've built web apps that did a full redraw and then had to rebuild them because it wasn't an acceptable user experience.

<os:Var> is the only construct that would prevent redrawing a single item - all other information can be generated without iterating through the list sequentially. And this is only a problem if the <os:Var> is redefined over the course of list processing.

> ...
>
> read more »

[goosemanjack]

I'm not really seeing from this example how os:Var is causing the
incorrect value to display or be set. From the implementation/
behavior you describe, there's already a (possible) existing issue WRT
the loop ${Context} value.

From your example, on a partial render that only outputs new items,
but leaves the original list intact, the following will create invalid
output:

<div repeat="${activities}">
${title} Activity ${Context.Index + 1} of ${Context.Count}
</div>

First pass will be:

Foo Activity 1 of 3
Bar Activity 2 of 3
Bat Activity 3 of 3

After refresh that adds two items (with partial render you describe)

Foo Activity 1 of 3
Bar Activity 2 of 3
Bat Activity 3 of 3
Nob Activity 4 of 5
Bob Activity 5 of 5

Point being that the partial render you describe already has issues.
Allowing in-template reassignment with os:Var is not blocking your
proposed implementation, since it already has issues of data
inconsistency.

To further illustrate why reassignment with os:Var isn't creating any
new issues, we can look at doing the same thing with the javascript
API as with os:Var.

<div repeat="${activities}">
${title} Activity ${Context.Index + 1} of ${Context.Count}
<osVar key="somevar" value="${Cur.title" />
</div>

versus

<div repeat="${activities}">
${title} Activity ${Context.Index + 1} of ${Context.Count}
<script type="text/javascript">
opensocial.data.getDataContext().putDataSet("somevar", "$
{Cur.title}");
</script>
</div>


A developer that wanted to fine-tune a partial render by using a
listener would simply have to come up with a different mechanism to re-
render the list - like a manual processing of the DOM nodes. I don't
think disallowing a common use-case (reassigning values to the same
variable) for another less-common use case that already has issues is
a smart trade-off. They could also break up that block of markup into
multiple templates with narrower scoping to allow tighter re-
rendering.

The example you give is also the reason we were arguing for allowing
data-dependency marking on any OSML tag, instead of only at the
template level. In that way the effected scope would be controlled by
the developer, not subject to best-guess optimizations of the
container. Making this change, however, is not a proposal for this
round, so is merely brought up to illustrate that the use-case you
describe could be addressed in a way that has less ambiguity of intent
or potential ambiguous side-effects. Of course, without any changes
more or less the same thing can be achieved by segmenting the gadget
code into multiple inline templates with tight scope.
--
clc

> ...
>
> read more »

[Evan Gilbert]

Notes below.

I know that preventing <os:Var> from referencing other <os:Var>'s is slightly lame from a developer perspective, but I have a strong preference to have this limitation on <os:Var> for now. This behavior would change a core language characteristic for a relatively minimal developer benefit.

We've built systems like this before - it's a little complicated, but doable.

In this example, it's expected in this case that you would redraw all the elements, as the contents have changed. The template processing code adds listeners for each node for all of the data upon which it has dependencies.

In the example, the generated output HTML might look like:

<div id="100">

<div id="101">Foo Activity 1 of 3</div>

<div id="102">Foo Activity 2 of 3</div>

<div id="103">Bat Activity 3 of 3</div>

</div>

<script type="text/javascript">

  dataContext.addListListener('activities', function(listOp) {

    // listOp is the change to the list

    ... add the new elements here ...

  }

  dataContext.addListener('activities', function() {

   // This list is generated by looking at the dependencies for each node.

   // You only get added if you rely on something that depends on the list (index, count, current element)

    updateTemplateNode('101', 102', '103');

  });

</script>

The reason why var referencing var causes problems is that it's the only case when one list item needs to know the results of evaluation of another list item.

To further illustrate why reassignment with os:Var isn't creating any
new issues, we can look at doing the same thing with the javascript
API as with os:Var.

<div repeat="${activities}">
 ${title} Activity ${Context.Index + 1} of ${Context.Count}
<osVar key="somevar" value="${Cur.title" />
</div>

versus

<div repeat="${activities}">
 ${title} Activity ${Context.Index + 1} of ${Context.Count}
<script type="text/javascript">
opensocial.data.getDataContext().putDataSet("somevar", "$
{Cur.title}");
</script>
</div>

We don't allow <script> tags inside templates currently - this was originally planned for the spec but looks like it didn't make it in. @Lev - do you recall any links to the discussion?

Ignoring what we currently support, though, note that this JavaScript would not execute during template rendering, only after the HTML has been created. For consistency between client and server (and for general sanity), JavaScript functions would execute after the HTML had rendered. So in this case, you would set call openSocial.data.getDataContext().putDataSet(...) once per list element, but only after the template had rendered. 

 

> ...
>
> read more »

[goosemanjack]

My feeling is that in these situations we should be erring on the side
of what's good for the developers, not the implementers. We're
building this as a platform for developers, after all. Having os:Var
be immutable amounts to making it os:Const, which I disagree with.

I can think of a couple ways to achieve the partial re-render you talk
about while still correctly interpreting os:Var evaluation: Full
evaluation of the template on an in-memory DOM node, then diff the
innerHTML of the two instances and replace the changed areas.
Alternately, walk the DOM tree, evaluating all os:Var instances and
only re-writing DOM sections that have changed.

I'm OK with making os:Var immutable in data pipeline sections, but I
don't see this as a blocking issue for partial template re-rendering.
I also disagree with your statement that this is a relatively minor
developer benefit. I see lots of cases where there is real benefit to
having mutable variables in the template language. Particularly in
views where we're disallowing any app-generated javascript.

I'll post an updated patch with everything we're in agreement on
shortly.
--
clc

> ...
>
> read more »

[goosemanjack]

Updated patch submitted:

http://codereview.appspot.com/169044

> ...
>
> read more »

[Evan Gilbert]

I looked through the example code again and realized that the proposed spec enhancement allows for declaring the same <os:Var> multiple times in a given scope. This is what gives rise to the problems.

Updated proposal: "A variable can only be declared once with a given key in a given template". This is:

- Standard for programming languages, and

- Simple for developers to understand

@Chris - The example you're using for summing over a list allows for redefining a variable in what seems like an unintuitive way. 

Example from patch:

<os:Var key='sum" value="0">

<os:Repeat expression="${some.list.of.integers}">

  <!-- Does sum in ${sum + Cur} refer to this "sum" variable or the one above? -->

  <os:Var key="sum" value="${sum+Cur}"> 

</os:Repeat>

Rewritten in Java:

int sum = 0;

for (int cur : integers) 

  int sum = sum + cur;
}

Rewritten in JS:

var sum = 0;

for (var i = 0; i < integers.length; i++) {

  var sum = sum + integers[i];
}

On Wed, Dec 9, 2009 at 8:36 AM, goosemanjack <cc...@myspace.com> wrote:

My feeling is that in these situations we should be erring on the side
of what's good for the developers, not the implementers.  We're
building this as a platform for developers, after all.  Having os:Var
be immutable amounts to making it os:Const, which I disagree with.

I can think of a couple ways to achieve the partial re-render you talk
about while still correctly interpreting os:Var evaluation:  Full
evaluation of the template on an in-memory DOM node, then diff the
innerHTML of the two instances and replace the changed areas.
Alternately, walk the DOM tree, evaluating all os:Var instances and
only re-writing DOM sections that have changed.

I'm OK with making os:Var immutable in data pipeline sections, but I
don't see this as a blocking issue for partial template re-rendering.
I also disagree with your statement that this is a relatively minor
developer benefit.  I see lots of cases where there is real benefit to
having mutable variables in the template language.  Particularly in
views where we're disallowing any app-generated javascript.

Can you share these use cases? I'm probably missing the right examples... most of the possible use cases I can think of are:

1. Using a paginated list, where the sum of the items (or other functions) using the visible result set isn't that useful, or

2. Where the developer is providing data from their own backend, in which case it would be easier to process these variables from their side.

 

> ...
>
> read more »

[Lev Epshteyn]

Thanks for putting this together, Chris. I went trough and added some comments.
I think largely they are cosmetic except for two points:

 - I don't see why variables created in inline templates should be global when

custom tag-created vars are temporary. I think the right thing to do is to have
them all be temporary.

 - I *really* don't like the ability to put content into <os:Var>, especially
for the purposes of sticking markup into a variable.

> ...
>
> read more »

[goosemanjack]

Lev, to your comments:

1. The choice of making variables from inline templates become global
to the view has to do with the fact that only custom tag template
instances have a unique scope (aka ${My}). Creating scope for inline
templates would involve creating a new scoping construct, which I
wanted to avoid.

2. Markup content defined in a variable seems reasonable, so I wanted
to call it out explicitly. Since we agreed to leave os:Html within
the spec, that would be used to allow proper unescaped display.

With the explicit addition of JSON support, I can't imagine any sane
developer wanting to use an XML syntax to define complex objects.
That leaves the only practical use being for markup.


Evan, to your question about scoping the variable, I think your code
has errors in it. My java chops aren't what they were a few years
ago, but in c# that sample code is going to generate a compile time
error. Java and C# require explicit variable declaration and also
allow block-level scoping.

In your java example (assuming c# rule are the same as java):

int sum = 0;
for (int cur : integers)
int sum = sum + cur;
}

You'll get a compilation error because you're redefining a variable in
a narrower scope. If we eliminate the the "int sum =0;" that's above
the loop then you'll get the behavior I think you're going for, which
is the "sum" variable will fall out of scope outside the loop.

JavaScript, in turn, only allows scoping either at the global (window)
level or the function level. Your example is written in a
particularly confusing way, but in all instances the "var sum"
statement is referring to the same variable.

var sum = 0;
for (var i = 0; i < integers.length; i++) {
var sum = sum + integers[i];
}

I double checked it with this code and the answer is, in fact, 9 and
not 3 or 6.

function doit(){

var integers=[1,2,3];
var sum = 3;

for (var i = 0; i < integers.length; i++) {
var sum = sum + integers[i];
}

document.getElementById("answer").innerHTML=sum;
}

> (Evan)

> I looked through the example code again and realized that the proposed spec
> enhancement allows for declaring the same <os:Var> multiple times in a given
> scope.

The rules in the os:Var syntax are written to follow the JavaScript
scoping rules. That means that if the given variable already exists
in given scope, it is used. If it doesn't exist, it is created on
first reference. Since the client-side execution will be in
JavaScript it seemed logical to follow the same scoping rules. This
doesn't create any problems and actually reduces confusion since it
follows the same rules as JavaScript.

--
clc

> ...
>
> read more »

[Lev Epshteyn]

On Fri, Dec 11, 2009 at 4:28 PM, goosemanjack <cc...@myspace.com> wrote:

Lev, to your comments:

1. The choice of making variables from inline templates become global
to the view has to do with the fact that only custom tag template
instances have a unique scope (aka ${My}).  Creating scope for inline
templates would involve creating a new scoping construct, which I
wanted to avoid.

This seems like an implementation-driven decision (well, not implementation exactly, but almost): just because we don't have an existing scope to neatly tie a variable into, I don't think it should follow different patterns of behavior in the two cases. Variable use in both inline and custom tag case should be the same. The existence of an additional transient scope for custom tags shouldn't drive us to make it otherwise. I believe the correct behavior is for the variables to be temporary in both cases.

Regardless of how they are to be scoped, variables can be made temporary by
  a) putting them into ${Top}, then removing/restoring previous value when they are supposed to go out of scope
  b) adding a ${My} to inline template scope, which will only contain these variables, but not any XML-derived params
 

2. Markup content defined in a variable seems reasonable, so I wanted
to call it out explicitly.  Since we agreed to leave os:Html within
the spec, that would be used to allow proper unescaped display.

With the explicit addition of JSON support, I can't imagine any sane
developer wanting to use an XML syntax to define complex objects.
That leaves the only practical use being for markup.

Markup content only makes sense in a variable if it comes from user data (like rich text profile, etc). I can't think of a good use case to put runtime-created markup into a variable - support for this significantly complicates the developer model. I agree that XML content of <os:Var> should not define complex objects either, which is why I'd like to see us say that <os:Var> cannot have contents, and the only way to set the variable value is using the @value attribute.

This should be more than enough "power" to enable tons of interesting use cases. I would rather we add support for markup at a later date (or in an extension) if there is significant user need. Removing things from the spec are far harder.

Again, a bunch of issues emerge from supporting markup setting via inner XML - mainly how we plan to support repeaters, conditionals and custom tags within this content. By disallowing XML inside <os:Var> we get rid of all these ambiguities.

[goosemanjack]

You seem to be getting hung up on the word "temporary". As written,
this proposal allows both temporary and literal variable creation.
Looking more at the issue of scoping for inline templates, this
appears analogous to how inline JavaScript blocks behave. Declaring a
variable in one script block makes it available to all subsequent
script blocks - it does not restrict the variable just to the block in
which it was declared.

Ex:

<script type="text/javascript">
var foo = "someval";
</script>

... some markup

<script type="text/javascript">
var bar = foo + " other";
</script>

The behavior speced for os:Var matches the behavior of javascript
variables, so this is not an implementation-driven decision, but one
modeled on existing behaviors in JavaScript, which will be familiar to
gadget developers. If we adjust our thinking so that this is not so
much temporary variables as an alternate way of creating variables
within Data Context, this behavior is perfectly logical.

WRT the behavior of markup, we can strike the text from the patch, but
that doesn't address how to handle markup within a variable - it
simply ignores the issue. If the decision is to strip markup (like
accessing via innerText), how would you reconcile this behavior with
the behavior of referencing another variable that already has markup.

Ex:
contents of "some_url_to_html" = <h1>Hello world</h1>

<os:HttpRequest key="myfragment_key_is_long" format="text"
href="some_url_to_html" />
...
<os:Var key="kshort" value="${myfragment_key_is_long}" />
<os:Var key="kshort2" /><h1>Hello world</h1></os:Var>


Given the above example, what would your expected outputs be on the
three variables. My expectation is that they would all have identical
content. Just because the same content is bounced from an external
server doesn't mean it should be mangled. If instead we say that
os:Var strips all markup, then the behavior of using os:Var to create
shortened reference keys becomes broken (case "kshort").

Not having explicit behavior defined on many of these edge cases is
what makes 0.9 such a problematic spec - too much is left for
interpretation. My preference is to define correct and sensible
behavior on the edge cases.
--
clc

[Lev Epshteyn]

On Sun, Dec 13, 2009 at 5:29 AM, goosemanjack <cc...@myspace.com> wrote:

You seem to be getting hung up on the word "temporary".  As written,
this proposal allows both temporary and literal variable creation.
Looking more at the issue of scoping for inline templates, this
appears analogous to how inline JavaScript blocks behave.  Declaring a
variable in one script block makes it available to all subsequent
script blocks - it does not restrict the variable just to the block in
which it was declared.

Ex:

<script type="text/javascript">
var foo = "someval";
</script>

... some markup

<script type="text/javascript">
var bar = foo + " other";
</script>

The behavior speced for os:Var matches the behavior of javascript
variables, so this is not an implementation-driven decision, but one
modeled on existing behaviors in JavaScript, which will be familiar to
gadget developers.  If we adjust our thinking so that this is not so
much temporary variables as an alternate way of creating variables
within Data Context, this behavior is perfectly logical.

Sorry, I probably used the terms "temporary" and "transient" more loosely than I should have.

It's my belief that variables defined inside template blocks should not linger on after these blocks. I do realize this differs from how Javascript works, but there is an inherent difference between scripting and templating. The main reason for my preference is that I don't believe that rendering a template should in any way alter the application's DataContext. Enforcing this will prevent people from putting increasingly more logic into their templates, which will allow templates to be the View of te application (DataContext being the model, and JS being the controller).
 

WRT the behavior of markup, we can strike the text from the patch, but
that doesn't address how to handle markup within a variable - it
simply ignores the issue.  If the decision is to strip markup (like
accessing via innerText), how would you reconcile this behavior with
the behavior of referencing another variable that already has markup.

Ex:
contents of "some_url_to_html" = <h1>Hello world</h1>

<os:HttpRequest key="myfragment_key_is_long" format="text"
href="some_url_to_html" />
...
<os:Var key="kshort" value="${myfragment_key_is_long}" />
<os:Var key="kshort2"  /><h1>Hello world</h1></os:Var>


Given the above example, what would your expected outputs be on the
three variables.  My expectation is that they would all have identical
content.  Just because the same content is bounced from an external
server doesn't mean it should be mangled.  If instead we say that
os:Var strips all markup, then the behavior of using os:Var to create
shortened reference keys becomes broken (case "kshort").

Not having explicit behavior defined on many of these edge cases is
what makes 0.9 such a problematic spec - too much is left for
interpretation.  My preference is to define correct and sensible
behavior on the edge cases.

I don't think you understood me. I am proposing that for <os:Var>, the @value attribute be the only way to set the variable value.

So, in your example, the second <os:Var> statement would be an error (or NOOP), since it was missing a @value attribute.
It *could* be rewritten as

<os:Var key="kshort2" value="<h1>Hello world</h1>"/>
 
In which case the variable set would be the literal string with all HTML markup intact. However, to render out such a string properly using a template, you'd have to use <os:Html>, otherwise you would see all the angle brackets in your output.

So, I am proposing that any content between the opening and closing of the <os:Var> tags gets ignored, instead of being equivalent to the @value attribute. I don't see how this leads to any inconsistencies or uncertainty.

[goosemanjack]

I'd go ahead and edit the patch to remove the section stating that
variables exist across templates, as you've requested.

I'd rather not make only the attribute @value be the only way to
specify values. In cases of complex JSON, this will be difficult to
author for developers and difficult to read.

EX:

<os:Var key="myjson">
{
foo: ["one fish", "two fish", 'red fish', "blue fish"],
bar: {
first: "${firstEL}",
second: 2
}
}
</os:Var>


Rewritten using the @value syntax

<os:Var key="myjson" value="{foo: [\"one fish\", \"two fish\", 'red
fish', \"blue fish\"], bar: { first: \"${firstEL}\", second: 2}}" />


Since, as you acknowledge, the markup could be included within the
attribute value, eliminating use of the innerXML to define values is
not actually restricting values that can be placed in a variable. Any
markup has to be rendered with os:Html (when in html escaping mode),
so allowing this is not introducing any new behavior.
--
clc

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

[Evan Gilbert]

Evan, to your question about scoping the variable, I think your code
has errors in it.  My java chops aren't what they were a few years
ago, but in c# that sample code is going to generate a compile time
error.  Java and C# require explicit variable declaration and also
allow block-level scoping.

In your java example (assuming c# rule are the same as java):

int sum = 0;
for (int cur : integers)
 int sum = sum + cur;
}

You'll get a compilation error because you're redefining a variable in
a narrower scope.  If we eliminate the the "int sum =0;" that's above
the loop then you'll get the behavior I think you're going for, which
is the "sum" variable will fall out of scope outside the loop.

Yes, it will be a compilation error - that was the point I was trying to make :)

Multiple declaration statements in the same scope disallowed or strongly discouraged in almost all programming languages.

 

JavaScript, in turn, only allows scoping either at the global (window)
level or the function level.  Your example is written in a
particularly confusing way, but in all instances the "var sum"
statement is referring to the same variable.

var sum = 0;
for (var i = 0; i < integers.length; i++) {
 var sum = sum + integers[i];
}

I double checked it with this code and the answer is, in fact, 9 and
not 3 or 6.

Javascript allows this, but it's discouraged practice in almost every style guide, and many linters / compressors will show errors when using this.

It's confusing to have the bolded item below first refer to the upper variable and then to the previously set value of sum on the same line.

var sum = sum + integers[i]

 

function doit(){

 var integers=[1,2,3];

 var sum = 3;
 for (var i = 0; i < integers.length; i++) {
   var sum = sum + integers[i];
 }

 document.getElementById("answer").innerHTML=sum;
}

> (Evan)

> I looked through the example code again and realized that the proposed spec
> enhancement allows for declaring the same <os:Var> multiple times in a given
> scope.

The rules in the os:Var syntax are written to follow the JavaScript
scoping rules.  That means that if the given variable already exists
in given scope, it is used.  If it doesn't exist, it is created on
first reference.  Since the client-side execution will be in
JavaScript it seemed logical to follow the same scoping rules.  This
doesn't create any problems and actually reduces confusion since it
follows the same rules as JavaScript.

It seems like you're trying to use variable declaration to execute statements. 

You would normally not increment sum with a variable declaration - you would use a statement, i.e.

1. sum = sum + Cur,

     instead of

2. var sum = sum + Cur

I'd be surprised if any programming language supported #2 without supporting #1.

[Evan Gilbert]

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

I'd go ahead and edit the patch to remove the section stating that
variables exist across templates, as you've requested.

I'd rather not make only the attribute @value be the only way to
specify values.  In cases of complex JSON, this will be difficult to
author for developers and difficult to read.

EX:

<os:Var key="myjson">
{
 foo: ["one fish", "two fish", 'red fish', "blue fish"],
 bar: {
      first: "${firstEL}",
      second: 2
 }
}
</os:Var>

The JSON literal seems like a valuable addition.

I'd prefer to keep EL out of the tag - we're not going to have <os:Repeat> / <os:If> in these tags, and supporting only expressions seems to add complexity when evaluating without much value. If you want to keep EL in, providing use cases will help justify.

 

Rewritten using the @value syntax

<os:Var key="myjson" value="{foo: [\"one fish\", \"two fish\", 'red
fish', \"blue fish\"], bar: { first: \"${firstEL}\", second: 2}}" />


Since, as you acknowledge, the markup could be included within the
attribute value, eliminating use of the innerXML to define values is
not actually restricting values that can be placed in a variable.  Any
markup has to be rendered with os:Html (when in html escaping mode),
so allowing this is not introducing any new behavior.

I think you're correct that this would work, and I don't see any reason to prevent it.

However, Lev's point is important - I think this is usually a worse way to define HTML blobs:

- They will likely be subject to more stringent sanitization rules, as they are evaluated as data and not template content.

- They can't support OSML tags

- You have to write your HTML in a multi-line string.

I think there is alway a way to make the HTML part of the template content.

 

To unsubscribe from this group, send email to opensocial-and-gadg...@googlegroups.com.

[goosemanjack]

Perhaps we've chosen an improper name for the tag. We're modeling
it's behavior on behavior in JavaScript of variable and the <cfset>
tag from ColdFusion (http://livedocs.adobe.com/coldfusion/6.1/htmldocs/
tags-pc5.htm).

> Yes, it will be a compilation error - that was the point I was trying to
> make :)

OpenSocial gadgets don't necessarily have a compilation stage, so I
feel this is an inappropriate comparison to make. We view this entire
spec as functioning as a loosely-typed interpreted language. Imposing
strong typing rules found in compiled languages on this doesn't smell
right to me, given we have to support executing in a JavaScript
environment.

> You would normally not increment sum with a variable declaration - you would
> use a statement, i.e.

A more appropriate tag name might be <os:SetVar > for what we've
proposed. Perhaps that will remove some of the confusion, since the
intent is to set (and possible create) a variable, not declare a
variable for later use.
--
clc

> var sum = *sum *+ integers[i]

[Evan Gilbert]

On Wed, Dec 16, 2009 at 5:10 PM, goosemanjack <cc...@myspace.com> wrote:

Perhaps we've chosen an improper name for the tag.  We're modeling
it's behavior on behavior in JavaScript of variable and the <cfset>
tag from ColdFusion (http://livedocs.adobe.com/coldfusion/6.1/htmldocs/
tags-pc5.htm).

> Yes, it will be a compilation error - that was the point I was trying to
> make :)

OpenSocial gadgets don't necessarily have a compilation stage, so I
feel this is an inappropriate comparison to make.  We view this entire
spec as functioning as a loosely-typed interpreted language.  Imposing
strong typing rules found in compiled languages on this doesn't smell
right to me, given we have to support executing in a JavaScript
environment.

> You would normally not increment sum with a variable declaration - you would
> use a statement, i.e.

A more appropriate tag name might be <os:SetVar > for what we've
proposed.  Perhaps that will remove some of the confusion, since the
intent is to set (and possible create) a variable, not declare a
variable for later use.

Thanks for the clarification - this naming is much clearer in intent.

I think I'm still on the negative side for the functionality. My current leaning is:

+1 for <os:Var> with set once semantics and JSON literal support

-1 for <os:SetVar> for this spec iteration. Maybe MySpace can create a prototype of this for the next round of revisions?

Anyone else on the spec list interested in commenting? We only have three people on this thread.

Evan

--
clc

[goosemanjack]

Our prototype code doesn't become public until later this week, but
here's the sample gadget we're testing with and the rendered result:

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Sample os:Var Gadget
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++

<?xml version="1.0" encoding="utf-8"?>
<Module xmlns:os="http://ns.opensocial.org/2008/markup"
xmlns:myspace="http://ns.opensocial.org/2008/x" xmlns:my="http://
ns.opensocial.org/2008/z">
<ModulePrefs title="OsVar Test Gadget" description="Test cases on
osVar"
thumbnail=""
>
<Require feature="opensocial-0.9"/>
<Require feature="opensocial-templates"/>
<Require feature="opensocial-data"/>
</ModulePrefs>
<Content type="html" view="canvas">
<script type="text/os-data">
<os:ViewerRequest key='vwr' />
<os:PeopleRequest key='myfriends' userid="@viewer"
groupid="@friends" />
<os:Var key="dpVar" >I am registered with Data Pipeline</os:Var>
<os:Var key="jsonArrayVar" >[1,"one", "three"]</os:Var>
<os:Var key="jsonObjectVar" >{"id":'jsonId',"displayName":"faux
Person"}</os:Var>
</script>

<script type="text/os-template" tag="vartest:Embedded">
<div style="border:4px solid gray;padding:4px;margin:
10px;float:left;">
vartest:Embedded tag <br/>
<b>My.someVal:</b> ${My.someVal}
</div>
</script>

<script type="text/os-template" tag="vartest:InDefinition">
<os:Var key="altKey" >Built altKey contains someVal: ${My.someVal}</
os:Var>
<div style="border:4px solid red;padding:4px;margin:
10px;float:left;">
vartest:InDefinition tag <br/>
<b>altKey:</b> ${altKey}
</div>
</script>

<script type="text/os-template" tag="vartest:InDefinition2">
<os:Var key="altKey" >Built altKey contains someVal: ${My.someVal}</
os:Var>
<div style="border:4px solid orange;padding:4px;margin:
10px;float:left;">
vartest:InDefinition2 tag <br/>
<b>altKey:</b> ${My.altKey}
</div>
</script>

<script type="text/os-template">
<h1>os:Var Test Cases</h1>
<p>
Testing var "foo"
</p>
<p>Before set: ${foo}</p>
<os:Var key="foo" value="0" />
<p>Initial set: ${foo}</p>
<os:Var key="foo" >${foo + 1}</os:Var>
<p>Added one with EL: ${foo}</p>

<os:Var key="sum" value="0" />

<h3>Looping increment to sum</h3>
<os:Repeat expression="${Top.myfriends}">
<os:Var key="sum" value="${sum+1}" />
<div>
Item: ${Context.Index} is ${Cur.displayName}
</div>
</os:Repeat>
<p>Sum: ${sum}</p>

<hr />
<h2>Custom Tags</h2>
<vartest:Embedded someVal="Created with attr param" />
<vartest:Embedded >
<someVal>Created with Element Param</someVal>
</vartest:Embedded>

<vartest:Embedded >
<os:Var key="someVal">osVar registered value</os:Var>
</vartest:Embedded>

<br style="clear:both;" />

<vartest:InDefinition >
<os:Var key="someVal">Any value will do here</os:Var>
</vartest:InDefinition>

<vartest:InDefinition2 >
<os:Var key="someVal">Another value is good</os:Var>
</vartest:InDefinition2>

<br style="clear:both;" />
<p>Deregistered altKey (should be empty): <span id='afterDeregKey'>$
{altKey}</span></p>

<hr style="clear:left;" />
<h2>Data Pipeline variables</h2>
string: ${dpVar}

<hr />
<h2>Json Data</h2>

jsonArrayVar.length: ${jsonArrayVar.length} <br/>
jsonArrayVar[0]: ${jsonArrayVar[0]} <br/>
jsonArrayVar[1]: ${jsonArrayVar[1]} <br/>
jsonArrayVar[2]: ${jsonArrayVar[2]} <br/>

jsonObjectVar.length: ${jsonObjectVar.length} <br/>
jsonObjectVar.id: ${jsonObjectVar.id} <br/>
jsonObjectVar.displayName: ${jsonObjectVar.displayName} <br/>

<h4>Repeating Data</h4>
<b>jsonArrayVar</b>
<ul>
<li repeat="jsonArrayVar">${Cur}</li>
</ul>

<b>jsonObjectVar</b>
<ul>
<li repeat="jsonObjectVar">${Cur}</li>
</ul>

<script type="text/javascript">

function testKeyDeregistration(){
var el = document.getElementById("afterDeregKey");
if(el.innerHTML.length > 0){
el.style.backgroundColor="red";
el.style.color="white";
}
else{
el.style.backgroundColor="#CCFFCC;";
}
}

testKeyDeregistration();
</script>
</script>
</Content>
</Module>

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Rendered os:Var Gadget Result
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://
www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html><head><title>
OsVar Test Gadget
</title>
<!-- script snipped -->
<body >
<div class="xcontentblockview-canvas "
id="_osmlContentBlock_appid166877__osmlContentBlock_0">
<h1>os:Var Test Cases</h1>
<p>
Testing var "foo"
</p>
<p>Before set: </p>
<p>Initial set: 0</p>
<p>Added one with EL: 1</p>

<h3>Looping increment to sum</h3>
<div>
Item: 0 is Tom
</div>
<div>
Item: 1 is Rob Cooper
</div>
<div>
Item: 2 is Philadelphia
</div>
<div>
Item: 3 is annemarie
</div>
<div>
Item: 4 is WES AMC
</div>
<p>Sum: 5</p>

<hr />
<h2>Custom Tags</h2>
<div style="border:4px solid gray;padding:4px;margin:
10px;float:left;">
vartest:Embedded tag <br/>
<b>My.someVal:</b> Created with attr param
</div>
<div style="border:4px solid gray;padding:4px;margin:
10px;float:left;">
vartest:Embedded tag <br/>
<b>My.someVal:</b> Created with Element Param
</div>
<div style="border:4px solid gray;padding:4px;margin:
10px;float:left;">
vartest:Embedded tag <br/>
<b>My.someVal:</b> osVar registered value
</div>
<br style="clear:both;" />

<div style="border:4px solid red;padding:4px;margin:10px;float:left;">
vartest:InDefinition tag <br/>
<b>altKey:</b> Built altKey contains someVal: Any value will do here
</div>
<div style="border:4px solid orange;padding:4px;margin:
10px;float:left;">
vartest:InDefinition2 tag <br/>
<b>altKey:</b> Built altKey contains someVal: Another value is good
</div>
<br style="clear:both;" />
<p>Deregistered altKey (should be empty): <span id='afterDeregKey'></
span></p>

<hr style="clear:left;" />
<h2>Data Pipeline variables</h2>
string: I am registered with Data Pipeline

<hr />
<h2>Json Data</h2>

jsonArrayVar.length: 3 <br/>
jsonArrayVar[0]: 1 <br/>
jsonArrayVar[1]: one <br/>
jsonArrayVar[2]: three <br/>

jsonObjectVar.length: 2 <br/>
jsonObjectVar.id: jsonId <br/>
jsonObjectVar.displayName: faux Person <br/>

<h4>Repeating Data</h4>
<b>jsonArrayVar</b>
<ul>
<li>1</li><li>one</li><li>three</li></ul>

<b>jsonObjectVar</b>
<ul>
<li>[id, jsonId]</li><li>[displayName, faux Person]</li></ul>

<script type="text/javascript">

function testKeyDeregistration(){
var el = document.getElementById("afterDeregKey");
if(el.innerHTML.length > 0){
el.style.backgroundColor="red";
el.style.color="white";
}
else{
el.style.backgroundColor="#CCFFCC;";
}
}

testKeyDeregistration();
</script>

</div>
<script type="text/javascript" >
//<![CDATA[
/*
opensocial.data.getDataContext().putDataSet("vwr",
{"displayName":"joe","hasApp":"true","id":"myspace.com.person.
26000001","msUserType":"RegularUser"});
opensocial.data.getDataContext().putDataSet("myfriends", {"snip"});
opensocial.data.getDataContext().putDataSet("dpVar", "I am registered
with Data Pipeline");
opensocial.data.getDataContext().putDataSet("jsonArrayVar",
"MySpace.DataPipeline.JsonData");
opensocial.data.getDataContext().putDataSet("jsonObjectVar",
"MySpace.DataPipeline.JsonData");
opensocial.data.getDataContext().putDataSet("foo", "1");
opensocial.data.getDataContext().putDataSet("sum", "5");

gadgets.util.registerOnLoadHandler(function(){
MyOpenSpace.ClientRequestProcessor.resolveRequests();
});
*/
//]]>
</script>
<script type="text/javascript" >
//<![CDATA[
/*
opensocial.template._rawTemplates = [];
MyOpenSpace.template.TemplateProcessor.templatesXml
["vartest:Embedded"] = "<Template xmlns:os=\"http://opensocial.org/
templates\" xmlns:vartest=\"http://opensocial.org/templates\">\n<div
style=\"border:4px solid gray;padding:4px;margin:10px;float:left;\">
\nvartest:Embedded tag <br/>\n<b>My.someVal:</b> ${My.someVal}\n</div>
\n </Template>";
MyOpenSpace.template.TemplateProcessor.templatesXml
["vartest:InDefinition"] = "<Template xmlns:os=\"http://opensocial.org/
templates\" xmlns:vartest=\"http://opensocial.org/templates\">\n
<os:Var key=\"altKey\" >Built altKey contains someVal: ${My.someVal}</
os:Var>\n <div style=\"border:4px solid red;padding:4px;margin:
10px;float:left;\">\n vartest:InDefinition tag <br/>\n <b>altKey:</b> $
{altKey}\n </div>\n</Template>";
MyOpenSpace.template.TemplateProcessor.templatesXml
["vartest:InDefinition2"] = "<Template xmlns:os=\"http://
opensocial.org/templates\" xmlns:vartest=\"http://opensocial.org/
templates\">\n <os:Var key=\"altKey\" >Built altKey contains someVal: $
{My.someVal}</os:Var>\n <div style=\"border:4px solid orange;padding:
4px;margin:10px;float:left;\">\n vartest:InDefinition2 tag <br/>\n
<b>altKey:</b> ${My.altKey}\n </div>\n</Template>";
*/
//]]>
</script>
</body></html>

[Evan Gilbert]

Overall looks good, few notes:

<vartest:Embedded><os:Var key="someVal">osVar registered value</os:Var></vartest:Embedded> -> depends on discussions around Clarify Custom Tag Parameter Behavior

<os:Var key="sum" value="${sum+1}"/> -> this is now undefined behavior

jsonArrayVar.length: ${jsonArrayVar.length},  jsonObjectVar.length: ${jsonObjectVar.length} -> I don't think length is currently defined for objects and arrays. This seems like a useful addition (definitely for arrays, more possibility of naming conflicts on objects), but don't think it's in the spec.

[goosemanjack]

One of the most important items that came out of the discussion, even
more so than behavior, was the need to settle on a tag name to move
forward with before implementation splinter this tag name.

Possible Values:

os:Var (currently proposed)

os:SetVar (alternate one)

os:Set (alternate two - this aligns with cf:set found in
ColdFusion, which this proposal was somewhat modelled on)

Evan, you seem to feel farily strongly that "os:Var" has connotations
of variable declaration, but not (re)assignment. We feel variable
reassignment is an important behavior, even if it's left out of this
round of the spec, and both declaration and assignment should all be
handled by a single tag.

From my perspective, os:SetVar is a horribly clunky name and should be
rejected out of hand. That leaves us with os:Var or os:Set. If we
can get some quick votes from the people following this thread, I'll
update the patch with the next version.

Also, I think we're all getting spec fatigue. I believe the only two
remaining contentious issues are: os:Var behavior as a parameter to a
custom tag instance, and the treatment of markup with os:Var. Would
everyone be comfortable with simply striking these sections from the
proposal and leaving the behavior in these situations undefined for
this round of the spec?
--
clc

> ...
>
> read more »

[Evan Gilbert]

+1 on <os:Var>

+1 also on leaving a few items undefined. This is not ideal, but I agree that we're at risk of these issues dragging on and holding up our 1.0 release for what are fairly small clarifications in the scope of the overall spec.

Evan

[Lev Epshteyn]

I'm generally in favor of omitting some things to get us unblocked, though I'd like to see the actual patch to vote on it.

Do we need to have a conference call today? I recall we scheduled it for 2pm EST last week.

[Lev Epshteyn]

Just looked through all the threads, and it seems like we're approaching consensus on all the issues that were under discussion. In light of this, I don't think we need to have a conference call today - rather, as the next step, we should get an updated set of proposals with the agreed upon changes, so that we can vote on them.

[Lane LiaBraaten]

Please commit these changes to svn so we can publish RC1 at EOD today.  If there are particular sections you want to call out for extra attention during review, use 

<x:draft note="Describe why this section needs special attention" href="http:// 
example.com"> 
 ... 
</x:draft> 

Thanks,

Lane

[1] http://wiki.opensocial.org/index.php?title=Spec_Changes#Propose_and_agree_on_timeline

[goosemanjack]

I'm not currently a committer on the project. I'll need you to either
add me in as a committer or handle the commit for me.

On Jan 11, 10:02 am, Lane LiaBraaten <lliab...@google.com> wrote:
> Please commit these changes to svn so we can publish RC1 at EOD today.  If
> there are particular sections you want to call out for extra attention
> during review, use
>
> <x:draft note="Describe why this section needs special attention"
> href="http://
> example.com">
>  ...
> </x:draft>
>
> Thanks,
> Lane
>

> [1]http://wiki.opensocial.org/index.php?title=Spec_Changes#Propose_and_a...

> ...
>
> read more »

[Lane LiaBraaten]

Hi Chris - I've added your @myspace.com account as a committer...let me know if you'd rather use a different account.

Thanks,

Lane

[Mark W.]

Lane,
Do you need some help getting RC1 out?
-Mark W.

On Jan 11, 1:02 pm, Lane LiaBraaten <lliab...@google.com> wrote:
> Please commit these changes to svn so we can publish RC1 at EOD today.  If
> there are particular sections you want to call out for extra attention
> during review, use
>
> <x:draft note="Describe why this section needs special attention"
> href="http://
> example.com">
>  ...
> </x:draft>
>
> Thanks,
> Lane
>

> [1]http://wiki.opensocial.org/index.php?title=Spec_Changes#Propose_and_a...

> ...
>
> read more »

[Lane LiaBraaten]

On Tue, Jan 12, 2010 at 5:29 AM, Mark W. <weit...@us.ibm.com> wrote:

Lane,
Do you need some help getting RC1 out?

Once Chris and Tim submit their patches I'll post RC1 on opensocial.org.

-Lane

 

[goosemanjack]

Could you associate the gmail.com account (goosemanjack). On that one
I actually remember the password.

> ...
>
> read more »

[Lane LiaBraaten]

Looks like I actually did do the gmail.com account.

You can find you googlecode.com password (i.e. the one you need to checkout the repo in read/write mode) here: https://code.google.com/hosting/settings

-Lane

[goosemanjack]

Committed patch w/ modifications discussed (leaving contentious
behavior undefined).
--
clc

> ...
>
> read more »

[goosemanjack]

In reviewing some comments from Lev re: cross reference to core gadget
spec from template, would it make sense to move the bulk of the os:Var
tag into the data pipeline section in the core-gadget spec? I'll
prepare a patch for this shortly so people can review.
--
clc

> ...
>
> read more »