We Keep Coding

Use SCORM runtime API without LMS?

I am new to SCORM and have been given an assignment to integrate SAP Workforce Performance Builder exported SCORM (can either be 1.2 or 2004) content into an existing PHP website.
To put it simple, I need to be able to display the exported SCORM material in the browser (I can already do this), and be able to get the statistics through the SCORM runtime API.
I understand that I will need to make use of an LMS to allow communication with the SCO through the SCORM runtime API. I have looked into several open source LMS's, but haven't found a good solution for my purpose. The problem is that a lot of these LMS's are designed to run on the domain of the provider, and have built in tools to follow up on users' progress and scoring.
What I'm looking for is a simple, lightweight solution to be able to interact with the SCORM runtime API, so I can fetch the time a user has spent on a course, his score, etc. I will insert the gathered data into my own database, and code the backend where results can be evaluated myself, all I need is a way to get to the SCORM data.
I feel like I'm missing something, as surely you don't need an entire LMS implementation to simply listen for the basic 8 SCORM API calls, and log the results? Any help or a nudge in the right direction is greatly appreciated!

If you just need to mimic an LMS, providing a pseudo SCORM API so the course can 'speak' to your PHP site, try Claude Ostyn's SCORM Test Wrapper. It's pure client-side JavaScript, as lightweight as you can get with SCORM.
In a nutshell, Claude's test wrapper provides a simple SCORM API for the course to connect to. It receives communication from the course, which you can handle however you like. No backend code is provided; if you want to incorporate with a database, you will need to modify the wrapper to push/pull data from your site's database (this is typically handled via AJAX).
Once you build out the data store, you can make your site behave as an LMS, enabling the site to launch SCORM courses, and enabling the courses to send/receive data to your site via the SCORM API. No LMS or 3rd-party server required.
Notes:
There is no support for unzipping packages or reading manifests. (I suspect you're not interested in going that far.)
SCORM also supports sequencing and navigation, which go way beyond simple JavaScript wrappers. If you need to support the sequencing and navigation features, you'll need to grab them from an existing open-source project (not easy) or pay a 3rd party like Rustici Software (SCORM Cloud). I suspect the content you create via SAP will not use any of SCORM's sequencing or navigation features, so you'll probably be OK.
Claude passed away a while ago, so he can't support you. Shout out to the guys at Rustici Software, who have preserved the site for the SCORM community.

From the courseware's point of view, it is just using javascript to call functions on an API or API_1484_11 object. If you can write the javascript code to sufficiently ape the interface, and store/return the necessary data model elements, then you don't need "an entire LMS implementation".
You need to carefully read the Run-Time Environment documentation though.
If you only ever plan to use it for running SAP Workforce Performance Builder produced courseware, then you can implement enough or the data-model to make that work correctly (although I've seen this done, then people surprised/confused/angry when other SCORM compliant courseware does not work, so beware.)
(Aside) You also need a reliable way to install/update your courseware packages from a PIF zip file. Again, for dealing with courseware from a specific content creator and not needing to write a full blown generic interface, you can just pick out the bits of the imsmanifest.xml file you need.
(Digression) Having written the courseware side of the interface a few times, I've seen interesting gotchas in various LMS implementations of the API, including things like returning the boolean true or false instead of a string "true" or "false" which can catch you off guard. May favourite so far is an LMS that truncates the cmi.suspend_data at the first newline character. (Actually, the implementation was that inept that there was a bug in their bug, and it also chopped off the character before the newline as well.)

You'll mainly want to capture, maintain and enforce the Student Attempt Object. I've used this in a JSON format now for a while, and you can take different approaches to how you store information collected by a Shareable Content Object. Normally people pluck the parts they need vs. trying to go 100% into full SCORM support so these types of questions are popular.
By creating the SCORM Runtime for either SCORM 1.2 or 2004 you'll mainly be providing those methods to build the data from the student session.
This can look like https://gist.github.com/cybercussion/4675334 (based on Unit test data for SCORM 2004)
You attempt to route your calls to your server side. Normally this results in a lot of lag. And I normally don't advocate it as an option.
You cache the student attempt, but you post the whole JSON object on a commit call. This normally results in a larger data post which can blimp on you if there are a lot of journaled interactions.
You take a hybrid approach and only post the data thats changed and merge that on your server limiting the data blimp issues that could occur.
I have a bunch of info up on the wiki here too https://github.com/cybercussion/SCOBot/wiki as well as a lot of sample code, tips etc...

Web browser Text annotator to annotate documents

I thought to bounce this idea from people here:
I have to build a light-weight text annotator which will be later embedded in one of website.
The text annotator will be used to collect manual annotation for various documents from various users (i.e. human users which are logged in to that website). User will be rewarded based on their labor.
Wondering if anyone has already done similar thing or if someone has any thought on this task.
As per my research so far, somehow using CKeditor for this seems good idea.
This is totally new to me and I am also new to JavaScript (but hardcore with Java core :) ). Any assistance will be greatly appreciated.

The Firefox addon Semantic Checker retrieves semantic data such as this from websites. There are also several JavaScript libraries which facilitate creation of such metadata:
RDFaCE
createjs
annotate.js
alohaeditor with WAI plugin
vie.js with backbone.js
References
Commercial Benefits of Accessibility | CKEditor.com

Pure JavaScript-based clients

I would like to know, how powerful/viable are JavaScript only clients based on say, GWT/gxt/vaadin, when compared to DHTML clients such as those made with wicket, tapestry, click etc?
My boss has insisted on using GXT (due to its nice colors and theme) on a project that will most likely become very big with lots of screens. I am against the idea of a javascript only client, especially when the javascript is generated from Java code. I have tried to advice him that we use something like wicket whereby we construct the screens with html but put in ajax where and when neccessary.
How viable is such a JavaScript client? I understand that JavaScript was intended for minor web page enhancements, and not all browsers, especially mobile devices have complete support for JavaScript.

Yes, it is viable for certain applications. Consider Gmail, Google Docs and Google Maps as typical applications where this works, and is probably the most feasible approach.
Some rich UI JavaScript frameworks, such as Ext JS also rely on this technique.

I've built javascript only web apps for ages.
First in SAP projects for big multinationals. And now on a new project:https://beebole-apps.com?demo
So yes it is powerful and viable.

Javascript-only webapp can be extremely powerful, and it's viable for certain applications, say, an Instant-Messenger webapp?
You mentioned that there are lots of screens in your web-app. One of the advantages from GWT/GXT is the fact that you can unit test your UI-layer with JUnit. This is an extra testing you can do on top of, say, Selenium. This is essential if you'd like to make UI testing a part of the continuous integration process, and, as the team grows, you'll definitely want to have tests around to make sure everything works (At least in theory.)
However, if what your boss meant to do is to build an in-house, custom Javascript engine using GWT's JavaScript Native Interface (Link), then I'm not sure...
Another advantage with GWT-like-engine over Wicket is that you can rely on HTML-code-gen to generate standard-compliant (In theory) HTML code. With framework like Wicket, it is hard to ensure every single developer on the team to author good HTML code - Especially when the team gets bigger.

Disclaimer: I'm a member of the Vaadin team.
Our Timeline demo is a good example of what can be achieved with Vaadin and GWT in client side, but I think all of the options presented in this discussions are viable given enough time.
Since you are going to start a big project you should build a simple proof-of-concept app with each of the relevant frameworks. If your PoC includes at least some of the more complex use cases you'll probably can make a pretty informed choice based on the experiences you get while building them.
I urge you to at least evaluate Vaadin. With it you write only server-side Java code and Vaadin will create a slick and professional browser UI for you. Client side can be easily extended using standard GWT (also pure Java), and there are no HTML templates, tag libraries or XML configuration involved at all. A Vaadin UI is fully Ajax'ed and lazy loading out of the box, and it easily integrates with any server side technologies, eg. Spring.
In addition to the development model advantages you get top-notch documentation, a bi-weekly update schedule, a very lively community filled with helpful experts, 100+ useful open source add-ons, and a 10 year old backing company with help on hand should you need it.

What's a good way to merge remote, standalone web apps into a virtual site?

We have a few dozen web apps on multiple servers/platforms owned by 5 teams at our company and want to merge them into a single site. The UI part is straightforward - a common header with login/status info, tabs for the major sections of the site, and yui menus for navigation within a section.
The hard part is finding a way to do this while making minimal changes to the existing apps, which are easily breakable and a pain to deploy. We want to minimize updates to the apps and try to get it right the first time.
The only working solution we have now is to include a Javascript file to write the site header/navigation at the top of the page, which lets us easily deploy changes to all of the apps:
script src="..../site/include?appid=xxx" // app id determines which tab/navigation to display
Is there a better way to do this, especially one with better performance than remote dynamic Javascript that writes the entire page header? Are there existing frameworks to simplify this?

Consider using a portal framework like uPortal. You could aggregate all those webapps -- no matter what technologies they're written in -- by leveraging a web proxy solution.
This suggestion might be overkill if your needs are really & truly simple; but uPortal (and others) provide scores of additional functions -- like administration, statistics, SSO, and integrations with other platforms and services -- that quickly add to their attractiveness.

Why should I use Flex?

In a recent conversation, I mentioned that I was using JavaScript for a web application. That comment prompted a response: "You should use Flex instead. It will cut your development time down and JavaScript is too hard to debug and maintain. You need to use the right tool for the right job." Now, I don't know too much about Flex, but I personally don't feel like JavaScript is too hard to debug or maintain, especially if you use a framework. JavaScript is also one of the most used languages right now, so it would seem a better choice in that regard too. However, his reply piqued my interest. Would Flex be a good choice for a distributable web app for which 3rd party developers could build add-ons? What are the advantages of using it vs. a JavaScript framework? What are some of the disadvantages?

I have recently started to develop Flex applications, and I personally find it a refreshing framework for the web.
You get a state-ful application that runs completely client side. You get no worries about cross-browser portability that you do with JavaScript, and you get some really neat things such as effects, graphing, and rich user interface components.
Flex also makes it easy to communicate to webservices and the XML parsing via ECMA is insanely powerful and simple.
I'm glad I have made the switch. As far as how popular it is...I'm not really sure, but I am fairly certain that the developer base is expanding rapidly.
The only real disadvantage I can think of is a flash player requirement, but I would say it is pretty safe to assume that most browser support flash player; even konquerer in Linux is supported; much more so then a silverlight runtime (which I NEVER plan on installing)

Here is my experience: you really need to consider 2 things separately - development and the end-user experience. Flex shines in the first area:
ActionScript is a nice mixture of Java and JavaScript so you get a familiar language with strong support for OOP
debugging is far easier than what you can achieve in JavaScript
Flex framework is component-oriented and event-driven which helps in creating rich user interfaces (HTML was not really created to support application UI scenarios)
On the other hand, the end-user experience is worse when running a Flex app compared to an AJAX app. First, you need to have Flash Player installed but this is probably not an issue for most computers today. Bigger problems are with usability - Flash Player handles all UI interactions (instead of a browser) so the password manager doesn't work, text fields don't remember previous entries, Ctrl+T and middle-clicking doesn't work, text search doesn't work etc. etc.
My advice would be - if you are developing an application (rich UI, relatively separated from the rest of the web), go for Flex as it will save you time, money and will make your users happier by providing richer functionality and shorter periods between new versions. On the other hand, if your application needs to be tightly integrated with the web and you want your users to be able to use features of their browsers, go with AJAX.
Nice example is Google Docs vs Buzzword. Buzzword is much more feature rich (for instance, text can flow around an image from both sides which is something you could never ever achieve in DHTML) but Google still decided to go for an AJAX version because they are the "web company". There is no right or wrong in doing it the one or the other way, it's just different and it's important to consider who your end users are.

I would push you towards standard web development technologies in most cases. Javascript is no longer a great challenge to debug or maintain with good libs like jQuery/Prototype to iron out some of the browser inconsistencies and tools like Firebug and the MS script debugger to help with debugging.
There are cases when Flash is a better option, but only in cases where you are doing complex animations. And, if you are willing to invest the effort, most animations can be achieved without resorting to flash. A couple of examples...
Flash content is not as accessible as other content.
This will not only affect people with out flash, but also search engine spiders. There may be some hacks to help get around this now, but I think that most flash content will never be indexed by google.
Flash breaks the web UI.
For example:
If I click my mouse wheel on a link,
that link is opened in a background
tab. In a flash app there is no way
to simulate this behavior.
If I select text in my browser and
right-click I get options provided
by the browser that include things
like "Search Google for this text".
In a flash app those options are no
longer there.
If I right click on a link or an
image I get a different set of
options that are not available in a
flash app. This can be very
frustrating to a user who is not
"flash savvy".

GWT lets you do the same stuff as Flex for the most part, and handles all the browser compatibility issues, AND lets you code/debug in Java with your favorite IDE.
All without having to learn a new language (or pay Adobe $$$ for the flex IDE you'll need to do anything real).
Flex has some prettier UI widgets than GWT has out of the box, but there's a ton of 3rd party widgets (such as GWT-EXT-JS) you can use - or, you can use your existing favorite JS widgets with GWT.
Check it out if you haven't: http://code.google.com/webtoolkit/

I can't be sure if it was myself, or someone else who made that statement but I would definitely be one to say 'use the right tool for the job'.
Flex has a large community behind it, and is well hyped by Adobe's platform evangelism team. Now, as far as replacing JavaScript, that sounds like a very broad spectrum discussion point. Flex is not a replacement for JavaScript. What it does, it does well, however. That is, 3D, drawing, and data rendering whether in chart or table form. Flex also has the power of ActionScript 3 behind it which allows you to do much of what Flash does in cooperation with the MXML frontend components without ever touching the timeline or keyframes.
In a way, Flex is the .NET of Flash and Rich Internet Application development. It uses the same datasource concepts, and component focused design structures which make it easy, and fast to develop in.
The real question is, what are you trying to achieve? What is the end goal?
As to the debugging point, Flex has a true debugger and profiler within the Flex Builder IDE. JavaScript, unfortunately, has different syntax and execution between browsers due to the nature of JavaScript engines in modern browsers. Flex, because it is essentially Flash, uses the same rendering engine in all browsers due to the use of the Flash plugin.
Hope that clears a few things up. :)

Flex has a lot of extra overhead:
New language
Clients must have flash installed (might need to install, might not be able to)
Clients must download flex framework (few hundred kilobytes)
Flex content is not indexed by search engines (contrary to what Google might claim)
Flex has one main advantage:
- Better at building rich interfaces (see Picnik.com, etc)
For example, in Flex, it is easy to create a custom styled dialog box, complete with drop shadows, inner glows, animated open, whatever you might want.
In summary, use Flex if you need the extra richness.

Aside from what's already been mentioned here, another major difference is that JavaScript is dynamically typed and ActionScript is statically typed. Whether that's good or bad will depend on your point of view :).

If you want your web application to look like it's not a web application, Flex is pretty good. You also get to sidestep all the messiness of making HTML+JS look like a real app. For something which is essentially a website, Flex might not be the best choice, but if you really want to write an application which happens to be accessed through the browser, it's quick to develop with and gives great looking results.

You should try Google Gears instead. Create your application, add some Gears to it, and you can greatly increase the speed (and reliability) of your application.
http://gears.google.com/
Essentially Google gears gives you access to two useful things for any application: offline data storage, and native threading control (allowing updates/computations to run in the background and not slow down the users computer).
The really nice thing is, you can use whatever Framework you like for your application, as long as data storage/retrieval and server side communication is handled with JavaScript.
It also allows you to cache whatever files client side you want, which is especially useful when you want to avoid that 'flickering' look in the browser while some needed image is being downloaded by the browser.

A few reasons to consider Flex:
The control library is much richer in Flex than anything you can do with JS/DHTML. The charting controls are killer for business apps and things like the DataGrid / AdvancedDataGrid are pretty well ahead of anything you can do with HTML.
The Flex framework was designed for building applications. It abstracts away the "frame-based" concepts in the Flash Player to really make it easy to build apps. It has a well-designed component hierarchy that makes it easy to extend any of the standard controls. It also has a pretty intuitive event model for handles user inputs and makes it easy to have any of your controls dispatch custom events that can bubble up to parent components or get routed through a central event dispatcher. While it may be possible to do this with JS/DHTML, I don't think it's nearly as easy and it certainly wasn't designed for it.
You can take a Flex application and quickly deploy it to the desktop with the AIR runtime. AIR also offers additional APIs for things like local system access, embedded SQLite DB, etc. Gears offers something similar but it does require a browser. Granted, AIR requires the AIR runtime but at least it's purposed towards building desktop apps.
You can build a very rich, very sexy UI that will knock your users socks' off. As programmers we might not care about UX but our users do. Part of the reason why Apple is having a lot of success lately is because they really value UX and users/consumers are taking note of this.
The biggest con I think is that if you are really used to Java or C#, the ActionScript language will seem a bit limiting. If you're comparing it JavaScript, it's at par or maybe slightly better.
A lot of people will rail on Flash Player (or AIR) because it's not "standard-based." If we were only willing to use sites that were 100% standards compliant and free of plugins, we wouldn't have YouTube today. Or pretty much any other site that does interesting data visualization you can't do with HTML/JS (or at least, not with a sane level of effort). Adobe has been pretty progressive in opening up the Flex framework, Blaze DS (for backend Java development), publishing the AMF spec and starting the Open Screen Alliance to push Flash Player to mobile devices. Flash Player, Flex, Flex Builder and Blaze DS all have public JIRA bug trackers. I'd say there is a good chance that Flash Player itself will be open source within the next 2-3 years. I think Adobe is continuing to move towards being very open and that the criticisms of the platform being "closed" and "proprietary" are becoming less relevant. I think if developers approach Flex/FP with an open mind that they would really be impressed with how it all fits together.

This comparison table was good enough to make me decide what to use . I prefered javascript:)
http://askmeflash.com/article_m.php?p=article&id=11