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 <[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.
