You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Chris Chabot <ch...@xs4all.nl> on 2008/02/16 13:38:30 UTC
GadgetSpecParser - bug in content type / href / data per view?
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
Re: GadgetSpecParser - bug in content type / href / data per view?
Posted by Bruno Bowden <br...@google.com>.
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, <et...@google.com> 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 <dg...@google.com> 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 <br...@google.com> 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 <dg...@google.com> 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 <br...@google.com>
> wrote:
> > > >
> > > > > On Feb 16, 2008 4:38 AM, Chris Chabot <ch...@xs4all.nl> 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.
>
Re: GadgetSpecParser - bug in content type / href / data per view?
Posted by et...@google.com.
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 <dg...@google.com> 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 <br...@google.com> 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 <dg...@google.com> 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 <br...@google.com> wrote:
> > >
> > > > On Feb 16, 2008 4:38 AM, Chris Chabot <ch...@xs4all.nl> 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.
Re: GadgetSpecParser - bug in content type / href / data per view?
Posted by David Glazer <dg...@google.com>.
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 <br...@google.com> 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 <dg...@google.com> 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 <br...@google.com> wrote:
> >
> > > On Feb 16, 2008 4:38 AM, Chris Chabot <ch...@xs4all.nl> 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.
> > >
> >
>
Re: GadgetSpecParser - bug in content type / href / data per view?
Posted by Bruno Bowden <br...@google.com>.
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 <dg...@google.com> 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 <br...@google.com> wrote:
>
> > On Feb 16, 2008 4:38 AM, Chris Chabot <ch...@xs4all.nl> 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.
> >
>
Re: GadgetSpecParser - bug in content type / href / data per view?
Posted by David Glazer <dg...@google.com>.
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 <br...@google.com> wrote:
> On Feb 16, 2008 4:38 AM, Chris Chabot <ch...@xs4all.nl> 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.
>
Re: GadgetSpecParser - bug in content type / href / data per view?
Posted by Bruno Bowden <br...@google.com>.
On Feb 16, 2008 4:38 AM, Chris Chabot <ch...@xs4all.nl> 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.
Re: GadgetSpecParser - bug in content type / href / data per view?
Posted by Kevin Brown <et...@google.com>.
On Feb 16, 2008 6:06 AM, Chris Chabot <ch...@xs4all.nl> wrote:
>
> On Feb 16, 2008, at 2:42 PM, Kevin Brown wrote:
>
> > Really, we're not as big of amateurs as some of this code might lead
> > you to
> > believe ;-).
>
> No worries that is quite apparent to anyone with some experience and i
> had made no such assumptions :-)
>
> > We already have a PHP sub-directory, and some other people were
> > actively
> > working on this. You might want to check the mail archives to see
> > who's
> > doing what, as I've kind of forgotten myself.
>
> I haven't seen anyone working on the php code base in the svn
> repository, and while i did occasionally see a 'i want to make a php
> version', i've seen little in the form up status updates, code or
> anything else, which made me a bit afraid that right now this effort
> might be in the conceptual stage and not yet quiet in the actual
> realization faze, also Cassie's call for people to help update the PHP
> code base to use the new features javascripts instead of the old (0.2
> or 03?) javascripts which were used to make the php prototype, were as
> far as i am aware, unanswered except by someone who said "explain to
> me how everything works in non document type language but in pseudo
> code and i'll make it", also not something that gave me a lot of
> confidence that this process is now well under way (no offense meant
> btw to that person). (I did respond offlist to Cassie to notify of my
> ongoing porting project, so maybe those other people is me?)
>
> If anyone else -is- working on the same, i would love to hear from you
> of course so we can perhaps combine our efforts.
>
> So presuming i am currently the only one working on a php port of
> shindig (thats looking to contribute it to the shindig project), what
> would be the procedure to submit my code for inspection and inclusion?
Open a ticket in JIRA (https://issues.apache.org/jira/browse/SHINDIG) and
attach a patch file with your additions. That's generally the best way to go
about it. If the code is accepted and you're interested we'll probably try
to get you regular commit access since you seem to be the only one actively
working on this.
>
>
> > Also, have you investigated using the Java implementation and simply
> > talking
> > to it from your PHP code base using the RpcServlet? A few other
> > people have
> > had success with this approach and it might get you what you're
> > looking for.
>
> Yep, we've privately exchanged emails on this a few days ago, while
> this is a great solution in many situations, the company i currently
> work for doesn't want to add another software stack to his 400+
> servers, nor do they feel confident that their resident programmers
> could handle any problems that might arise when something would need
> to be fixed, in the java code, and with over a few hundred thousands
> of vocal, paying customers who have our customer support numbers,
> thats something they would rather not risk.
>
> So for me (and i' m sure for more people in the future in similar
> situations) having a good and proper php code base to work with is
> much preferred over either using gmodules.com in any way shape or form
> (since adding an external dependency is a business risk too, even if
> it's google :-)), nor is using another software stack since the in-
> house knowledge is lacking to support this.
Ahh, sorry, I forgot that was you doing this. For some reason I thought it
was someone else :).
>
> Besides most of the hard parts are already done, the gadget spec
> parsing, translating and feature support, all i need to finish now is
> the caching, proxy, rpc and security token bits and their a lot easier
> to make since it involves a lot less reverse engineering of partially
> undocumented specs from java code (though as we discussed off list,
> Caja is still the big unknown factor in this until there's something
> like command line version available)
>
> -- 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.
Re: GadgetSpecParser - bug in content type / href / data per view?
Posted by Chris Chabot <ch...@xs4all.nl>.
On Feb 16, 2008, at 2:42 PM, Kevin Brown wrote:
> Really, we're not as big of amateurs as some of this code might lead
> you to
> believe ;-).
No worries that is quite apparent to anyone with some experience and i
had made no such assumptions :-)
> We already have a PHP sub-directory, and some other people were
> actively
> working on this. You might want to check the mail archives to see
> who's
> doing what, as I've kind of forgotten myself.
I haven't seen anyone working on the php code base in the svn
repository, and while i did occasionally see a 'i want to make a php
version', i've seen little in the form up status updates, code or
anything else, which made me a bit afraid that right now this effort
might be in the conceptual stage and not yet quiet in the actual
realization faze, also Cassie's call for people to help update the PHP
code base to use the new features javascripts instead of the old (0.2
or 03?) javascripts which were used to make the php prototype, were as
far as i am aware, unanswered except by someone who said "explain to
me how everything works in non document type language but in pseudo
code and i'll make it", also not something that gave me a lot of
confidence that this process is now well under way (no offense meant
btw to that person). (I did respond offlist to Cassie to notify of my
ongoing porting project, so maybe those other people is me?)
If anyone else -is- working on the same, i would love to hear from you
of course so we can perhaps combine our efforts.
So presuming i am currently the only one working on a php port of
shindig (thats looking to contribute it to the shindig project), what
would be the procedure to submit my code for inspection and inclusion?
> Also, have you investigated using the Java implementation and simply
> talking
> to it from your PHP code base using the RpcServlet? A few other
> people have
> had success with this approach and it might get you what you're
> looking for.
Yep, we've privately exchanged emails on this a few days ago, while
this is a great solution in many situations, the company i currently
work for doesn't want to add another software stack to his 400+
servers, nor do they feel confident that their resident programmers
could handle any problems that might arise when something would need
to be fixed, in the java code, and with over a few hundred thousands
of vocal, paying customers who have our customer support numbers,
thats something they would rather not risk.
So for me (and i' m sure for more people in the future in similar
situations) having a good and proper php code base to work with is
much preferred over either using gmodules.com in any way shape or form
(since adding an external dependency is a business risk too, even if
it's google :-)), nor is using another software stack since the in-
house knowledge is lacking to support this.
Besides most of the hard parts are already done, the gadget spec
parsing, translating and feature support, all i need to finish now is
the caching, proxy, rpc and security token bits and their a lot easier
to make since it involves a lot less reverse engineering of partially
undocumented specs from java code (though as we discussed off list,
Caja is still the big unknown factor in this until there's something
like command line version available)
-- Chris
Re: GadgetSpecParser - bug in content type / href / data per view?
Posted by Kevin Brown <et...@google.com>.
On Feb 16, 2008 5:20 AM, Chris Chabot <ch...@xs4all.nl> wrote:
> Thanks, clears things up quite a bit.
>
> Once the patch lands i'll mirror it in the port I'm working on, better
> to mimic the behavior as closely as possible for now i guess, makes
> following 'upstream' a lot easier on a whole.
>
> Ps one general remark, for when someone has some spare time he'd like
> to fill with some code rewriting, there's a good few small terminology
> inconsistencies in the code, such as calling something 'Required' in
> the spec and gadget spec parser loops, but in the parsed gadget spec,
> it has a isOptional, so the boolean is flipped around in the
> processFeature function, such things happen in a few locations where
> the terminology used internally isn't quite consistent, which might
> make it a little less readable to the less seasoned programmers.
Indeed -- The entire "Gadget" heirarchy (GadgetSpec / GadgetView / Gadget /
ParsedGadget) is very kludgy and is in need of some significant refactoring,
as is GadgetServer. You'll have to bear with us a bit on this one as we've
had a lot of code to write and not a lot of time to do it in, so our code
reviews haven't been applied as thoroughly as we would normally like.
Really, we're not as big of amateurs as some of this code might lead you to
believe ;-).
>
> Pps, as you might have been able to tell, i'm working on a propper PHP
> shindig implementation (the current one is nothing more then a proof
> of concept with a lot of hard coded assumptions and can't be seen as a
> implementation really), i've chosen to mirror the java version as
> closely as possible in PHP, which should make it a bit cross
> maintainable since the logic structures in both will be identical
> (except for the jetty part that is). The gadget spec parser with all
> its dependencies is just about done, and i hope to have the other bits
> done in the coming weeks.
>
> What would be the easiest way to submit my work as a proposed new php
> code base, shall i make a code.google.com project out of it and mail
> the url to it here or what would be preferred?
We already have a PHP sub-directory, and some other people were actively
working on this. You might want to check the mail archives to see who's
doing what, as I've kind of forgotten myself.
Also, have you investigated using the Java implementation and simply talking
to it from your PHP code base using the RpcServlet? A few other people have
had success with this approach and it might get you what you're looking for.
Re: GadgetSpecParser - bug in content type / href / data per view?
Posted by Chris Chabot <ch...@xs4all.nl>.
Thanks, clears things up quite a bit.
Once the patch lands i'll mirror it in the port I'm working on, better
to mimic the behavior as closely as possible for now i guess, makes
following 'upstream' a lot easier on a whole.
Ps one general remark, for when someone has some spare time he'd like
to fill with some code rewriting, there's a good few small terminology
inconsistencies in the code, such as calling something 'Required' in
the spec and gadget spec parser loops, but in the parsed gadget spec,
it has a isOptional, so the boolean is flipped around in the
processFeature function, such things happen in a few locations where
the terminology used internally isn't quite consistent, which might
make it a little less readable to the less seasoned programmers.
Pps, as you might have been able to tell, i'm working on a propper PHP
shindig implementation (the current one is nothing more then a proof
of concept with a lot of hard coded assumptions and can't be seen as a
implementation really), i've chosen to mirror the java version as
closely as possible in PHP, which should make it a bit cross
maintainable since the logic structures in both will be identical
(except for the jetty part that is). The gadget spec parser with all
its dependencies is just about done, and i hope to have the other bits
done in the coming weeks.
What would be the easiest way to submit my work as a proposed new php
code base, shall i make a code.google.com project out of it and mail
the url to it here or what would be preferred?
-- Chris
On Feb 16, 2008, at 1:55 PM, Kevin Brown wrote:
> 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 <ch...@xs4all.nl> 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.
Re: GadgetSpecParser - bug in content type / href / data per view?
Posted by Kevin Brown <et...@google.com>.
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 <ch...@xs4all.nl> 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.