At the moment, two views with mismatched types (e.g. see below) do not produce a parse error. After my changes are submitted, it will produce an error:
Example of what should produce an error but doesn't yet: <Content view="maximized" type="url" src=" http://yyy.com/type-url-gadget.xml";></Content> <Content view="maximized" type="html">YYY</Content> On Feb 16, 2008 5:52 PM, <[EMAIL PROTECTED]> wrote: > yes, and I think ultimately this is what the spec should say as well, > since nothing else makes much sense. > > On 2/16/08, David Glazer <[EMAIL PROTECTED]> wrote: > > That makes sense for well-formed gadgets. > > > > The corner case I was asking about is when the XML asks for > concatenation of > > sections, at least one of which is type=url. Specifically, in your > example, > > consider appending either: > > <Content type="url" view="maximized" src=" > > http://yyy.com/type-url-gadget.xml <http://x.com/type-url-gadget.xml> > > "></Content> > > or: > > <Content type="html" view="maximized">YYY</Content> > > > > I believe either of those should result in parse errors. Is that right? > > > > - dG > > > > > > On Sat, Feb 16, 2008 at 4:39 PM, Bruno Bowden <[EMAIL PROTECTED]> wrote: > > > > > You're correct that for a type="url" view, the Content section is > empty > > > and > > > no concatention is done. Consider the case where the gadget has a > mixture > > > of > > > type="url" and type="html" Content sections. Then concatenation is > done > > > for > > > the HTML views and is ignored for the URL views. > > > > > > Say for example that you have 3 views: mobile, profile, maximized. > > > Consider > > > the case where you wanted to share content between the mobile / > profile > > > views and use a small amount of CSS to style them differently. Then > > > finally > > > use type=url for maximized to give yourself more flexibility by > accessing > > > your own srever directly. Here's how you could write the gadget: > > > > > > <?xml version="1.0"?> > > > <Module> > > > <ModulePrefs title="Title"/>" + > > > <Content type="html" view="mobile"> > > > MobileCSS > > > </Content> > > > <Content type="html" view="profile"> > > > ProfileCSS > > > </Content> > > > <Content type="html" view="mobile,profile"> > > > SharedHTML > > > </Content> > > > <Content type="url" view="maximized" src=" > > > http://x.com/type-url-gadget.xml > > > "></Content> > > > </Module> > > > > > > The Output of the Gadget Render is different for each view. Here's > what it > > > would be: > > > > > > Mobile view = MobileCSS + SharedHTML > > > Profile view = ProfileCSS + SharedHTML > > > Maximized view = <iframe src="http://x.com/type-url-gadget.xml > "></iframe> > > > > > > > > > On Feb 16, 2008 3:41 PM, David Glazer <[EMAIL PROTECTED]> wrote: > > > > > > > I'm confused -- don't type=url gadgets have empty <Content> > sections? > > > If > > > > so, it seems like concatenating them wouldn't make any sense. Maybe > we > > > > should only support Content-concatenation if they're all type=html, > and > > > > just > > > > return a not_parseable error if any of them are type=url? > > > > > > > > On Sat, Feb 16, 2008 at 3:31 PM, Bruno Bowden <[EMAIL PROTECTED]> > wrote: > > > > > > > > > On Feb 16, 2008 4:38 AM, Chris Chabot <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > 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> > > > > > > > > > > > > > > > I was thinking yesterday "How long before someone wants to use > > > type=html > > > > > content for the profile and type=url for maximized mode?". Guess > > > you've > > > > > answered my question. > > > > > > > > > > The patch that I'm writing works just as Kevin described it. The > only > > > > > difference is that in my case, the winning attribute, is the first > one > > > > > associated with the view, not the last. This is equivalent > > > functionality > > > > - > > > > > I > > > > > can't think of scenario where one is much better than the other. > Since > > > > you > > > > > read the spec usually in order, it seems natural to look for the > first > > > > > instance rather than have to read backwards to find the > controlling > > > > > attribute. I'm open to suggestions on changing it. > > > > > > > > > > > > > > > > > -- > ~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. >
