After much messing around, I have now put up a web page on the sourceforge website, about the SLeD player, it’s at: http://ldplayer.sourceforge.net/. SLeD is the name for the player that we’ve finally settled on!
For info the messing around was because I couldn’t get to log in with the SSH client to upload the files to sourceforge. Turns out that after I changed my password all works fine, even though I was using the correct password to begin with – because it was the same one I used to log in to the Sourceforge website and that was working!
Have also put up the latest version of the authoring wizard tool on sourceforge too, it fixes one (fairly major) bug (!), and includes another demo template.
hmmm – well getting the complex type returned and correctly deserialized was working! but it only worked for an hour or so, then it seemed to stop working and I can’t figure out what’s going wrong! I keep on getting an ‘instantiation exception’ every time I try to call one of the methods. For some reason it tries to be instantiating the ‘CopperCoreAdmin’ class, which is an interface, so it shouldn’t be able to be instantiated anyway – so why is it even trying???! I’ve not changed anything 😉
Anyway, I’ll try for a bit longer to get this working, but if not, when I put the final release up on Sourceforge, I’ll leave it using the extra admin web service installed on the CopperCore server, but I’ll include the code that I tried to use to call the ‘proper’ coppercore admin service, so that someone else can pick this up and have a look – if they like 😉
I think I’ve now solved the problem of having to add the extra web service to the CopperCore install, to be able to get the Player to work. I’ve now resolved how to deal with the complex types returned by the CopperCore web service.
Harrie at OUNL showed me the Web Services Designer Wizard in JBuilderX and using this it generates all the required code for the complex classes based on the WSDL for the service. The next problem I found was that it was refering to the WSDL on the localhost and when I tried to change this to point to the name of my machine (alexlittle), every time I compiled it reverted back to local host. I;ve now found that after the Web Services Designer Wizard has done it’s thing, it can be removed from the project – just leaving the generated classes, and now I am able to alter the address of the WSDL without it reverting back to localhost.
The problem with having it revert to localhost is that I don’t want to force people to compile the player code in order to get it running, and want them to be able just to change the location of the CC admin service withi an xml config file.
Next step is to get this embedded into the code of the player (at the moment it’s just in a test class).
I’ve the past couple of days trying to get the player to recognise and deserialize the java classes provided by the CopperCore admin module. However I’ve had no luck with getting this working (I’ll keep trying though!). What I have done is a workaround, so that a small file needs to be added to the CopperCore server which provides the required CopperCore Admin web service method for the player, but returns an xml string instead of a java object.
This isn’t the best solution, but it will have to do for now (!), until I can get the neater solution working correctly.
I’ve tested installing the player on another machine and connecting to the web services version of CopperCore on another machine, and this all seems to be working well!! This is now up on Sourceforge and you can get the link and install instructions from: http://iet.open.ac.uk/pp/a.little/index.cfm?page=ldpInstall
For the problem with the returned data types from the CC admin web service, I built the new skeleton classes in the LD player and tried to test it all out. But, what I’d forgotten about was the fact that the player then cannot deserialize the returned data, to turn it into an instance of the new classes.
I’ve spent most of the day trying to find out how exactly to do this deserialization, and there’s lots of websites which mention it, but they are all too in depth and detailed or specific to a particular application for me to be able to read and understand in the short time I’ve got to get this sorted out. I could find no basic step-by-step examples for how to do deserialization of complex java data types, or arrays of them.
My next thought was then to try to update the coppercore admin web service – but then this would mean trying to find out how all the insides of the CC implementation works (also don;t really have time to get into this), and ensure that this was distributed with the next version of CC.
So, my plan of action is to basically recreate the parts of the CC admin web service that the player needs, but have it return xml strings rather than weird data types! This would mean however that to use the LD player, you would then need access to the CC web service server to be able to add in this new admin web service – but I think that’s the best I can do for now 😉
Now sorted out the problem of passing strings of arrays to the webservice – the problem was actually that I was calling the wrong service – doh! – so it wasn’t expecting an array of strings – hence the error message
Have got most of the rest of the player running with webservices, however there was one little problem that I came across in that the CC admin web service returned arrays of classes that were only defined in the CopperCore engine. This means that I would have to have CC and the player installed on the same machine, so that the player can get to the class definition for these CC classes, and I would like to be able to demonstrate that I can have the player running on one machine and CC on another. There are a couple of solutions to this:
- Update the CC admin webservice so that it returns XML strings rather than arrays of CC clasess
- Write another class within the player which just does the necessary functions to the objects that the player requires
I’ve gone for the second option, mainly because there is actually one one class that I will need to create, and there’s not much time left on the project for me to start updating a load of CC functionality. It may not be the best solution, but it will do what I need it to for now and updtaing CC to return XML instead of java objects can be added to the list of future developments 😉
Been a bit quiet on this recently – but I have been doing stuff!
There are a few things that I’ve now managed to get done….
- put a release up on Sourceforge. This seemed to take a lot longer than it should have done! – I’ve never used sourceforge before and it took a little while to find out how I could actually just upload a zip file for people to be able to download. The release I’ve got up there is still just the first version that’s also available from this site. I’ll get a much more up to date version uploaded in afew days (or so!)
- I’ve updated the player so that it will now run level B learning design, so that the user is able to view and set properties. This took a while to get figured out in my head what the LD package should look like – but the OUNL team helped a lot with this one! In terms of this current JISC project, I don’t think we are going to have time now to get the player up to running level C – or rather there may be time, but then the documentation etc of everything else would suffer. Also i think it’s probably more important to get the player tested and running well with level A & B, before trying to implement too much at once (and in a rush) – this can be something someone else may like to take up…. 😉
- I;ve also now received the webservices version of CopperCore, so I’m in the process of changing the player to run with this api rather than the current java api. This seems to be going well so far. The only problem I’ve come across is trying to pass an array of Strings to the web service – but I’m sure I can find a solution to this somewhere…
Just about now got to grips (I think!) with how properties are defined in LD. I thought at first that the properties were just defined in the main LD XML – and in a sense they are, but, to be able to allow users to set/change properties, then extra xml files need to be included in the LD package in order to display the form for the user to update.
Using one of the examples the OUNL team gave me with their 2nd version of the CopperCore engine, I’ve figured out how this should all be working – and I’ve made some changes to their stylesheet for displaying the globalcontent/properties update form. Not significant changes at this point. I now need to update the player servlet so that when the form is posted back the updates are actually sent back to CopperCore.
The next step after this is to sort out the ‘supported-person’ options. An LD can be set up so that (for example) a teacher can look at the properties/global content that one of their learners has entered. All of this is being made much harder by the lack of sample content – just one or 2 examples aren’t really enough!
There still seems to be much to do – and I’m not sure that I’ll have it up to LD level C before the end of the project. Still got quite a lot of tidying up in the code to and writing up (comments/explanations etc) and also change the player so it connects to CopperCore using web services, rather than the current internal java calls.
Been making some more updates to the player, so that it can pull in html resources – and not all of the html tags need to be explicitly defined in the XSL (see point 2 in last entry). I;ve tested it with more content and have been trying with ‘full’ html documents – ie one’s which have all the head, meta tags etc. So far some of these are working and others aren’t. I;ve found that if the html resource has a doctype tag then the xml parser moans about the xml not being well formed – which is what it should moan about I guess.
I’ve made a few updates to the login and course selection pages, so that any errors – such as username not existing, or the username exisitng but not currently assigned to any courses – are handled more elegantly. By elegantly, I mean that the user doesn’t just get the whole java error message printed on screen!
I’m making some changes to the error handling, so that all error messages can be stored in a log file, rather than just appearing either on screen or in the JBoss server window.
Have spent the last few days sorting out some demo content (real content from a short professional development course), which I really need someone else to look over and check that it’s all ok – ie, it’s how a teacher/author would expect a prof. dev. course to look like when presented with learning design.
I got a new version of the coppercore engine through from OUNL so got that up and running quite quickly. I’ve also got the coppercore engine running standalone on my laptop. There were some problems here in that I had Windows XP Pro on the laptop, but for some reason MSDE wouldn’t install properly on XP Pro (couldn’t work out why as MS claim it should!), so ended up rebuilding the machine with W2K instead and all seems to be fine. Putting a new OS on seems a bit drastic – but there wasn;t anything on the machine that I needed to keep!
I’ve made an update to the player, so that rather than html content (a resource in the LD package) being displayed within an iframe, it is displayed directly in the page. There are a couple of drawbacks with what I’ve done here: 1) the html must be well formed – else the xml parser won’t transform the document, 2) any html tags you want to use must be explictly specified in the layout.xsl file and 3) so far, I’ve only tested it with files that are well formed ‘fragments’ of html files, ie they’ve not got all the header/ doc-type declarations etc at the top.
There probably are better ways of doing this, but this way should work for demo/testing purposes for now.