Looking at the rpc servlet:
if (isset($GLOBALS['HTTP_RAW_POST_DATA']) || isset($_POST['request'])) {
...stuff ....
} else {
throw new Exception("No post data set");
}
So it looks both at the raw post, and a request=<foo> (hack for php, php
client side doesnt really do raw posts so easily) and if neither are present
it throws that error.
In what way does the sample gadget now parse the info to the rpc service?
get param or something?
Should be easy & quick enough to fix in any case. I'm stuck in a train right
now (thalys, rocks that they have wifi) but i'll take a look once im near a
desk again :)
2008/9/19 Astha Bhatnagar <[EMAIL PROTECTED]>
> Hi Chris,
> I actually tried latest shindig code and sample container. It is throwing
> error
>
> <html><body><h1>Internal Server Error</h1><br />No post data set<br
> /><pre>Array
>
> (
>
> [0] => Array
>
> (
>
> [file] => C:\wamp\www\shindig\php\index.php
>
> [line] => 109
>
> [function] => doPost
>
> [class] => JsonRpcServlet
>
> [object] => JsonRpcServlet Object
>
> (
>
> [lastModified:private] =>
>
> [contentType:private] => text/html
>
> [charset:private] => UTF-8
>
> [noCache:private] =>
>
> [cacheTime:private] => 86400
>
> [noHeaders] =>
>
> )
>
> [type] => ->
>
> [args] => Array
>
> (
>
> )
>
> )
>
> )
>
> </pre></body></html>
>
> but same samplecontainer is working fine with Java Shindig.
>
> That's why this issue came up.
>
> Regards,
>
> Astha
>
>
> On Fri, Sep 19, 2008 at 5:03 PM, Chris Chabot <[EMAIL PROTECTED]> wrote:
>
> > PHP Shindig def does support the metadata call, see
> > http://modules.partuza.nl/gadgets/files/container/sample-metadata.htmlas
> > example. If there's something missing in the response structure, please
> > file
> > a JIRA issue for that.
> >
> > Json-RPC is being worked on, and hope to have that in somewhere next
> week.
> >
> > 2008/9/18 Astha Bhatnagar <[EMAIL PROTECTED]>
> >
> > > Hi Ben,
> > > As per the samplecontiner code
> > >
> > > function generateGadgets(metadata) {
> > > // TODO: The gadget.js file should really have a clearGadgets method
> > > gadgets.container.gadgets_ = {};
> > > for (var i = 0; i < metadata.gadgets.length; i++) {
> > > gadget = gadgets.container.createGadget(
> > > {'specUrl': metadata.gadgets[i].url, 'title':
> > > metadata.gadgets[i].title});
> > > gadget.setServerBase('../../');
> > > gadget.secureToken = escape(generateSecureToken());
> > > gadgets.container.addGadget(gadget);
> > > }
> > >
> > >
> gadgets.container.layoutManager.setGadgetChromeIds(['gadget-chrome']);
> > > reloadStateFile(function() {
> > > gadgets.container.renderGadgets();
> > > });
> > > };
> > >
> > > I think what they have done is something like Tamlyn Rhodes has
> suggested
> > > in
> > > this thread
> > >
> > > var gadgetDefaultPrefs = {};
> > >
> > > for (var prefName in gadgetMetadata.userPrefs) {
> > > gadgetDefaultPrefs[prefName] =
> > > gadgetMetadata.userPrefs[prefName].default;
> > > }
> > > var gadget = gadgets.container.getGadget(gadgetId);
> > > gadget.setUserPrefs(gadgetDefaultPrefs);
> > > gadget.refresh();
> > >
> > > Java Shindig is supporting JsonRpc and so gadget/metadata call. That's
> > why
> > > its working properly in Java Shindig and PHP side its still not
> supported
> > > and hence its not working with PHP Shindig (even sample container it
> self
> > > not working with PHP Shindig).
> > >
> > > Anybody please correct me if I am wrong :)
> > >
> > > 2008/9/18 ben bonfil <[EMAIL PROTECTED]>
> > >
> > > > To all involved in this thread,
> > > > Can you conclude on the preferred way to do this? I have just ran
> into
> > a
> > > > problem with my solution ( created a bug report actually, though I
> > guess
> > > > it's not really valid -
> > > https://issues.apache.org/jira/browse/SHINDIG-613)
> > > >
> > > > Before I go ahead and fix it, I'd like to know what is the correct
> way
> > to
> > > > initialize the userprefs, and whether it was already patched in the
> > > latest
> > > > revision (didn't see anything related to it on the SVN log)
> > > >
> > > > Thanks,
> > > >
> > > > Ben
> > > >
> > > > 2008/9/14 ben bonfil <[EMAIL PROTECTED]>
> > > >
> > > > > Hi,
> > > > > I've attached the patch for the method that I use.
> > > > >
> > > > > Ben
> > > > >
> > > > >
> > > > > 2008/9/12 John Hjelmstad <[EMAIL PROTECTED]>
> > > > >
> > > > >> That's fair. So long as prefs.js doesn't parse the URL but instead
> > > > accepts
> > > > >> only the prefs values the server provides, we're golden.
> > > > >>
> > > > >> 2008/9/12 Kevin Brown <[EMAIL PROTECTED]>
> > > > >>
> > > > >> > 2008/9/12 John Hjelmstad <[EMAIL PROTECTED]>
> > > > >> >
> > > > >> > > I could be misunderstanding, but it sounds like that's what
> Ben
> > > did
> > > > --
> > > > >> > pass
> > > > >> > > (in the server) the defaults to setMessages_ with some special
> > > > format,
> > > > >> > and
> > > > >> > > have prefs.js read them when no up_<key> values are provided
> on
> > > the
> > > > >> URL.
> > > > >> > > Meanwhile, UP substitution is already handled by the server,
> > with
> > > a
> > > > >> merge
> > > > >> > > algorithm that presumably mirrors what Ben's does in JS.
> > > > >> >
> > > > >> >
> > > > >> > Yeah, and I think that's error prone. We should be doing the
> > merging
> > > > in
> > > > >> > just
> > > > >> > one place, or we're going to have bugs.
> > > > >> >
> > > > >> >
> > > > >> > >
> > > > >> > >
> > > > >> > > -John
> > > > >> > >
> > > > >> > > 2008/9/12 Kevin Brown <[EMAIL PROTECTED]>
> > > > >> > >
> > > > >> > > > That's not a complete solution because it skips user pref
> > > > >> substitution.
> > > > >> > > The
> > > > >> > > > only thing that completely allows skipping filling in the
> user
> > > > pref
> > > > >> > > > defaults
> > > > >> > > > in the url is to make the user prefs merge happen server
> side.
> > > > >> > > >
> > > > >> > > > 2008/9/11 ben bonfil <[EMAIL PROTECTED]>
> > > > >> > > >
> > > > >> > > > > My solution was indeed to pass the default values in the
> > > > >> setMessages_
> > > > >> > > > > array(like iGoogle), and modify prefs.js accordingly.
> > > > >> > > > >
> > > > >> > > > > Ben Bonfil
> > > > >> > > > >
> > > > >> > > > > On 9/12/08, John Hjelmstad <[EMAIL PROTECTED]> wrote:
> > > > >> > > > > > Correct me if I'm wrong, but the only server-side code
> > that
> > > > >> touches
> > > > >> > > > > > gadgets.Prefs initializes it with Messages
> (setMessages_),
> > > not
> > > > >> > Prefs
> > > > >> > > at
> > > > >> > > > > all,
> > > > >> > > > > > all of which are initialized by parsing
> > > > >> > > > gadgets.util.getUrlParameters().
> > > > >> > > > > >
> > > > >> > > > > > I don't have any strong opinion on implementation
> > > particulars
> > > > -
> > > > >> > > either
> > > > >> > > > > way
> > > > >> > > > > > server-side code spits out defaults and some
> corresponding
> > > JS
> > > > >> reads
> > > > >> > > > > them...
> > > > >> > > > > > assuming we want to support this in the first place.
> > > > >> > > > > >
> > > > >> > > > > > -John
> > > > >> > > > > >
> > > > >> > > > > > On 9/11/08, Kevin Brown <[EMAIL PROTECTED]> wrote:
> > > > >> > > > > >>
> > > > >> > > > > >> That's wholly unnecessary. If we want gadgets.Prefs to
> > > > include
> > > > >> > > > defaults,
> > > > >> > > > > >> we
> > > > >> > > > > >> just need to make the server side code that outputs
> > > > >> gadgets.Prefs
> > > > >> > > > > properly
> > > > >> > > > > >> merge in the defaults from the spec. There's no reason
> to
> > > add
> > > > >> new
> > > > >> > > > client
> > > > >> > > > > >> libraries.
> > > > >> > > > > >>
> > > > >> > > > > >>
> > > > >> > > > > >> On Thu, Sep 11, 2008 at 3:01 PM, John Hjelmstad <
> > > > >> [EMAIL PROTECTED]
> > > > >> > >
> > > > >> > > > > wrote:
> > > > >> > > > > >>
> > > > >> > > > > >> > Given that default values for a given gadget fixed in
> > the
> > > > >> spec,
> > > > >> > I
> > > > >> > > > > think
> > > > >> > > > > >> the
> > > > >> > > > > >> > cleaner solution is to inject some kind of
> defaultPrefs
> > > > >> object
> > > > >> > > into
> > > > >> > > > > the
> > > > >> > > > > >> > gadget when rendering it, somewhat like
> > > > gadgets.config.init()
> > > > >> > > does.
> > > > >> > > > > >> >
> > > > >> > > > > >> > As implemented today (which admittedly isn't the
> > cleanest
> > > > >> impl,
> > > > >> > > but
> > > > >> > > > > >> that's
> > > > >> > > > > >> > an orthogonal problem), that would mean modifying
> > > > >> > > > GadgetRenderingTask
> > > > >> > > > > to
> > > > >> > > > > >> do
> > > > >> > > > > >> > something like:
> > > > >> > > > > >> >
> > > > >> > > > > >> >
> > > > >> > > > > >>
> > > > >> > > > >
> > > > >> > > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > >
> > >
> >
> js.append("gadgets.Prefs.setDefaults(").append(jsonObjectRepresentingDefaultsOf(gadget.getSpec()).append(");\n");
> > > > >> > > > > >> >
> > > > >> > > > > >> > ...then augmenting features/core/prefs.js
> > correspondingly
> > > > to
> > > > >> > > > > initialize
> > > > >> > > > > >> > from
> > > > >> > > > > >> > defaults when the up_<key> equivalent isn't
> available.
> > > > >> > > > > >> >
> > > > >> > > > > >> > --John
> > > > >> > > > > >> >
> > > > >> > > > > >> > On 9/10/08, Cassie <[EMAIL PROTECTED]> wrote:
> > > > >> > > > > >> > >
> > > > >> > > > > >> > > (in case you are interested - don't feel pressured
> > > though
> > > > >> :)
> > > > >> > > > > >> > >
> > > > >> > > > > >> > > samplecontainer.js actually already makes calls to
> > the
> > > > >> > metadata
> > > > >> > > > > >> servlet.
> > > > >> > > > > >> > > see
> > > > >> > > > > >> > > line 167 - the "requestGadgetMetaData" function.
> This
> > > > came
> > > > >> > from
> > > > >> > > a
> > > > >> > > > > >> > different
> > > > >> > > > > >> > > patch which gave the samplecontainer the ability to
> > > show
> > > > >> > gadget
> > > > >> > > > > >> > > titles.
> > > > >> > > > > >> > >
> > > > >> > > > > >> > > - Caszsie
> > > > >> > > > > >> > >
> > > > >> > > > > >> > >
> > > > >> > > > > >> > >
> > > > >> > > > > >> > > On Wed, Sep 10, 2008 at 6:48 AM, Tamlyn Rhodes <
> > > > >> > > [EMAIL PROTECTED]
> > > > >> > > > >
> > > > >> > > > > >> > wrote:
> > > > >> > > > > >> > >
> > > > >> > > > > >> > > > On Tue, Sep 9, 2008 at 6:55 PM, Cassie <
> > > > [EMAIL PROTECTED]>
> > > > >> > > wrote:
> > > > >> > > > > >> > > > > Hey Tamlyn - do you think you could make this
> > into
> > > a
> > > > >> patch
> > > > >> > > and
> > > > >> > > > > >> attach
> > > > >> > > > > >> > > it
> > > > >> > > > > >> > > > to
> > > > >> > > > > >> > > > > a jira issue for Shindig?
> > > > >> > > > > >> > > >
> > > > >> > > > > >> > > > The thing is I've done it from outside of
> > gadgets.js
> > > so
> > > > >> it's
> > > > >> > > not
> > > > >> > > > > >> > > > really patchable. Doing it in gadgets.js would
> mean
> > > > >> making
> > > > >> > an
> > > > >> > > > ajax
> > > > >> > > > > >> > > > call to fetch the metadata in the
> > > > >> > gadgets.container.addGadget
> > > > >> > > > > method
> > > > >> > > > > >> > > > and I'm not really sure how that would work since
> > > > >> > > > gadgets.ioisn't
> > > > >> > > > > >> > > > available in the container (unless i've
> > > misunderstood).
> > > > >> > > > > >> > > >
> > > > >> > > > > >> > > > I'm aware that you're keen to maintain clear
> > > separation
> > > > >> > > between
> > > > >> > > > > >> > > > Shindig and the JavaScript code that manages the
> > > > >> > layout/chrome
> > > > >> > > > but
> > > > >> > > > > >> for
> > > > >> > > > > >> > > > most people actually using Shindig I suspect this
> > > > >> separation
> > > > >> > > is
> > > > >> > > > > >> rather
> > > > >> > > > > >> > > > more theoretical than practical. I've been
> > developing
> > > a
> > > > >> drag
> > > > >> > &
> > > > >> > > > > drop
> > > > >> > > > > >> > > > layout/framework using jQuery, PHP and MySQL and
> I
> > > hope
> > > > >> to
> > > > >> > > open
> > > > >> > > > > >> source
> > > > >> > > > > >> > > > this once I get it working. This should be some
> > time
> > > in
> > > > >> > > > September.
> > > > >> > > > > >> > > >
> > > > >> > > > > >> > > > Tamlyn.
> > > > >> > > > > >> > > >
> > > > >> > > > > >> > >
> > > > >> > > > > >> >
> > > > >> > > > > >>
> > > > >> > > > > >
> > > > >> > > > >
> > > > >> > > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > > >
> > > > >
> > > >
> > >
> >
>
