Proposal for 1.0: Deprecate DataAttribute definition of cur outside repeaters

[goosemanjack]

Synopsis:

The DataAttribute section that allows definition of @cur within an
arbitrary element outside the scope of repeaters should be deprecated
from the spec as it creates confusion as to the meaning of cur without
creating any value.


The definition of a DataAttribute in section 8.5 of the Template spec
appears to be simply a scoping convenience that can be achieved
through other means already.

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

(example from spec)
<div cur="${Friends[0]}">
<div repeat="${Interests}">
${Title}
</div>
</div>

This syntax only serves to create confusion, both as to the meaning of
the ${Cur} variable and to scoping precedence of the EL variable. The
code can easily be rewritten as below with more obvious results:

<div>
<div repeat="${Friends[0].Interests}">
${Title}
</div>
</div>

The section defining DataAttributes should be deprecated from the
spec.

[Adam Winer]

Yes, this example can be rewritten, but only because it's an
excessively simple example that uses ${Friends[0]} once. It's only
useful if you need the aliasing repeatedly.

I'm fine with deprecating @cur, but only if we add support for os:Var.
Aliasing is important, and @cur is all we have in OST.

[goosemanjack]

I'm all for bringing os:Var back to the table. If anyone can find the
original proposal thread, please forward. I'll work up an updated re-
proposal of os:Var and post to the group.

On Oct 8, 5:07 pm, Adam Winer <awi...@gmail.com> wrote:
> On Thu, Oct 8, 2009 at 4:52 PM, goosemanjack <cc...@myspace.com> wrote:
>
> > Synopsis:
>
> > The DataAttribute section that allows definition of @cur within an
> > arbitrary element outside the scope of repeaters should be deprecated
> > from the spec as it creates confusion as to the meaning of cur without
> > creating any value.
>
> > The definition of a DataAttribute in section 8.5 of the Template spec
> > appears to be simply a scoping convenience that can be achieved
> > through other means already.
>

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

[Evan Gilbert]

The syntactical convenience of @cur is worth keeping. Here's a really simple address widget...

1. Without @cur

<div style="addresswidget">

  <div if="${User.Address.Line1}">${User.Address.Line1}</div>

  <div if="${User.Address.Line2}">${User.Address.Line2}</div>
  <div if="${User.Address.City || $User.Address.State}">${User.Address.City}<span if="${User.Address.State}">, </span>${User.Address.State}</div>

  <div if="${User.Address.Zip}">${User.Address.Zip}</div>

</div>

2. With @cur

<div style="addresswidget" cur="${User.Address}">

  <div if="${Line1}">${Line1}</div>

  <div if="${Line2}">${Line2}</div>

  <div if="${City || $State}">${City}<span if="${State}">, </span>${State}</div>

  <div if="${Zip}">${Zip}</div>

</div>

#2 is also nice because you can already get this syntactical convenience in a loop (<div repeat="${User.Addresses}">), and it seems odd to only allow it for repeated elements.

<os:Var> would be a nice addition (please make it immutable once set), but I don't think it replaces the need for @cur

--

[Lane LiaBraaten]

There's a wiki page with related information:

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

However, this is out of scope for this iteration as it's a functional change and we're focusing on cleanup and extensions.

-Lane

On Fri, Oct 9, 2009 at 4:21 AM, goosemanjack <cc...@myspace.com> wrote:

[Lev Epshteyn]

+1 on revisiting this when adding <os:Var> functionality to the spec.

[goosemanjack]

I edited the wiki page to clarify some points and add an Array
definition syntax. I also brought it back in scope on the spec
changes page:
http://wiki.opensocial.org/index.php?title=Spec_Changes#Current_Status_At_a_Glance

Lane, I put you down as the owner of this item. LMK if you don't want
to own it. I started a new thread on os:Variable to split the
discussion between these two items:

http://groups.google.com/group/opensocial-and-gadgets-spec/browse_thread/thread/8b0e50a2a429f44b?hl=en

On Oct 11, 8:56 pm, Lev Epshteyn <le...@google.com> wrote:
> +1 on revisiting this when adding <os:Var> functionality to the spec.
>

> On Fri, Oct 9, 2009 at 11:46 AM, Lane LiaBraaten <lliab...@google.com>wrote:
>
> > There's a wiki page with related information:
>

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

[Lane LiaBraaten]

As this proposal begins with "A new element <os:Variable> is added" I think it is out of scope for this iteration.  I would rather see os:Variable evolve as an extension so we can tweak things like the attribute list/values based on developer feedback, and do it outside the spec iteration timelines.

-Lane

[Lane]

And from this thread, it doesn't look like we can deprecate Cur
outside of repeaters without the os:Var stuff.

-Lane

On Oct 13, 10:20 am, Lane LiaBraaten <lliab...@google.com> wrote:
> As this proposal begins with "A new element <os:Variable> is added" I think
> it is out of scope for this iteration.  I would rather see os:Variable
> evolve as an extension so we can tweak things like the attribute list/values
> based on developer feedback, and do it outside the spec iteration timelines.
>
> -Lane
>
> On Mon, Oct 12, 2009 at 10:56 AM, goosemanjack <cc...@myspace.com> wrote:
>
> > I edited the wiki page to clarify some points and add an Array
> > definition syntax.  I also brought it back in scope on the spec
> > changes page:
>

> >http://wiki.opensocial.org/index.php?title=Spec_Changes#Current_Statu...

>
> > Lane, I put you down as the owner of this item.  LMK if you don't want
> > to own it.  I started a new thread on os:Variable to split the
> > discussion between these two items:
>

> >http://groups.google.com/group/opensocial-and-gadgets-spec/browse_thr...

[goosemanjack]

Is everyone OK with the idea that this _will be_ marked for
deprecation? If not there are a slew of scoping issues that this
creates WRT how the collisions between cur above, inside and below the
repeater will behave.

Because of all these scoping issues MySpace will not support
DataAttribute rather than try to work them out in the spec list, given
that data attribute will be eclipsed by os:Var.

Also, I'd like the spec group to reconsider the hard line on not
adding anything new this round (esp os:Var). We have found the
current spec unworkable in a number of areas and are hesitant to
consider this a candidate for 1.0 designation if all that's being
allowed is minor wording tweaks.
--
clc

[Lane LiaBraaten]

On Tue, Oct 13, 2009 at 11:33 AM, goosemanjack <cc...@myspace.com> wrote:

Is everyone OK with the idea that this _will be_ marked for
deprecation?  If not there are a slew of scoping issues that this
creates WRT how the collisions between cur above, inside and below the
repeater will behave.

Because of all these scoping issues MySpace will not support
DataAttribute rather than try to work them out in the spec list, given
that data attribute will be eclipsed by os:Var.

Also, I'd like the spec group to reconsider the hard line on not
adding anything new this round (esp os:Var).  We have found the
current spec unworkable in a number of areas and are hesitant to
consider this a candidate for 1.0 designation if all that's being
allowed is minor wording tweaks.

Sounds like there's a misunderstanding about this "hard line".  If you look at the current list of proposals in scope [1] you'll find much more than wording tweaks.  There are some places were functional changes will be required to resolve conflicts within the spec. 

I agree that the os:Var tag does address a shortcoming in the spec, but I'm not convinced that the existing proposal is the best solution.  To be convinced, I'd like to see it implemented by containers, used by developers, and, if necessary, iterated on by the community.  This is the whole point of the extensions proposal is at the center of this iteration, and it seems unwise to violate this new principle in the very iteration we adopt it.

-Lane

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

[Evan Gilbert]

On Tue, Oct 13, 2009 at 11:33 AM, goosemanjack <cc...@myspace.com> wrote:

Is everyone OK with the idea that this _will be_ marked for
deprecation?  If not there are a slew of scoping issues that this
creates WRT how the collisions between cur above, inside and below the
repeater will behave.

As mentioned above, I think there's value in @cur.

And I I don't see how supporting @cur is harder than supporting setting the ${Cur} value in repeated fields.

Using @repeat instead is possible, but a bit confusing when you only have one field.