I've been asked to do Facebook apps. Before I commit to anything, I want to know how easily a game can be moved to Facebook? (I'm completely comfortable making games in JavaScript in the browser.)
Does Facebook filter the JavaScript in some way? Can I use jQuery or other JS libraries? Can I do animation by altering the DOM on the fly? Is it best to go with an iFrame or use FBML?
I've done some poking around the Facebook dev site. But I'd like to hear from someone who's done it what the learning curve is like.
JavaScript in the Facebook context is different inasmuch as it all will get rewritten as it goes through Facebook. To get a sense of the differences (of which there are many), start with the FBJS Documentation. The getting started guide is a good primer.
The site that will become your bible is wiki.developers.facebook.com, it is canonical in terms of the FB platform. Additionally, as we all have come to know and (love? hate?) the Facebook platform is a moving target, so it's useful to keep up with things via the Developers Group on Facebook. I also like the blog Inside Facebook.
Most providers who allow developers to
embed JavaScript within their domain
force developers to use iframes to
sandbox their code. Facebook has taken
a different approach to this problem.
JavaScript that you give us gets
parsed, and any identifiers (function
and variable names) get prepended with
your application ID. For example, the
following code block:
function foo(bar) { var obj = {property: bar}; return obj.property;
}
becomes:
function a12345_foo(a12345_bar) { var a12345_obj = {property: a12345_bar}; return a12345_obj.property; }
This creates a virtual scope for every
application that runs within Facebook.
From there we expose certain
functionality through a collection of
JavaScript objects that allow you to
modify your content on Facebook. Our
objects are made to mimic the
functionality of JavaScript as closely
as possible, but it may take some
getting used to for people who are
already adept with JavaScript.
Many items which are simply elements in plain JavaScript must be accomplished with special method calls in FBJS. For example when referring to a form field's value in JS you use .value, whereas in FBJS you need to do .getValue(). It's these differences that prevent simply cutting and pasting JS from elsewhere into Facebook.
That's a basic primer. That should get you started. Best to you!
The simple solution is to wrap your entire game inside an iFrame. FB itself filters out a lot of javascript calls - basically, anything involving the window or document objects probably won't work.
Not too hard I would say, since you already have the ability to program a game, it should be fine for you to program a facebook app, as well as migrating a game to facebook.
as far as I know, with FBML your javascript will be rendered useless (yes your javascript will be filtered)
so you will have to use iFrame, which your javascript will remain functional (as long as your javascript doesn't touch the fbml tags)
Facebook api documentation is notoriously bad.
Related
I've made a tool take people can use and its made in Javascript.
They generate the code and then paste it into their webpage code.
I am just wondering how would I go about making it work in forum posts, or other site posts or do the websites normally block this sort of thing?
Would it be possible to convert it for social media sites also? Like have it so the users can interact with it inside posts? Thanks!
So first a warning: DO NOT DO THIS THE WAY THAT YOU HAVE IT RIGHT NOW
You are forcing people to inject a script directly into their website directly from your servers. This script sets and users global variables and can break other things. I would be very very angry if someone added something like this to a site I ran. For example your script creates a function called clicked() in the global scope. What if the site already had a function named that on it? Then all of a sudden that site breaks. It is possible to do this without these issues (see how twitter buttons work for example) but it still has limitations.
Doing this in the way you have it set up looks to another site exactly like an XSS (Cross Site Scripting) attack so no, you cannot do this in forums/etc - they specifically disallow it.
Occasionally a forum might allow iframes (they have much better security for the including site). In your case using iframes would actually be a much cleaner solution. Simply have them include an iframe that points to your site. Your site then (using php, .Net, node, perl, whatever server scripting language you want) would reply with the markup that you want. You can pass the parameters you want as parameters in your url.
I started looking at FBJS to build some complex application that has to be within a tab on a fan page. Since my first option of using iframes are out till Facebook puts that functionality in, I have to resort to using the sanitized FBJS.
I was wondering if anyone has done really complicated apps using FBJS? Besides DOM manipulations, how does it stack up against the usual JS?
I looked at the documentation online on the developers page, but all the samples there seem pretty basic. For example, I would need to access ActiveXControls/plugins, generate iframe on the fly and then append content into the iframe, etc. Does anyone think this would be doable in FBJS?
If you need to access custom ActiveXControls you won't be able to do it in FBJS. FBJS obscures global variables so you can't access them. I'm pretty sure that Facebook allows iframe applications in tabs on fan pages though. How are you adding the content?
I would like to know if there is a way of tracking who is using my jQuery plugin by using some javascript code inside the plugin itself. My plugin is being used on different sites, so I'd like to know where it is being used and how many times it is being accessed.
You could just present a registration form for people to fill out before the download the source code, asking them for some basic contact information and the website they'll be using it on. I don't think #SLaks' idea of a 1x1 pixel gif is that bad of an idea, however it does cause additional load on both your server and it's also an additional request for the visitors to all the sites that use your plugin.
Because jQuery plugins are just plain JavaScript code, many people might just remove the part that adds the tracking image, considering it to be an invasion of privacy or just a waste of resources, or for whatever reasons. They may feel like it was trickery or it was "snuck in". Asking for people to register however it a clear demonstration of your motives. It's not sneaky, you're clearly wanting to track usage and I think most developers will understand that.
Even if the registration form is optional it should give you a pretty good feel for who's downloading and using your plugin.
You could create an <img> element in the plugin that points to a server-side script that increments a counter. (This would work across domains)
However, this could be viewed as spying, especially for intranet sites.
It would probably be very controversial; I wouldn't recommend it.
You could easily do a get request to an API on your server. For example just
$.get("http://youserver.com/api/track/");
And then on your server you could see who was it was that used your plugin using PHPs $_SERVER["REMOTE_HOST"] and incrament a counter.
Is Graceful degradation possible for everything? for every javascript and javascript frameworks functionality?
No, it is not possible for everything. There comes a point when you have to decide if you can support a feature with or without javascript, or if it simply can't be done without it (or would take too much time/money to accomplish).
This concept might help you:
For public websites meant to provide information, make sure every essential piece works with/without JS. This includes sales sites, corporate information sites, business micro sites, etc.
If the site is a web application with tools available behind a login, then making JS a requirement makes more sense since you can notify the user of this requirement upon signup/signin. Obviously you should still go as far as you can to make the site accessible for handicapped users.
If you start with a non-javascript webpage, and get the functionality that you are willing to accept, then you can get graceful degradation to work, as you have a lower level that is acceptable, so if you can't get some functionality to work you can just not use javascript for that part.
But, if you absolutely require javascript then you need to decide on a least supported version, and get your app to work that way.
You may find that you will need to be able to replace some functionality that doesn't exist in the browser's version of javascript, so, if you use the string.trim() function but it isn't included, then you need to write it, and use the String.prototype functionality.
If you use unobtrusive javascript then you can test before making any changes to the dom elements to see what needs to be done to get that functionality to work.
If you find a framework that doesn't meet your needs, you will need to replace that framework with your own, rather than having a mix where on some browsers you have one framework and on others you have your own.
It depends what you will accept as functional, if you require a dialog box to pop up on the page and request user input, then no, but if it's ok that the page redirects to an input form then it is.
There are a lot of cool things that can be done with javascript, but with some thought things can usually be functional (but probably not pretty) without.
In my experience, I've yet to find a scenario that can't be solved with graceful degradation. Consider a "to-do list" app of today versus a decade ago. Today, if you would like to order a list of items, you simply drag & drop. A decade ago, you would click a "re-order" button, visit a second page where you would manually modify the IDs for each item for numeric sorting.
I tend to build apps (with a framework behind them, mind you) that already support this structure. Then, with "progressive enhancement" via Javascript, you can simply ease the user's burden in making these changes and still take advantage of the same code in the backend.
So yes, as long as a browser supports cookies for session data, an app can remain entirely functional without Javascript. It will simply be more difficult to use :)
Preamble
So, this question has already been answered, but as it was my first question for this project, I'm going to continue to reference it in other questions I ask for this project.
For anyone who came from another question, here is the basic idea: Create a web app that can make it much easier to create other web applications or websites. To do this, you would basically create a modular site with "widgets" and then combine them into the final display pages. Each widget would likely have its own set of functions combined in a Class if you use Prototype or .prototype.fn otherwise.
Currently
I am working on getting the basics down: editing CSS, creating user JavaScript functions and dynamically finding their names/inputs, and other critical technical aspects of the project. Soon I will create a rough timeline of the features I wish to create. Soon after I do this, I intent to create a Blog of sorts to keep everyone informed of the project's status.
Original Question
Hello all, I am currently trying to formalize an idea I have for a personal project (which may turn into a professional one later on). The concept is a reflective web application. In other words, a web application that can build other web applications and is actively used to build and improve itself. Think of it as sort of a webapp IDE for creating webapps.
So before I start explaining it further, my question to all of you is this: What do you think would be some of the hardest challenges along the way and where would be the best place to start?
Now let me try to explain some of the aspects of this concept briefly here. I want this application to be as close to a WYSIWYG as possible, in that you have a display area which shows all or part of the website as it would appear. You should be free to browse it to get to the areas you want to work on and use a JavaScript debugger/console to ask "what would happen if...?" questions.
I intend for the webapps to be built up via components. In other words, the result would be a very modular webapp so that you can tweak things on a small or large scale with a fair amount of ease (generally it should be better than hand coding everything in <insert editor of choice>).
Once the website/webapp is done, this webapp should be able to produce all the code necessary to install and run the created website/webapp (so CSS, JavaScript, PHP, and PHP installer for the database).
Here are the few major challenges I've come up with so far:
Changing CSS on the fly
Implementing reflection in JavaScript
Accurate and brief DOM tree viewer
Allowing users to choose JavaScript libraries (i.e. Prototype, jQuery, Dojo, extJS, etc.)
Any other comments and suggestions are also welcome.
Edit 1: I really like the idea of AppJet and I will check it out in detail when I get the time this weekend. However, my only concern is that this is supposed to create code that can go onto others webservers, so while AppJet might be a great way for me to develop this app more rapidly, I still think I will have to generate PHP code for my users to put on their servers.
Also, when I feel this is ready for beta testers, I will certainly release it for free for everyone on this site. But I was thinking that out of beta I should follow a scheme similar to that of git: Free for open source apps, costs money for private/proprietary apps.
Conceptually, you would be building widgets, a widget factory, and a factory making factory.
So, you would have to find all the different types of interactions that could be possible in making a widget, between widgets, within a factory, and between multiple widget making factories to get an idea.
Something to keep on top of how far would be too far to abstract?
**I think you would need to be able to abstract a few layers completely for the application space itself. Then you'd have to build some management tool for it all. **
- Presentation, Workflow and the Data tier.
Presentation: You are either receiving feedback, or putting in input. Usually as a result of clicking, or entering something. A simple example is making dynamic web forms in a database. What would you have to store in a database about where it comes/goes from? This would probably make up the presentation layer. This would probably be the best exercise to start with to get a feel for what you may need to go with.
Workflow: it would be wise to build a simple workflow engine. I built one modeled on Windows Workflow that I had up and running in 2 days. It could set the initial event that should be run, etc. From a designer perspective, I would imagine a visio type program to link these events. The events in the workflow would then drive the presentation tier.
Data: You would have to store the data about the application as much as the data in the application. So, form, event, data structures could possibly be done by storing xml docs depending on whether you need to work with any of the data in the forms or not. The data of the application could also be stored in empty xml templates that you fill in, or in actual tables. At that point you'd have to create a table creation routine that would maintain a table for an app to the spec. Google has something like this with their google DB online.
Hope that helps. Share what you end up coming up with.
Why use PHP?
Appjet does something really similar using 100% Javascript on the client and server side with rhino.
This makes it easier for programmers to use your service, and easier for you to deploy. In fact even their data storage technique uses Javascript (simple native objects), which is a really powerful idea.