The current behavior is incorrect -- these are relatively new additions to
the spec however, and concatenation was something that went in at the last
minute. John H. submitted the patch to support the concatenation and it was
done it a bit of a rush.
As it turns out, Bruno Bowden (a non-committer Googler who has submitted a
few patches in the past) has volunteered to update gadget spec / gadget spec
parser / etc. to instead manage a map of view -> content sections. It'll
look something like this:
view-name : {
content: "concatenated content for all sections matching this view",
type: "type attribute*"
href : "href attribute*"
quirks: "quirks attribute (proposed in spec discussion group) *"
...any new attributes that are added in the future...
}
* When there's a conflict in the attributes between amongst concatenated
content sections using the same view, the last declared one wins. The spec
is currently silent on what the correct behavior is under this scenerio, but
this seems like the only sensible solution and it is what we will most
likely present to the spec discussion group as our proposal for resolving
this ambiguity.
When he's got a patch ready, I've asked him to go ahead and submit a JIRA
ticket. We should be seeing this update relatively soon.
On Feb 16, 2008 4:38 AM, Chris Chabot <[EMAIL PROTECTED]> wrote:
> Hey Guys,
>
> While working on a php port of the java shindig version, i noticed
> that in ParsedGadgetSpec, it supports having a <Content> block per
> view., and it stores the content data in an map with a [view name] =>
> [content data or contentHref] relationship.
>
> It also supports a content type, either html or url based.
>
> However if shindig / opensocial supports those 2 things, you would
> expect as a gadget writer that you could mix those 2 types (html and
> url), and have a url block for say 'default', and a html content block
> for <whatever views will be defined by the social gadget spec>
>
> However looking at the code, it stores the its contentType and
> contentHref in single vars, which is overwritten every time by
> processContent(). So it assumes that the last content type and/or href
> it sees in the xml document is the contentType and contentHref for
> every view, thus making it impossible to mixing multiple type's in a
> gadget, and impossible to use the multiple view support with anything
> but <Content type="html" /> blocks.
>
> Is this intended and will-be-documented behavior or, as i suspect, a
> bug?
>
> oh ps, i also noticed in the GadgetSpecParser that it's perfectly ok
> with having a gadget xml document without any <Content> blocks ... was
> wondering if that was intended, or if maybe that should throw an
> SpecParserException too.
>
> Thanks,
>
> -- Chris
>
--
~Kevin
If you received this email by mistake, please delete it, cancel your mail
account, destroy your hard drive, silence any witnesses, and burn down the
building that you're in.
