Problems with adding widgets to the page.
How to handle caching from proxies/browsers ( affects JS/CSS/PHP/(ANY GET CALL) )?
Two ways of making sure we bust from cache is to rename the file or use a QS parameter. Normally this is handled with the a build/deploy process making it very easy. A querystring parameter is appended to the script tag and the version is updated with a value in a config file that is manually changed. The QS parameter forces the browser to follow the GET procedures of grabbing a new version since the URL is different. BUT since we are not controlling other releases, we are not lucky in having all of the controls updated with a new release.
We need to investigate what caching headers are we setting on the server and if we are letting the control developer decide what headers are set for this. (Good overview on caching with aol servers here: http://webmaster.info.aol.com/caching.html) I personally found issues with users on/with aol with my Ajax applications.
Why we need to cache and have proxies? Speeds up the user experience, reduces bandwidth, 'localizes' files for users.
How to handle versioning?
- What do we do to specify a version of a control (hosted and unhosted controls)?
- Do we just force users to use the newest version? What do we do for rollbacks on the control?
- Is there a way to notify users that a control has been updated with a new version?
- Do we somehow create a community/network around a control and the user gets notified that way? (message added to their feeds in the dev/community feeds?)
We might want to be able to host multiple versions of a control? Let the user decide if they want to move to the new version so they can run their own tests on it. I could see a qs parameter added to the widget code specifying the version. We could also say if you want the newest version change the value to "future/upgrade" or leave off the version number. (Caching issue applies to this approach)
The versions also causes issues with the widget code page UI (sort of the sourceforge download page of different versions of an application/file.)
We also have to think about how to handle versioning of JQuery. When they release a new version how do we approve that it gets integrated into our widgets. Do we upgrade the widgets that use it to the new version? Is it a case by case deal with what the release contains? We do not want to force the user to download 4 different versions of a library for 4 widgets.
How to have multiple widgets on the page?
- Loading same js files?
- giving unique ids?
If the user wants to include some widget on the page more than once, we need to make sure that we are not injecting the same "library" code in the page more than once. The "library" code would be the links for JQuery, CSS, and other JS Code needed for the widget. The code that is doing the will need to register some namespace to the page. We than need to register that XXX, YYY, ZZZ was added to the page. When the loader for the next widget loads it can see if any of its components exist from this array.
Do we build out widgets and let the other widget owners figure it out for themselves or do we build some sort of loading code that says to the library author "link to files needed".
Another issue is that we need to make sure that ids do not clash. (divs, spans, tables, etc) (Again would this have to be some sort of registration code in the widgets?) The ids could have something to do with the session.
How to implement Sandboxing?
- Iframe
- Our "FBJS Implementation"
For right now we are going to run the application inside of an iframe for sandboxing. (For those that do not know why we need sandboxing, we do not want a widget author to be able to take control of the parent page/read its contents. Read about Sammy Worm here: http://namb.la/popular/ )
We can go the facebook JS path and do the renaming of the variables. This piece is in development/not fully implemented?
How to deal with Iframe and quirks?
- Talking to parent page is shot
- XHTML 1.0 Strict and XHTML 1.1 not supporting iframes
XHTML 1.0 Strict and XHTML 1.1 do no allow iframes in their specifications. The people that know this are the people that will complain when they find out we throw in an iframe. The XHTML spec REQUIRES that an object tag is used instead. Object tag fails/has major issues in IE6 (I think IE7 but do not quote me on it), but IE also does not fully support pages served up as XHTML (most cases will not load up the page at all) so if that is the case than these developers might have 2 versions of their pages.
Instead of us trying to figure out the doc type (which would be pretty hard) we can add a parameter that says render in XHTML Object mode and spit out an object tag instead of a iframe. OH THE FUN of browser quirks!
How to work with document.write issues?
- XHTML
- Delaying loading of page
- Escaping issues
Just like the iframe issue with XHTML, there are issues with document.write and spitting out tags. John Resig (guy behind JQuery) has a good discussion on it here: http://ejohn.org/blog/xhtml-documentwrite-and-adsense/
The BIG kicker with widgets (ads, trackers, maps, etc) is that they can cause a page to load VERY slow. Now do we make it so our widgets help the developer adding the widget to the page have a faster loading website or do we go the route of the others and document.write away? JQuery has a way to know when the page is loaded. (http://www.learningjquery.com/2006/09/introducing-document-ready) We can tie our code into this and have our components load in a nicer manner. Issue with this is, our stuff loads later than the page. There are a few pros and cons here. Might depend on the widget.
Another thing is when we add tags, we need to make sure that the people are escaping the data correctly. This really ties in when we are talking about customization and versioning.
How to deal with namespace issues (sandboxing fixes this?)
- variables
- functions
- methods
- Objects
- etc!
We somehow need to figure out if namespaces/variable are not going to clash with different apps and different widgets. I am guessing that the sandboxing is going to take care of that so we will not sure into too many problems.
Determining http/https support?
We will first have to support https on our server that the widgets point too.
The widget callback urls (Ajax/JSON/JS/CSS/ETC) need to know what to make the calls too.
The widget generation either needs to ask (checkbox) for https or we make the widget code auto detect it sort of like Adsense does with the http/https check.
How to enable configuration parameters?
- Configs with multiple widgets
- Externalizing include (user does not have to add configs to every page)
If widgets have the ability to be customized we need a way to specify that information in an easy manner.
Very bad option = One option (which can be painful) would be to allow the user to specify the options in a querystring. Now that is nice, but it is not user friendly and the URL does have a length limit, and there can be escaping issues.
The way that it is done now is a div holds a block of tags and it is sent up to the server and the server is rendering it.
The way that Adsense and some other JS solutions do is add another JavaScript tag block under the include where they can set some properties. This is very nice since it is a little easier to handle that fb/os markup.
Problem with the settings and properties is the user has to "copy and paste" the details around. If they make a change on 1 they would have to do it to all. Could show them a way to build a JS file to do it (video trailmap type of thing). If they have a server-side language this is no issue since it would be a server side include.
Another way would be to be able to host details on the server and send up an id that specifies the properties. Than the user can hold data on the server and not worry about setting the details on the client.
How to add security so another site can not copy/paste widget code?
We need a way that our back-end verifies that a widget is coming from a valid page and that someone did not "borrow" the code from viewing the page source. Google does that through an a key registered to that specific domain. That key is a pain in the butt since if you change domains (localhost or 127.0.0.1 or 192.168.1.2) it freaks out saying it is invalid.
The best thing we can do is give a place where they can add a whitelist of domains that are valid. We could do it at a nid level or at a app/widget level? Now how do we check the list on the server? Do we grab the location on the page? Do we look at referers/headers? Both methods are flawed, but better than no protection at all.
Best security would to give the server-side a chunk of code that can register and add it to the page that the widget is on. The widget would check for the code and use that as part of the "handshake".
How to Handle JSON vs Ajax requests?
- JSON Error
- Request does not come back
- timeouts
- Man In Middle attacks?
- (Local server Proxy if available?)
Ajax requests require that we goto the same domain from where the browser is. So if we are in an iframe and the iframe is pointing to our server we can use Ajax to make the calls. If we are not using the iframe, the Ajax call would have to point to a proxy on their local instance and the proxy would have to forward the request. If there is no proxy, than we would have to do the JSON implementation.
JQuery has both Ajax and JSON requests built into their framework so it is a simple call.
The Ajax implementation is the best of the 2. The reason is that JSON gives us no real control over errors, bad requests, timeouts, etc.
Implementing JQuery with "Other Libraries"?
Need to look into this in greater detail for our widgets: http://docs.jquery.com/Using_jQuery_with_Other_Libraries
The link shows how to make JQuery not use the $ sign which other libraries use.
Logging in to widget without leaving page?
A nice feature would be able to log the user in without leaving the page. An idea for logging in would be something like http://Pandora.com with the window. Click on the register button or login (if you have an account) and see how it works. The panels slide in and out when the user performs an action. Runs rather smooth.
Maintaining Session between pages?
If the user is not using a serverside based page (aka basic html) and the widget requires a user to log in there is no way for the server to add the users credentials (session info) into its session. to keep the user from having to log in from page click to page click, we will have to implement a session cookie. If cookies are disabled, than the user is basically screwed.
I am not sure how this will play out with the iframe implementation. Iframe implementation may require that the page post back if we have 3rd party cookie issues with Safari or IE7?
Linking to Google for JQuery?
Google is hosting JQuery up on their site. Reasons and info here: http://googleajaxsearchapi.blogspot.com/2008/05/speed-up-access-to-your-favorite.html
Do we want to do this? Do we expect installers to have access to this library? Do we include the file and give them the option themselves?
Handling widgets that have forms inside of forms?
We need to agree on a way to figure out what to do if a widget has a form and is being included inside a form. We can just not include a form and add our elements, we can add a form to the bottom of the page and dynamically position controls, or we can investigate some other methods. If we are using an iframe, we do not have to worry about this.
Things to agree upon
- Handling Lazy Loading of JavaScript and CSS files?
- appendChild (causes loading icon with FF)
- eval (only can be done with local/proxy call)
- Standard JSON format
- Standard Coding Style
- XHTML/HTML Code Generation
- Client Only
- Server Only
- Client and Server
- JS testing
- Unit tests
- Performance tests
- Memory leaks (drip/sIEve)
- NoScript tag pointing to ringside?
