Hi alphalouis, I m really impressed with the way you have followed the implementation guides. I m really interested in this discussion group. I need to develop a container in PHP. I havent gone through shindig yet, but will go through it keeping in mind the points that you have mentioned above. You guys have stated that the PHP version of shindig is not much full fledged working, but i will have to wait for it, as my site needs to be developed in PHP. I would share my experience here and would also like to get yous as well. Please keep on posting for any new developments. You are doing a great job.
Bye. On Jan 28, 9:48 am, alphalouis <[EMAIL PROTECTED]> wrote: > So I came to a conclusion. > Use Apache Shindig. > I just browsed the features directory in the SVN and looks like some > serious work is going on. (but the php version is dry). Maybe is a few > days I will even post about getting Shindig running for your site. > > End this topic here > Bye and have a nice time with Shindig. :) > > On Jan 27, 8:24 pm, alphalouis <[EMAIL PROTECTED]> wrote: > > > Now I got some information from Brian. > > I got to know why OAuth is being Implemented. > > Have you seen on Facebook? whenever you access an app, you are asked > > whether you want the app to access your personal data? Yeah thats what > > OAuth is meant for. Its like an authorising agent that asks users > > whether they want to allow the gadget to access their personal data. > > Example: If a gadget lists your friends. Then before accessing the > > gadget you will be asked whether you want the gadget to access the > > friends data. > > Right? > > > On Jan 27, 8:11 pm, alphalouis <[EMAIL PROTECTED]> wrote: > > > > (I didn't complete the previous message. here is the rest of the > > > message).... > > > > 2.) I need to take the javascript files and mess with them so that > > > when a function requesting data from my site is called, it should get > > > the data. I mean.... I need to change or add some variables... right? > > > (I don't know... just asking you..) > > > > 3.) Implement some extras like the tabs feature so that you can also > > > support a few Google Gadgets feature. This implmentation of Tabs and > > > other features can be done thru the <require> tag (The google gadgets > > > way). And implementing extras.... like Caja etc. I don't know how to > > > do it. If anyone can say it would be nice. > > > > There was once a post on the Shindig mailing list titled "How Shindig > > > works" > > > Here's Kevin's reply in the mailing list. > > > > " > > > Step 1: Fetch the gadget spec XML. This *should* consult a cache > > > first, to > > > minimize load on the gadget author's HTTP server. The spec does not > > > say how > > > long to cache for (suggest 24 hours or less), but we do require that > > > you > > > support bypassing / clearing the cache on your server somehow. The PHP > > > implementation should support the "nocache=1" query parameter to be > > > compatible with Java. Relevant Java classes: GadgetServer, > > > RemoteContentFetcher, GadgetDataCache > > > > Step 2: Process the gadget spec. This is hard, especially since the > > > spec > > > hasn't been published yet (it will be later this week, I'm told). I > > > would > > > strongly recommend using SimpleXML and follow the same processing > > > pattern as > > > you'll see in GadgetSpecParser. SimpleXML should make this pretty > > > easy, and > > > you won't have to go through the pain of all that DOM nastiness that > > > our > > > Java implementation had to deal with. Relevant Java classes: > > > GadgetSpecParser, GadgetSpec > > > > Step 3: Fetch message bundles. These are fetched by inspecting the > > > <Locale> > > > tags in the spec and making http requests for the bundle files. You > > > should > > > get your locale from the "lang" and "country" query parameters. > > > Processing > > > rules for locales have a few caveats, so examine > > > MessageBundleSubstituter > > > carefully and emulate that behavior. The actual messagebundle spec is > > > extremely simple. Message bundles should be cached using the same > > > caching > > > policy as Step #1. Relevant classes: MessageBundle, > > > MessageBundleParser, > > > MessageBundleSubstituter > > > > Step 4: Perform hangman variable substitutions. This is done by > > > replacing > > > __UP, __MSG, __MODULE, and other placeholders with other values. You > > > should > > > perform these substitutions in the following order: > > > > __MSG > > > __BIDI > > > __MODULE > > > __UP > > > > MSG and UP need to be html escaped to prevent XSS attacks. BIDI is a > > > set of > > > constants (see BidiSubstituter or the spec, whenever it gets > > > published, for > > > details). __MODULE only has one possible value right now: > > > __MODULE_ID__, > > > which is the "mid" query parameter (an UNSIGNED integer). Only do a > > > single > > > pass for each substitution type (you can use either a regex, or > > > implement a > > > basic parser like we did), and do not revist types already processed > > > (i.e. > > > don't substitute __MSG after you've already done __UP). Relevant > > > classes: > > > Substitutions, MessageBundleSubstituter, BidiSubstituter, > > > ModuleSubstituter, > > > UserPrefsSubstituter > > > > Step 5: Process <Require> / <Optional> features. This is going to be > > > hard to > > > do right now without the spec. We will be publishing this shortly, but > > > what > > > you see in shindig right now is, for the most part, the complete set > > > of what > > > will be in the initial "mandatory" support list. The good news is that > > > most > > > of this work is already done for you. You need to implement support > > > for > > > feature.xml loading and proper handling of <dependency>. See > > > trunk/features/README for details on the file format, and look at > > > JsFeatureLoader for an implementation. Combine this with the > > > dependency > > > graph resolution in GagdetFeatureRegistry.getIncludedFeatures and you > > > should > > > be good to go. Relevant classes: GadgetFeatureRegistry, JsFeature, > > > JsFeatureLoader > > > > Step 6: Output gadget content. The order is as follows: > > > > - standard html header (an ugly inline version can be seen in > > > GadgetRenderingServlet. This will be a lot cleaner in a PHP template). > > > Replicate this exactly for now (even the lack of a DOCTYPE). > > > - feature libraries (separate scripts, or ideally rolled up into a > > > single > > > file or script block like we do in GadgetRenderingServlet) > > > - Initialization of feature libraries (currently only gadgets.ifpc_, > > > gadgets.Prefs, and gadgets.io need this) > > > - processed gadget code from step 4. > > > - a single call to gadgets.util.runOnLoadHandlers > > > - close your html > > > > Ideally, all of the output from step 6 (except the html body wrapper) > > > should > > > be passed through Caja, but right now that's going to be difficult to > > > do in > > > PHP. Don't worry about it for now, I'll have a solution for you > > > shortly. > > > > This implements what we have on gmodules.com. Ideally, everything up > > > to and > > > including step 5 should be able to be done directly from some library > > > similar to GadgetProcessor, and the wrapper of Step 6 should happen in > > > the > > > code that specifically handles outputting iframe content. I *strongly* > > > recommend using curl_multi in implementing containers to fetch all of > > > the > > > gadget data in parallel, then caching that so that when the iframes > > > load, > > > they will be loading entirely from cache (which will be fast). This is > > > really the only part of the whole pipeline that needs to be run in > > > parallel, > > > due to the fact that http fetching is slow. " > > > > So thats just a hint for everyone else (I didn't understand most of > > > it). > > > So can anyone explain it clearly on How to do it in PHP? > > > > I hope this topic helps others who want to do it on their own. > > > > -- > > > Eagerly waiting for your replies! --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Implementing OpenSocial Containers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/opensocial-container?hl=en -~----------~----~----~----~------~----~------~--~---
