Mailing-List: contact shindig-issues-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: shindig-dev@incubator.apache.org
Message-ID: <1830532088.1261564169564.JavaMail.jira@brutus>
Date: Wed, 23 Dec 2009 10:29:29 +0000 (UTC)
From: "Bruce Godden (JIRA)" <jira@apache.org>
To: shindig-issues@incubator.apache.org
Subject: [jira] Commented: (SHINDIG-1248) UserPref problems in example
 container code: gadgets.js and cookiebaseduserprefstore.js
In-Reply-To: <841297010.1260963978054.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/SHINDIG-1248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12794003#action_12794003 ] 

Bruce Godden commented on SHINDIG-1248:
---------------------------------------

There is another similar issue in gadgets.IfrGadget.prototype.hasViewablePrefs_ where the pref value is expected to be an object with a 'type' property. That it isn't causes all gadgets to be deemed to have editable preferences.

Then the construction of the preferences dialog tries to use http://www.gmodules.com/ig/gadgetsettings which fails (I assume due to browser cross-domain issues) which results in an empty dialog. I have seen comments elsewhere suggesting that Shindig ought to provide its own implementation of this functionality.

Seeing this makes me think that perhaps my fixes above are wrong and that the pref value ought to be an object with type, value, default and other properties. These objects ought to be constructed from the gadget specification. The problem then becomes: how to fetch the gadget specification in the example container? The subsequent parsing to fetch the pref objects is straightforward. (Particularly if the specification is fetched as DOM object.)


> UserPref problems in example container code: gadgets.js and cookiebaseduserprefstore.js
> ---------------------------------------------------------------------------------------
>
>                 Key: SHINDIG-1248
>                 URL: https://issues.apache.org/jira/browse/SHINDIG-1248
>             Project: Shindig
>          Issue Type: Bug
>          Components: Javascript 
>            Reporter: Bruce Godden
>            Priority: Minor
>
> I was trying to create a simple test container which supported user preferences based on the pubsub example but I encountered a number of bugs in the example container javascript files.
> In gadgets.js the setUserPref function appears to be setting the preference in the GadgetService object instead of the Gadget object. Also the ways it runs the loop processing the function arguments might give an unwanted effect if no value was specified for the last name argument. The fixed function is:
> gadgets.IfrGadgetService.prototype.setUserPref = function(editToken, name, value) {
>   var id = gadgets.container.gadgetService.getGadgetIdFromModuleId(this.f);
>   var gadget = gadgets.container.getGadget(id);
>   for (var i = 2, j = arguments.length; i < j; i += 2) {      // *** run loop using the value argument to detect the end ***
>     gadget.userPrefs[arguments[i - 1]] = arguments[i];      // *** argument accesses changed ***
>   }
>   gadget.saveUserPrefs();      // *** use gadget instead of this ***
> };
> In gadgets.js the getUserPrefValue and handleSaveUserPrefs  functions fail to fetch/store the value for a preference because they seem to think that it is stored as a value attribute; it isn't according to the rest of the code. The fixed functions are:
> gadgets.Gadget.prototype.getUserPrefValue = function(name) {
>   var pref = this.userPrefs[name];
>   return typeof(pref) != 'undefined' && pref != null ?      // *** .value deleted from this line twice ***
>       pref : this.userPrefs['default'];        // *** .value deleted from this line ***
> };
> (Actually in the above is there really any point in fetching a global default value for a preference that doesn't have a value set? This probably isn't going to be the correct default value as given by the gadget specification.)
> gadgets.IfrGadget.prototype.handleSaveUserPrefs = function() {
>   this.hideUserPrefsDialog();
>   var numFields = document.getElementById('m_' + this.id +
>       '_numfields').value;
>   for (var i = 0; i < numFields; i++) {
>     var input = document.getElementById('m_' + this.id + '_' + i);
>     var userPrefNamePrefix = 'm_' + this.id + '_up_';
>     var userPrefName = input.name.substring(userPrefNamePrefix.length);
>     var userPrefValue = input.value;
>     this.userPrefs[userPrefName] = userPrefValue;      // *** .value deleted from this line ***
>   }
>   this.saveUserPrefs();
>   this.refresh();
> };
> The current settings of the user preferences are not loaded into the gadget during its creation. I added a comment to SHINDIG-181 about this but here is the fixed function anyway:
> gadgets.Container.prototype.addGadget = function(gadget)
> {
>   gadget.id = this.getNextGadgetInstanceId();
>   this.gadgets_[this.getGadgetKey_(gadget.id)] = gadget;
>   gadget.userPrefs = this.userPrefStore.getPrefs(gadget);      // *** new line ***
> };
> In cookiebaseduserprefstore.js the savePrefs function is trying to fetch a preference value by calling getUserPref on the gadget but the function is should be calling is getUserPrefValue. However, it would be neater to simple use the userPrefs object it fetched to find the preference names directly. The fixed function is:
> gadgets.CookieBasedUserPrefStore.prototype.savePrefs = function(gadget) {
>   var pairs = [];
>   var prefs = gadget.getUserPrefs();       // *** new line ***
>   for (var name in prefs) {       // *** use the fetched prefs ***
>     var pair = encodeURIComponent(name) + '=' + encodeURIComponent(prefs[name]);       // *** access the fetched prefs directly ***
>     pairs.push(pair);
>   }
>   var cookieName = this.USER_PREFS_PREFIX + gadget.id;
>   var cookieValue = pairs.join('&');
>   shindig.cookies.set(cookieName, cookieValue);
> };

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.