Peter: Sometimes there are reasons to access the raw Servlet API objects. Today, I need content generated by webforms in controller code (webscript)
in virtual tomcat and a remotely running SURF app. The only way I've found so far is using the requestdispatcher and forwarding a request
to the default servlet or the endpoint proxy servlet. You also need this when you want to create (Groovy) "handy" Model-Beans from within
controller code as mentioned above.
Am I missing something ?
Regarding "full blown" SURF application components, I still favour the "portal-style" cross context approach in general. I'll go ask the grails people for
their comments as I'm personally most interested in grails.
@Alfresco Engineering: Which approach in general would you suggest to implement "SURF application components" when one wants a full blown
web-application stack ?
Is there something wrong with the portal-style "cross context" approach ?
cheers
Andreas
in virtual tomcat and a remotely running SURF app. The only way I've found so far is using the requestdispatcher and forwarding a request
to the default servlet or the endpoint proxy servlet. You also need this when you want to create (Groovy) "handy" Model-Beans from within
controller code as mentioned above.
Am I missing something ?
Regarding "full blown" SURF application components, I still favour the "portal-style" cross context approach in general. I'll go ask the grails people for
their comments as I'm personally most interested in grails.
@Alfresco Engineering: Which approach in general would you suggest to implement "SURF application components" when one wants a full blown
web-application stack ?
Is there something wrong with the portal-style "cross context" approach ?
cheers
Andreas
@Alexander: Great, I'll have a look at it.
In the meantime, I've made a quick hack implementing a SuperPresentationScriptProcessor which also supports Groovy controllers. It is
an extension to PresentationScriptProcessor which defaults to javascript but tries groovy when javascript is not found. Works fine
with SURF for me.
Just in case somebody brave is interested
regarding SURF + Grails integrations, I'll check how much effort th "the portal style integration" is.
cheers
Andreas
In the meantime, I've made a quick hack implementing a SuperPresentationScriptProcessor which also supports Groovy controllers. It is
an extension to PresentationScriptProcessor which defaults to javascript but tries groovy when javascript is not found. Works fine
with SURF for me.
Just in case somebody brave is interested
import groovy.lang.Binding;
import groovy.lang.GroovyCodeSource;
import groovy.lang.GroovyShell;
import java.util.HashMap;
import java.util.Map;
import java.util.UUID;
import java.util.concurrent.ConcurrentHashMap;
import org.alfresco.web.scripts.PresentationScriptProcessor;
import org.alfresco.web.scripts.ScriptContent;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
public class SuperPresentationScriptProcessor extends
PresentationScriptProcessor {
private static final Log logger = LogFactory
.getLog(SuperPresentationScriptProcessor.class);
private Map<String, GroovyCodeSource> groovyScriptCache = new ConcurrentHashMap<String, GroovyCodeSource>(
256);
private boolean groovyEnabled = true;
public SuperPresentationScriptProcessor() {
super();
logger.debug("In god we trust :)");
}
/** AbstractWebScript has .js hard coded */
@Override
public Object executeScript(ScriptContent location,
Map<String, Object> model) {
logger.debug("Execute script " + location.getPath());
String path = location.getPath();
Object retval = null;
if (isGroovyEnabled() && path.endsWith(".groovy")) {
logger.debug("Its groovy !");
HashMap<String, Object> variables = new HashMap<String, Object>();
Map<String, Object> mod = model;
if (mod != null) {
for (String key : mod.keySet()) {
Object obj = mod.get(key);
variables.put(key, obj);
}
} else {
mod = new HashMap<String, Object>();
}
variables.put("model", mod);
GroovyCodeSource gs = this.groovyScriptCache.get(path);
if (gs == null) {
String codeBase = "";
String name = "Groovy_" + UUID.randomUUID().toString().replaceAll("-", "");
gs = new GroovyCodeSource(location.getInputStream(), name, "");
this.groovyScriptCache.put(path, gs);
} else {
logger.debug("Using cached instance of groovy script " + path);
}
GroovyShell groovyShell = new GroovyShell(new Binding(variables));
retval = groovyShell.evaluate(gs);
logger.debug("Groovy script " + path + " executed");
} else {
logger.debug("Its not groovy");
retval = super.executeScript(location, model);
}
logger.debug("model ready = " + model.get("ready"));
return retval;// Nobody cares about it actually !
}
@Override
public void reset() {
super.reset();
this.groovyScriptCache.clear();
}
/**
* AbstractWebScript passes .js hardcoded - try .js and .groovy
* protected ScriptDetails getExecuteScript(String mimetype)
* ScriptResourceHelper.recurseScriptImports calls
* ScriptResourceLoader.loadScriptResource
*/
@Override
public ScriptContent findScript(String path) {
logger.debug("find script " + path);
String basePath = path.replaceAll("\\.js", "");
ScriptContent scriptContent = super.findScript(basePath + ".js");
if (scriptContent == null && isGroovyEnabled()) {
logger.debug("No script with path " + basePath
+ ".js found, trying " + basePath + ".groovy");
scriptContent = super.findScript(basePath + ".groovy");
}
if (scriptContent != null) {
logger.debug("Got script for base path " + basePath + " : "
+ scriptContent.getPath());
} else {
logger.debug("Got no script for base path " + basePath);
}
return scriptContent;
}
public boolean isGroovyEnabled() {
return groovyEnabled;
}
public void setGroovyEnabled(boolean groovyEnabled) {
this.groovyEnabled = groovyEnabled;
}
}
regarding SURF + Grails integrations, I'll check how much effort th "the portal style integration" is.
cheers
Andreas
just in case somebody is interested, I've now asked the grails people for their 2c regarding integration
of grails and SURF. The posting is here: http://www.nabble.com/Alfresco-SURF-%2B-Grails-%3A-Comments-for-integration-td21898436.html
Luis: I personally would not call the rest of grails "overhead". Imagine you want a real full blown modern application running in a SURF based website: Persistence with a complex model, WebFlow, Form Validation, AJAX etc. Which approach would you suggest in this case ? Of course grails is just one of the many stacks available - it just happens to be the one I personally prefer.
cheers
Andreas
of grails and SURF. The posting is here: http://www.nabble.com/Alfresco-SURF-%2B-Grails-%3A-Comments-for-integration-td21898436.html
Luis: I personally would not call the rest of grails "overhead".
Imagine you want a real full blown modern application running in a SURF based website: Persistence with a complex model, WebFlow, Form Validation, AJAX etc. Which approach would you suggest in this case ? Of course grails is just one of the many stacks available - it just happens to be the one I personally prefer. cheers
Andreas
One comment (which is based on little more than a quick perusal of the GroovyPresentationScriptProcessor, so might be completely misguided :wink: I'm not sure it's a good idea to inject the default script processor model object into Groovy scripts, since currently the default model is quite specific to Rhino (the JS interpreter Alfresco uses). For Groovy (which has a much tighter integration with native Java than Rhino does), it would be better to inject the Java equivalents of the appropriate root scope objects, rather than the Rhino-compatible facades.
While this might seem like a lot of work, I think injecting just the ServiceRegistry (along with any script context - the document/space NodeRef for an action, for example) would be sufficient for most Groovy scripts. Unlike the Javascript API (which doesn't have an equivalent of the ServiceRegistry, let alone the ability to instantiate native Alfresco objects directly), Groovy scripts should be able to get at just about everything from the ServiceRegistry.
Cheers,
Peter
: I'm not sure it's a good idea to inject the default script processor model object into Groovy scripts, since currently the default model is quite specific to Rhino (the JS interpreter Alfresco uses). For Groovy (which has a much tighter integration with native Java than Rhino does), it would be better to inject the Java equivalents of the appropriate root scope objects, rather than the Rhino-compatible facades.While this might seem like a lot of work, I think injecting just the ServiceRegistry (along with any script context - the document/space NodeRef for an action, for example) would be sufficient for most Groovy scripts. Unlike the Javascript API (which doesn't have an equivalent of the ServiceRegistry, let alone the ability to instantiate native Alfresco objects directly), Groovy scripts should be able to get at just about everything from the ServiceRegistry.
Cheers,
Peter
