convio / luminateextend Goto Github PK

jQuery 1.11 and 2.1 are currently in beta. Once they've been released, the test suite should be updated accordingly.

Convio's "donate" call in their CRDonationAPI requires the form data to be passed as a query string EXCEPT for the credit card information.

Using luminateExtend's api call for donate does a POST with all the data as post data, which will return "required parameter 'method' not found" because the CRDonationAPI is looking for much of its arguments (well, at least "method") in the query string.

Currently I have to do a manual splitting of the parameters between the query string and post data via jQuery.post, but I end up missing out on luminateExtend's robust CORS-with-fallback for cross domain requests.

For organizations whose Luminate Online site is using Tomcat rather than JServ, luminateExtend.global.sessionCookie is not set correctly, breaking requests which require cookies/authentication.

From luminateExtend_server:

[[E130:"[[T7:PixelServer]]" dup dup "?" indexof 1 + swap length substring]]

With the move to Tomcat, the cookie is no longer part of the query string, rather, it is separated from the servlet name with a semicolon.

Provide developers with a few easy-to-understand functional examples that use the library.

This will build on work done in v1.2 to allow for parsing tags to display constituent information.

One should be able to display an action alert on an external website using something like this:

<luminate:actionAlert id="1234"></luminate:actionAlert>

When attempting to make a request to one of the API methods for Events using the shorthand "event" or "orgevent", the servlet name in the request is CROrgeventAPI rather than CROrgEventAPI. This causes the request to fail due to a 404.

luminateExtend.api({
  api: 'event', 
  data: myData, 
  callback: function(data) {

  }
})

Right now the Bootstrap example pages don't look right in IE8. respond.js needs to be included.

If luminateExtend.api.getAuth is called repeatedly, the method makes separate, asynchronous requests to get an auth token for each call. Instead, only one request for a token should be made, and any calls to the method made while the request is still outstanding should simply be canceled.

The request method references categoryId as luminateExtend.global.categoryId. This should be luminateExtend.global.apiCommon.categoryId.

When the postMessage transport is used in IE8/9, if the page includes another plugin that uses postMessage (such as Facebook social plugins, i.e. the Like Box), luminateExtend does not validate the origin when a message is received. This causes messages sent by the other plugin to throw errors, because luminateExtend has bound an event to the message/onmessage events.

Currently if a responseFilter is provided with an array that is not found, the response object is updated to include the object.

For example, using the example JavaScript:

luminateExtend.api({
  api: 'teamraiser', 
  data: 'method=getParticipants&fr_id=1234&first_name=John', 
  responseFilter: {
    array: 'getParticipantsResponse.participant', 
    filter: 'personalPagePrivate == false' // or 'personalPagePrivate != true'
  }, 
  callback: function(response) {
    console.log(response);
  }
});

If fr_id 1234 does not exist and thus an error is returned, the response object is updated to include getParticipantsResponse.

When using the postMessage transport, luminateExtend.api.request adds a hidden iframe to the DOM. After the request is complete, the method is supposed to remove the iframe using jQuery.remove(), however, this does not happen. The iframe remains in the DOM tree even after the request has completed.

jQuery v1.10.2 was released on July 3. As soon as it is available on the Google CDN, luminateExtend_server and luminateExtend_client should be updated to use it.

When luminateExtend.api.request is called with requiresAuth set to true, and no auth token has been defined, the method uses luminateExtend.api.getAuth to get a token before proceeding with the request. When the request uses the postMessage transport, this isn't necessary -- luminateExtend_server can itself get an auth token. Doing so will eliminate an HTTP request and improve performance.

Once madrobby/zepto#842 is fixed, luminateExtend.api.request should be updated to use CORS in browsers that support it regardless of whether jQuery or Zepto is used.

jQuery 1.10.2 should continue to be used in IE8 and below.

The following will throw a TypeError if the init method has not been called because luminateExtend.api.request attempts to read from luminateExtend.global.apiCommon which is not defined.

luminateExtend.api.request({
  api: 'cons', 
  data: 'method=loginTest'
});

While one should not call the request method prior to calling init, it shouldn't throw an error.

Depends on Issue #40.

Currently luminateExtend.api.request() uses feature detection to determine whether the browser supports CORS, if not falls back to using the postMessage API, and then finally if postMessage is not supported, falls back to a hash transport. At this point, the only browser with even a modicum of market share that requires this final fallback is IE7.

Still need to determine if the library in its current form can work with Zepto, or if the code would need to be forked.

One immediate issue is that Zepto.ajax() does not seem to include support for setting the withCredentials property to allow for cross-domain requests with cookies.

In v1.3, luminateExtend.api.getAuth() was updated to by default use the cached auth token if one is available. The CORS and postMessage transports were updated to override this default setting and get a new auth token immediately after the login or logout methods are called. The hash transport, however, has not been updated, and thus is using a stale auth token.

Luminate Online pages do not return a p3p HTTP header needed by browsers such as IE to properly set third-party cookies. As such, when calling luminateExtend.api.request, cookies may not be sent in the request. In order to ensure that session information is maintained, the sessionCookie should be appended to all request URLs.

http://caniuse.com/#feat=xhr2

jQuery 1.11 and 2.1 are currently in beta. Once they've been released, the Bootstrap examples should be updated accordingly.

The common parameters list_filter_column and list_filter_text can be used with many API methods to filter by a specified database column. However, there are some cases where client-side filtering is needed on top of this server-side filtering. The request method should provide something like the following to allow for filtering on a particular object's value within an array:

luminateExtend.api.request({
  api: 'teamraiser', 
  callback: getParticipantsCallback, 
  data: 'method=getParticipants&fr_id=1234&first_name=John', 
  responseFilter: {
    array: 'getParticipantsResponse.participant', 
    filter: 'personalPagePrivate == false'
  }
});

The result should be that the response data object passed to getParticipantsCallback should not contain any participants whose personal page is private.

The filter should allow for positive or negative statements. For example, the following should work as well:

luminateExtend.api.request({
  api: 'teamraiser', 
  callback: getParticipantsCallback, 
  data: 'method=getParticipants&fr_id=1234&first_name=John', 
  responseFilter: {
    array: 'getParticipantsResponse.participant', 
    filter: 'personalPagePrivate != true'
  }
});

Using a modern (supports CORS) browser (and a Tomcat server) with your new "sign up" example, it appears there is a flaw with the auth token request function.

At present, it doesn't properly append the 'CRConsAPI' string if the settings specify HTTPS.

Changing the line (276) as entered below fixes the issue:
url: settings.useHTTPS ? luminateExtend.global.path.secure + 'CRConsAPI' : luminateExtend.global.path.nonsecure + 'CRConsAPI',

Foundation 5 has been released, and it no longer uses Zepto.

Allow for setting locale using luminateExtend.init/luminateExtend.global.update. Supported locales include:

en_US
es_US
en_CA
fr_CA
en_GB
en_AU

When a locale is provided:

1. The locale session variable should be set.
2. The locale session variable should be appended to each request made using luminateExtend.api.request.
3. luminateExtend.utils.simpleDateFormat should use the appropriate default format for the locale.

Test is failing when setting luminateExtend.global.locale to a locale that uses a non-standard (M/d/yy) date format.

it("given null pattern, should honor locale setting", function() {
  luminateExtend.global.update('locale', 'en_GB'); 

  expect( sdf(dateObj.unformatted, null) ).toBe( '31/1/70' );
});

console.log("expect( '%s' ).toBe( '31/1/70' )", sdf(dateObj.unformatted)); 
// logs: expect( '1/31/70' ).toBe( '31/1/70' ) 

The most common reason to use the api object is to make a request. As such, luminateExtend.api should be an alias for luminateExtend.api.request.

When luminateExtend.api.request is called with requiresAuth set to true, and no auth token has been defined, the method uses luminateExtend.api.getAuth to get a token before proceeding with the request. When the request uses the hash transport, this isn't necessary -- luminateExtend_server can itself get an auth token. Doing so will eliminate an HTTP request and improve performance.

This private method should be moved to luminateExtend.utils so that it can be used outside of the core library, i.e. in a plugin.

As of the Luminate Online Q1 2013 release, the API will now return the Access-Control-Allow-Credentials response header on pre-flight requests, allowing for sending cookies when making a request.

With this change, modern browsers should use AJAX with the withCredentials property set to true on the XHR object, in lieu of the current postMessage polyfill.

This will build on work done in v1.2 to allow for parsing tags to display constituent information.

One should be able to display a Survey on an external website using something like this:

<luminate:survey id="1234"></luminate:survey>

Drupal ships out-of-the-box with jQuery 1.4.4, but luminateExtend currently requires jQuery 1.6.4+. While there are options for upgrading the version of jQuery used in Drupal, none of them are terribly simple. This issue will be used to track the changes to luminateExtend required to allow for backwards compatibility with jQuery 1.4.4.

• luminateExtend.api.request() does not currently work with jQuery 1.4.4 when making a cross-domain request where requiresAuth is true. This is because the request method uses the xhrFields object available in jQuery.ajax as of jQuery 1.5 to set the withCredentials property to true. The request method will need to be enhanced to include the sessionCookie as part of the request URL when the version of jQuery is < 1.5.1.
• The JavaScript included with the example AHS site currently uses jQuery.on for event handling. It should be updated to use jQuery.submit, jQuery.click, etc.

jQuery 2 should be used in modern browsers, while jQuery 1.10.2 should continue to be used in IE8 and below.

For modern browsers that support CORS, luminateExtend.api.getAuth should be updated to use the CRConsAPI getLoginUrl method in place of the current luminateExtend_server PageBuilder page.

The capitalization of the months March and May as defined in formattedMonthNames are being override by the regular expression replace:

formattedPart = formattedPart.replace(/MMMM/g, formattedMonthNames[Number(dateParts.month) - 1])
                                     .replace(/MMM/g, formattedMonthNames[Number(dateParts.month) - 1]
                                                      .substring(0, 3))
                                     .replace(/MM/g, dateParts.month)
                                     .replace(/M/g, oneDigitNumber(dateParts.month))
                                     .replace(/march/g, 'March')
                                     .replace(/may/g, 'May');

This problem was noticed while running the tests for the es_US locale and prevents the test from completed successfully since expect( 'Mayo' ).toBe( 'mayo') is false.

@noahcooper Do you remember why this is this way?

Noah,

I have some questions regarding interacting with the library after a submission is pushed to the API. I can see the JSON returned from Convio's Donation API, so I know the form (using the .bind method) is succeeding/failing correctly but I'm unclear on how I need to structure a callback to interact with that data.

Thanks!

Need to add test coverage for luminateExtend.utils.simpleDateFormat.

Some examples of patterns we should test:

No pattern (should result in default of 'M/d/yy')
'M/d/yy'
'MMMM d, yyyy'
'EEEE, MMMM d, yyyy'
'EEEE, MMMM d, yyyy, h:mma'
'h \'o\'\'clock\''
'h+3:mm'

There are several common use cases where custom event subscription could prove useful when working with the API.

In v2.0, initial support will be added for a set of events including login and logout. For example, something like the following could be used to display an "Edit profile" link whenever a user logs in, and hide it when they log out.

$(document).on('luminateExtend.login', function() {
  $('#editProfile').show();
});

$(document).on('luminateExtend.logout', function() {
  $('#editProfile').hide();
});

In order to simplify the process of adding components to external sites, the library should provide a method for parsing "tags" using the API.

In v1.2, the first tags will be added for displaying constituent info. Under the hood, this will use the getUser method to retrieve the logged in user's data.

For example, something like the following should show the logged in user's first name:

<luminate:cons field="name.first"></luminate:cons>

Future versions of the library will include comparable tags for things like embedding Surveys and Action Alerts.

In IE, under Tools -> Internet Options -> Advanced, there is an option "Enable native XMLHTTP support" which is checked by default. If a user has unchecked this option, then window.XMLHttpRequest is undefined. In v1.4, the init method was updated to use an instance of XHR to test for CORS support. This needs to be wrapped in a test to first confirm that window.XMLHttpRequest is defined.

The library currently requires jQuery 1.7 due to its use of jQuery.on() in several places. The version of jQuery automatically included in Luminate Online, however, is 1.6.4, which pre-dates jQuery.on(). The library should be updated to fallback to using jQuery.bind() if jQuery.on() is unavailable, thus allowing the use of earlier versions of jQuery.

jQuery 1.11 and 2.1 are currently in beta. Once they've been released, luminateExtend_server should be updated accordingly.

The options object passed to luminateExtend.api.request currently only allows for making a single API call. In order to simplify the process of making multiple calls, the method should optionally allow for an array of options objects to be passed in. One should be able to make multiple requests either synchronously or asynchronously.