I would like to know more about SCORM.
Ive beeing studying moodle module and the SCORM.com documentation but im not arriving to an aproach myself. As far i can tell steps are:
Upload to LMS a SCORM package
Develop a player that contains some controlls to browse the package
Provide a javascript API, called API for SCORM1.2 and API_1484_11 for SCORM2004. Implement then "at least" some basic calls to the API: Terminate, Commit, Intialize, etc. These functions will be called from the packet.
On the player open the package using a frame. ¿Any alternative?
Ive done this all but im not able to make it work. Im just writing this to make sure these are the correct steps for an LMS-SCORM integration.
So, basically my situation is that by the point of view of an LMS, how to show the packet without frames, and how to retrieve data from packets using PHP and javascript.
Maybe im pretending too much but better thing would be to make all types of SCORM packets to work.
Thanks all in advance!
Those are the basic steps, but the devil is in the details. It isn't really enough to only implement '"at least" some basic calls' unless you are producing all of the content that you will play. This is because you can't really know which of the runtime API calls will be made by a given piece of content. Also note that SCORM2004 has a whole sequencing implementation that is needed in order for the course to display and load the proper SCOs, etc.
Generally you can't really implement SCORM without frames (iframes do work), short of popping up new windows for all content which isn't ideal. This is because there is a pre-defined search algorithm the content will be using to locate the SCORM JS API(s) and that algorithm is designed to walk the tree of windows in the browser to locate it. Without frames (or separate windows) this algorithm won't work.
As far as the data, the "packet" (or SCO) is communicating via the JS runtime API so the data is being provided to the player via those calls. It is up to the implementer to decide what to do with that data so that the LMS can make use of it.
Writing a SCORM implementation, particularly a 2004 one, is a non-trivial pursuit.
Related
I would like to write a 3D application using Golang, my favorite programming language. However, I would prefer not to use native OpenGL directly as the graphical frontend as this would entail a larger learning curve than I'm willing to tolerate. Additionally, I don't really want to use a Golang game engine like go:ngine.
After doing some research I found out about the amazing WebGL Javascript library three.js and I was so intrigued that I completed an introductory Javascript course in a few hours. I'm not really a web developer at all, so I'm wondering how practical it would be for me to write my application primarily in Go but with a three.js frontend.
Some specific questions:
Is it worthwhile / practical to use Javascript/three.js as a frontend to a Golang server like this?
If it is worthwhile, where can I look to learn how to integrate the two cleanly?
If it isn't really worthwhile, which alternatives do I have?
Thanks, any response appreciated.
Edit:
Do you plan to make operations on geometry in Go, possibly in realtime and communicate with your Javascript layer using Websockets?
Yes, this is what I'm thinking now. I'm intending my (Golang) program to generate streams of vertices and triangles based on a few parameters from the user. Each "structure" is generated all at once after the users supply their parameters (which I see as slider bars + input boxes on a Javascript frontend).
Here's an example of something the Go program might generate, plotted in GNUPlot:
(source: alexozer.com)
If this is the case you underestimate Javascript a bit. You should write most of your application in Javascript and use Go as a classical backend service layer like user accounts, persisting state, etc.
I'd be fine with doing that, except for these reasons:
The core generating process fundamentally depends on Goroutines and channels
I know close to nothing about web development, including frontend and backend
So I suppose I'm asking about the implementation details of one of these three possibilities:
Writing most of the program, including the generator, in JS, and a minimal backend in Go
Writing most of the program in Go and using JS just as a graphical frontend
Something else?
I recommend leaving out the whole Websocket aspect because it's only a possible optimization (and maybe not even that).
If you need to depend on Go's concurrency model then go for it, write your component in Go, then a Webserver in Go that takes parameters coming from an HTML request, uses them to compute the result and sends back the data in a JSON format.
On the frontend you will then only focus on sending this request when the user changed a parameter and for displaying of the JSON data you can use ThreeJS right away.
You'll still have to learn a bit of web development and Javascript though. But hey, they say the web is the future ;-)
I think it's the way to go for your case because your application operates in a quite strict request-result way.
The answer to your question depends a lot on where exactly you plan to draw the line between your Go component and the Javascript component. From the way you describe the problem I get the feeling that you want to write most of your application in Go and use JS only as a display layer? I wouldn't recommend doing that.
To rephrase my question: Do you plan to make operations on geometry in Go, possibly in realtime and communicate with your Javascript layer using Websockets? If this is the case you underestimate Javascript a bit. You should write most of your application in Javascript and use Go as a classical backend service layer like user accounts, persisting state, etc.
I might be able to give a more specific answer if I know what exactly you plan to do.
I have been searching for an answer to this problem now for several weeks. I also previously tried to research this a few years ago to no avail.
Problem Summary:
My company has developed a web-based data analytics suite for a major beverage distributor. They have recently asked for a feature that allows the user to print or download a visually pleasing version of the rendered app as a PDF. I have had no luck in finding a solid, controllable, or reliable method to do this. I was hoping the stack community might be able to point me in the right direction.
Current Tech Stack:
Plack servers
Perl base on the Dancer framework
Standard web dev front-ends: HTML5, CSS3, Javascript, Jquery/UI
Client is using IE9/10 and Chrome.
Attempted Solutions Summary:
Obviously I started with the window.print() and tried to control what printed using classes and a specialized print.css but the output was still awful.
I looked in to pdfmachine and pdfbox and even contacted Adobe's acrobat development team directly to see if they had an out of the box solution our company could purchase. I was informed that such a product would be counter intuitive to their desired business model of putting an acrobat subscription on each client computer rather than a single server side application.
I have extensively searched the stack articles but did not feel that the articles I found covered what I was looking for.
At present, I am all out of ideas and am hoping somebody out there has had better luck at this than I have.
tl;dr = I need a pdf version of the rendered output of a complex reporting app.
Thanks for your time stack, I appreciate it.
A solution I have used in the past is to use PhantomJS running on a server to generate the PDF for download/email. Usually if the content is sensitive the server (that handles authentication) would provide a single use viewing token that is then passed to a PhantomJS process. It loads the URL with the viewing token then saves as a PDF.
Further info on Phantoms screen cap API can be found here on GitHub.
https://github.com/ariya/phantomjs/wiki/Screen-Capture
Is it something you can create in Perl using PDF::API2 or PDF::Create? You can load and modify and existing PDF (handy if you want standard headers and footers), and then insert the relevant content. The learning curve can be a bit steep, but simple reports should be easy enough.
See PDF::TextBlock and PDF::Table too - they are great little helpers.
Consider this service http://pdfmyurl.com/ . I try to use many perl modules, but they dont satisfy my problems.
I'm working on a tool that will require 'listening' for a response from the server.
Currently I've got the page using JQuery to request a URL and respond based on it's output.
I do that every couple seconds.
However, as there will likely be hundreds of people using the tool all at the same time, that could be a pretty big server load.
Is there a way I can create a 'listener' that will notify the loaded pages when a change happens instead of constantly querying the server?
I haven't really been able to find much on Google (probably not searching for the correct thing) so hopefully someone here will know exactly what I'm talking about.
Thanks in advance for your quick responses!
You are looking for technologies named Comet or server push. There are several different implementations of this problem, typically involving long-running, but idle HTTP connections. Check out Atmosphere (in Java) or various other libraries.
Also make sure to have a look at web sockets (new HTML5 technology).
See also
COMET javascript library
Anyone knows a good tutorial/js plugin to create a multi user html5 sketch web application?
Would be nice to have cross browser compatibility, preferably without any tools that need to be installed server side.
If the latter is not possible, I would also be happy if the application just saves the user x's sketch so that next time someone loads the app, it would show user x's sketch on startup.
Thanks for your advise.
PS. I have looked at Mr. Doob's, he uses node.js, unfortunately my hosting does not support this just yet. Hence I am asking for a solution that need no server side installation. Also the multi user drawing pad by Union Platform seems to fit the bill, but unfortunately it also requires something to be installed.
If you're willing to shift to a new web host for this application you can use Heroku. Heroku is free and supports Node.js.
I created a multi-user Agile project management whiteboard using WebSockets and Node.js and found a 624% increase in requests per second vs using HTTP. I use MongoDB on the back end which allows you to store data as serialized JSON... this means you can send JSON between client <-> Server <-> Database with no parsing (very fast).
Hope this helps!
The reason Mr. Doob's implementation uses Node.js is because node is great at this kind of things. Since this is going to involve delivering realtime changes to different users, your best bet is to use Comet/Ajax-Push/Longpolling. And if you want to support multi-window usage(multiple browser tabs having your sketchpad), you would need to implement http connection pooling to get around the connection limits set by browsers as per http standard.
If you can't use websockets which are fairly new anyways, Then I would suggest using ajax polling of some sort. Basically use ajax calls based on a delay.
This wikipedia article shows some of the various options you should do further reading into.
http://en.wikipedia.org/wiki/Comet_%28programming%29
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.