there I got the hint :)Yes you are correct the issue is HTTP_RAW_POST_DATA
was not allowed on my PHP.ini settings.
And hence was not getting posted.
Thanks for the great analysis , that too in the train:)
Thanks,
Astha
On Fri, Sep 19, 2008 at 6:12 PM, Chris Chabot <[EMAIL PROTECTED]> wrote:
> 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.
> > > > > >> > > > > >> > > >
> > > > > >> > > > > >> > >
> > > > > >> > > > > >> >
> > > > > >> > > > > >>
> > > > > >> > > > > >
> > > > > >> > > > >
> > > > > >> > > >
> > > > > >> > >
> > > > > >> >
> > > > > >>
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
