After a long hiatus from programming Sakai tools, I once again find the code base an opaque nest of terms. Gotta get back into the Sakai way of thinking, so I’m going to write up my thoughts to make it easier the next time I take a break and get back into it.
What I want to do is properly integrate my couch glossary with Sakai. So what I need is a java wrapper around the couch access. I want the wrapper to accept simple jsonp calls, and emit json responses, just as the current couchdb-native glossary does. I’m even up for serving the widget from a doc attached to the design doc, just as in couchdb-native.
So this has to be available everywhere, so it has to be a service. I think. Here is where sakai terminology just numbs me. There is nothing in the Sakai confluence site (nothing recent, that is) describing how to program a simple service. There is lots of awesome stuff up there to make writing tools easier, but I don’t want a tool. A tool gets stuck in a site. A site exists all by itself. I want a service with a public stub inside Tomcat, I guess like the library? Except library can be seen always. I want a real webapp. Just not a tool.
So I think that is a good start for how to code this up in Sakai. Use the app builder to make a tool, just get rid of all the tool stuff, and pay close attention to getting in and out of the app from the web. Make sure all access is mediated by the authorization service, and that should do it.