Alex Milowski wrote:
The init() function is called. If the init function returns an
object, then methods on
that object are called instread of global functions.
obviously I like this more...
I've currently implemented this as a very terse Application class that
just compiles
the script and passes the requests as appropriate. I could certainly
see expanding
this to handle mapping requests to more than one script file/source.
actually, you probably would want to separate things completely:
- on the one side just allow specifying multiple js files to be loaded
- and then provide some rounting/uri-mapping that acts as the
switchboard that creates any of the objects defined in any of those js-files
so I'ld rather have a init(context) {} that produces more then just one
type, depending on what e.g. the request-uri looked like
Comments? Suggestions?
Rhino allows you to do inline implementations of Java interfaces in
javascript
So I would really let init() return one of those through simply
function init(context) {
var jsRestlet = new RestScript(context);
return new Packages.org.restlet.Restlet(jsRestlet);
}
When that object gets back up into java-land somewhere it will have a
dynamic proxy wrapped around it to actually call your js-code, w00t!
With respect to scripting languages (and notably the continuations
support inside Rhino as exploited by Apache Cocoon's flowscript) I'm
still somewhat fighting with how that could be exploited as 'resources'
in restlet.org
(yeah, I'm still thinking about temporary resources, see the 'sessions
debate' thread)
Has anyone tried JRuby or Groovy with Restlets ?
nope, I guess those have frameworks like (g)rails doing the web-legwork
for them already.
And given the Java nature, rhino/js is surely more into my line of
thinking for giving restlet a scripting layer as well. (allthough this
should not prevent others from taking up other scripting languages)
Another argument pro rhino/js however is that this would extend on the
idea of the symmetric client-server API that is already present in
restlet.org: A js implementation of the restlet API should be able to
live inside the browser as well. (Over there the context/dispatcher
should use xmlhttprequest for actual GET/POST/PUT/DELETE proxy-ing)
as such we would have something like a client-proxy for the service
living inside the browser
making sense?
regards,
-marc=
