Simple Gadget format - Proposal for 2.0
35 views
Skip to first unread message
goosemanjack
Jan 21, 2011, 8:30:26 PM1/21/11
to OpenSocial and Gadgets Specification Discussion
Proposes allowing for a simplified gadget format as an optional
format.
http://docs.opensocial.org/display/OSD/Simple+Gadget+Format
This proposal is to allow for simpler gadgets to handle trivial use
cases. It also allows for ignoring the <script type="text/os-
template"> and <script type="text/os-data" > tags. Inline templates
may be authored using the same tag format as external template
libraries.
This will enhance the ability of gadgets (esp inline gadgets) to be
used to compose trivial or minor components of a larger site.
format.
http://docs.opensocial.org/display/OSD/Simple+Gadget+Format
This proposal is to allow for simpler gadgets to handle trivial use
cases. It also allows for ignoring the <script type="text/os-
template"> and <script type="text/os-data" > tags. Inline templates
may be authored using the same tag format as external template
libraries.
This will enhance the ability of gadgets (esp inline gadgets) to be
used to compose trivial or minor components of a larger site.
Matthew Marum
Jan 24, 2011, 11:11:55 AM1/24/11
to opensocial-an...@googlegroups.com
I've got a question about the part where you mention that the container "may infer what features are required."
Could you explain a bit how you think that might work? Search the content section for known functions?
Matt
Could you explain a bit how you think that might work? Search the content section for known functions?
Matt
goosemanjack
Jan 24, 2011, 4:00:31 PM1/24/11
to OpenSocial and Gadgets Specification Discussion
The one obvious feature that comes to mind would be "os-templates".
OSML template is optional and I believe Shindig eliminates the
template client support if templates are not requested (at least there
was talk of that). It would work by inferring that the templates
feature was needed if a <Templates> section was found in the gadget
XML file.
--
clc
OSML template is optional and I believe Shindig eliminates the
template client support if templates are not requested (at least there
was talk of that). It would work by inferring that the templates
feature was needed if a <Templates> section was found in the gadget
XML file.
--
clc
Mark W.
Jan 25, 2011, 12:36:06 AM1/25/11
to opensocial-an...@googlegroups.com
Chris,
This is actually pretty interesting. There's been some thought around an embedded experience that Ryan and folks are looking at. Do you think there is any overlap? That is, could an embedded experience take the format of one of these light weight gadgets?
The embedded experience use case is very very cool. I'm just concerned about it getting overly complex & maybe this is a way to simplify it.
This is actually pretty interesting. There's been some thought around an embedded experience that Ryan and folks are looking at. Do you think there is any overlap? That is, could an embedded experience take the format of one of these light weight gadgets?
The embedded experience use case is very very cool. I'm just concerned about it getting overly complex & maybe this is a way to simplify it.
rbaxter85
Jan 26, 2011, 8:47:12 AM1/26/11
to OpenSocial and Gadgets Specification Discussion
Mark, embedded experiences could display a "simplified gadget" as
well. You should be able to embed any kind of gaget that is supported
by the gadget definition. I would like to hear more about why you
think the proposal is overly complicated, and what parts are to
complex....probably best to move that conversation over to the
embedded experiences thread.
well. You should be able to embed any kind of gaget that is supported
by the gadget definition. I would like to hear more about why you
think the proposal is overly complicated, and what parts are to
complex....probably best to move that conversation over to the
embedded experiences thread.
Tim Wintle
Jan 26, 2011, 10:28:27 AM1/26/11
to opensocial-an...@googlegroups.com
On Fri, 2011-01-21 at 17:30 -0800, goosemanjack wrote:
> http://docs.opensocial.org/display/OSD/Simple+Gadget+Format
> http://docs.opensocial.org/display/OSD/Simple+Gadget+Format
I'm confused about the use case for this gadget format. Besides the
format being a little less verbose, I'm not sure what it adds.
(I may not be fully understanding the comment about os-templating as I
primarily use the gadgetspec, and don't use OS templates)
Is the suggestion that containers should support this format in addition
to the standard gadget format, or that containers can support either
format?
Thanks,
Tim Wintle
goosemanjack
Feb 3, 2011, 7:47:03 PM2/3/11
to OpenSocial and Gadgets Specification Discussion
The main use-case is making gadgets more friendly as a general purpose
component model for composing sites. Along the way we're righting
some syntactic wrongs as well.
Use Case: (Assume that inline gadgets from trusted sources are being
allowed)
For trivial use cases where gadgets are being used to compose a larger
site experience, a lot of the cruft in ModulePrefs is simply not
needed. The containing site can make assumptions about the gadget
code being run because the pool of allowed gadgets are under strict
control, so many of the feature directive are not necessary.
The other thing being done in this proposal is providing a single
universal format for template definition and allowing for not using of
<script> tags for data tags and templates.
In the spec, you can see two formats called out for template
definition - one inline and one for external template libraries. This
would allow for the canonical format to be used universally.
http://opensocial-resources.googlecode.com/svn/spec/1.1/OpenSocial-Templating.xml#rfc.section.4
http://opensocial-resources.googlecode.com/svn/spec/1.1/OpenSocial-Templating.xml#rfc.section.15
Use of the <script > tags for both data and inline templates goes back
to an initial attempt by the Shindig team to implement a wholly client-
side OSML and data pipelining processor. That attempt failed, but not
before use of the <script type="text/os-template"> and <script
type="text/os-data"> tags were codified into the spec. Script tags
were used because they were the only tags where the browser wouldn't
render the internal contents prior to the client-side processor
engaging.
The simple gadget proposal supplements the obtuse use of <script> tags
with the more obvious and canonical <Template> and <Data> blocks.
At this point my position WRT support is containers MUST support the
existing 1.0 gadget format and SHOULD support the simple gadget format
as well.
--
clc
component model for composing sites. Along the way we're righting
some syntactic wrongs as well.
Use Case: (Assume that inline gadgets from trusted sources are being
allowed)
For trivial use cases where gadgets are being used to compose a larger
site experience, a lot of the cruft in ModulePrefs is simply not
needed. The containing site can make assumptions about the gadget
code being run because the pool of allowed gadgets are under strict
control, so many of the feature directive are not necessary.
The other thing being done in this proposal is providing a single
universal format for template definition and allowing for not using of
<script> tags for data tags and templates.
In the spec, you can see two formats called out for template
definition - one inline and one for external template libraries. This
would allow for the canonical format to be used universally.
http://opensocial-resources.googlecode.com/svn/spec/1.1/OpenSocial-Templating.xml#rfc.section.4
http://opensocial-resources.googlecode.com/svn/spec/1.1/OpenSocial-Templating.xml#rfc.section.15
Use of the <script > tags for both data and inline templates goes back
to an initial attempt by the Shindig team to implement a wholly client-
side OSML and data pipelining processor. That attempt failed, but not
before use of the <script type="text/os-template"> and <script
type="text/os-data"> tags were codified into the spec. Script tags
were used because they were the only tags where the browser wouldn't
render the internal contents prior to the client-side processor
engaging.
The simple gadget proposal supplements the obtuse use of <script> tags
with the more obvious and canonical <Template> and <Data> blocks.
At this point my position WRT support is containers MUST support the
existing 1.0 gadget format and SHOULD support the simple gadget format
as well.
--
clc
goosemanjack
Mar 29, 2011, 6:25:29 PM3/29/11
to OpenSocial and Gadgets Specification Discussion
I have a running sample posted using the Negroni codebase. You can
view it below:
http://opensocial.slob.com/Editor.aspx
This includes two trivial samples that define variable, custom tag
template, and render content. The simple gadget format results in a
40% reduction in the size of the gadget, a 30% reduction in LOC, and
IMO is much easier to understand.
Please feel free to play around with the editor. Note that only
<os:Var> is supported currently for data tags, but you can use this to
mock any other data you might expect to access.
I'll work on a spec patch in the coming week.
--
clc
On Feb 3, 5:47 pm, goosemanjack <cc...@myspace.com> wrote:
> The main use-case is making gadgets more friendly as a general purpose
> component model for composing sites. Along the way we're righting
> some syntactic wrongs as well.
>
> Use Case: (Assume that inline gadgets from trusted sources are being
> allowed)
> For trivial use cases where gadgets are being used to compose a larger
> site experience, a lot of the cruft in ModulePrefs is simply not
> needed. The containing site can make assumptions about the gadget
> code being run because the pool of allowed gadgets are under strict
> control, so many of the feature directive are not necessary.
>
> The other thing being done in this proposal is providing a single
> universal format for template definition and allowing for not using of
> <script> tags for data tags and templates.
>
> In the spec, you can see two formats called out for template
> definition - one inline and one for external template libraries. This
> would allow for the canonical format to be used universally.
>
> http://opensocial-resources.googlecode.com/svn/spec/1.1/OpenSocial-Te...http://opensocial-resources.googlecode.com/svn/spec/1.1/OpenSocial-Te...
view it below:
http://opensocial.slob.com/Editor.aspx
This includes two trivial samples that define variable, custom tag
template, and render content. The simple gadget format results in a
40% reduction in the size of the gadget, a 30% reduction in LOC, and
IMO is much easier to understand.
Please feel free to play around with the editor. Note that only
<os:Var> is supported currently for data tags, but you can use this to
mock any other data you might expect to access.
I'll work on a spec patch in the coming week.
--
clc
On Feb 3, 5:47 pm, goosemanjack <cc...@myspace.com> wrote:
> The main use-case is making gadgets more friendly as a general purpose
> component model for composing sites. Along the way we're righting
> some syntactic wrongs as well.
>
> Use Case: (Assume that inline gadgets from trusted sources are being
> allowed)
> For trivial use cases where gadgets are being used to compose a larger
> site experience, a lot of the cruft in ModulePrefs is simply not
> needed. The containing site can make assumptions about the gadget
> code being run because the pool of allowed gadgets are under strict
> control, so many of the feature directive are not necessary.
>
> The other thing being done in this proposal is providing a single
> universal format for template definition and allowing for not using of
> <script> tags for data tags and templates.
>
> In the spec, you can see two formats called out for template
> definition - one inline and one for external template libraries. This
> would allow for the canonical format to be used universally.
>
goosemanjack
Apr 4, 2011, 3:42:19 PM4/4/11
to OpenSocial and Gadgets Specification Discussion
Patch created and applied to spec with x:draft tags.
(Vote)
http://code.google.com/p/opensocial-resources/source/detail?r=1371
(Patch issue)
http://code.google.com/p/opensocial-resources/issues/detail?id=1162
> >http://opensocial-resources.googlecode.com/svn/spec/1.1/OpenSocial-Te......
(Vote)
http://code.google.com/p/opensocial-resources/source/detail?r=1371
(Patch issue)
http://code.google.com/p/opensocial-resources/issues/detail?id=1162
Mark W.
Apr 8, 2011, 1:00:26 AM4/8/11
to opensocial-an...@googlegroups.com
Chris,
I'll take the time to review this, but I think I'd also benefit from the type of conversation we had today. Can we tee this up on next week's call?
goosemanjack
Apr 11, 2011, 1:46:49 PM4/11/11
to OpenSocial and Gadgets Specification Discussion
Yes, let's add it to the agenda.
--
clc
--
clc
Reply all
Reply to author
Forward
0 new messages