topic Re: 'GroovyPresentationScriptProcessor' in Alfresco Archive

'GroovyPresentationScriptProcessor'

deas0815 — Thu, 29 Jan 2009 09:31:36 GMT

Hallo everybody,I was wondering whether (and how) one would/should implement a "GroovyPresentationScriptProcessor" so one would usegroovy instead of JavaScript or both (choosing the interpreter dependent on the extension of the script).I guess I could implement that myself, but I'd like to avoid re

Re: 'GroovyPresentationScriptProcessor'

mrogers — Thu, 29 Jan 2009 22:52:13 GMT

Generic scripting support via JSR-223 (for Groovy and JRuby) is something that is on the medium term roadmap for Alfresco although we don't yet know how (or indeed if) it will work. We are still at the thinking, prototyping and kicking ideas around stage. So from Alfresco's perspective you are not re-inventing the wheel.

Your ideas for a groovyProcessor AMP are entirely feasible and it will be worth continuing with this forge project that way you will get precicely what you want and you may get a working system faster.

Re: 'GroovyPresentationScriptProcessor'

pmonks — Thu, 29 Jan 2009 23:51:14 GMT

I realise it's not a full Groovy scripting solution, but in Alfresco v3 and above [1] it's relatively easy to develop Web Scripts in Groovy, via Spring's "dynamic bean" concept. It requires a little bit of Java glue code (Spring dynamic beans can't have a parent, which Web Script beans require), but once that code is in place, adding new Groovy backed Web Scripts is as simple as putting the Groovy code and Web Script descriptor etc. into the classpath, updating the Spring config to define the new script as a dynamic bean and restarting Alfresco. All changes to the Groovy code from that point on are picked up automatically, without requiring any further restarts of Alfresco (much the same as Javascript backed Web Scripts that are stored in the classpath).

These "Groovy Web Scripts" can also be easily packaged into AMP files, which makes deployment to test / production environments both simpler and safer.

I have some code lying around that demonstrates how to do this - if you're interested in it let me know and I'll create a forge project, put the code up there and make you a committer so we can both enhance it (along with anyone else who's interested in this area).

Cheers,
Peter

[1] The only reason this approach doesn't work in earlier versions of Alfresco is that Spring dynamic beans don't work very well in Spring versions prior to 2.0.3 or so (Alfresco 2.x bundles Spring 2.0.2, Alfresco 3.x bundles Spring 2.0.6).

Re: 'GroovyPresentationScriptProcessor'

deas0815 — Fri, 30 Jan 2009 21:49:19 GMT

Hallo Peter,

this is exactly what I'm doing today.

What I had in mind in the first place was creating an extension/replacement for PresentationScriptProcessor which acts exactly
like PresentationScriptProcessor does with the only difference being that it uses groovy scripts instead of javascript (or both
determining the interpreter by extension ?).

During my research, I found stepped across groovyProcessor.amp ( http://forge.alfresco.com/frs/?group_id=105 ) but
the idea behind it seems a bit diffrent (and the project orphaned ?) The idea looks pretty appealing to me as well. If I understand
it correctly, it would make grails apps embedded in SURF possible. I imagined dropping an application of a region in webstudio. Please
also have a look at http://forums.alfresco.com/en/viewtopic.php?f=30&t=16567.

Ok now one step after the other.

What exaclty are you interested in when it comes to groovy and alfresco ?

Maybe we can really join forces an start/continue a forge project.

regards
Andreas

Re: 'GroovyPresentationScriptProcessor'

alexander — Fri, 30 Jan 2009 22:16:35 GMT

Hi Andreas

The reason why I did not advanced the forge project was significant changes in the WebScript API that happened between 2.1 and 2.9 version. It felt like a moving target and I felt that better to wait.

Now when API seems to be stabilised it may be a good time to give a boost to the project again. And you are welcome.

I would also like to coordinate with Alfresco as Groovy seems to be on roadmap. May be Alfresco engineer responsible for these features can join the project too.

Thanks
Alexander

Re: 'GroovyPresentationScriptProcessor'

deas0815 — Sat, 31 Jan 2009 11:50:29 GMT

Ok, so we are talking about two things.

1. Groovy controllers

2. (SURF aware) Grails Controllers/Grails Views

Now everybody interested should speak up now.

I, speaking for myself would love to have both, and I would suggest starting off with Groovy Controllers.

regards
Andreas

Re: 'GroovyPresentationScriptProcessor'

alexander — Sat, 31 Jan 2009 13:03:27 GMT

Andreas

What particular benefit do you see in replacing standard web script lifecycle (executable script connecting to model and carrying out operations and then using presentation template as a view)?

Grails controllers do offer extended functionality, such as :
1) Single controller is responsible for multiple operations and views where webscirpt has one operation by default (unless you use parameters to select right method).
2) URL mapping is more concise way of describing URL bindings than whole bunch of webscript descriptors. This is actually not about controllers but about framework approach. Webscripts approach allows better modularity, but less functional.
3) Allows redirect and webflow - nice thing but embedding Spring Web Flow in the product, like Grails did, may be an overkill.

Anything else you are thinking about?

Thanks
Alexander

Re: 'GroovyPresentationScriptProcessor'

deas0815 — Sat, 31 Jan 2009 17:15:17 GMT

Alexander,

Andreas

What particular benefit do you see in replacing standard web script lifecycle (executable script connecting to model and carrying out operations and then using presentation template as a view)?

Grails controllers do offer extended functionality, such as :
1) Single controller is responsible for multiple operations and views where webscirpt has one operation by default (unless you use parameters to select right method).
2) URL mapping is more concise way of describing URL bindings than whole bunch of webscript descriptors. This is actually not about controllers but about framework approach. Webscripts approach allows better modularity, but less functional.
3) Allows redirect and webflow - nice thing but embedding Spring Web Flow in the product, like Grails did, may be an overkill.

Anything else you are thinking about?

Thanks
Alexander

Regarding 1. (Groovy Controllers) I have the following idea in mind:

Provide a mechanism to use groovy controller scripts instead of the javascript ones to prepare the model for the view as groovy is much
more powerful than javascript. The view (i.e. freemarker) would remain the same as it is with javascript today. A special use case
I think of goes like this in the (groovy) controller of a SURF application:

def xml = webFormXmlContentInstanceAccessor.getXml(source.downloadURI)
def handyModelBean = new XmlParser().parseText(xml)
model.put("webFormContentInstance", handyModelBean)

as I personally don't like the idea using webform renditions in a SURF application.

Besides, in a groovy controller you can easily obtain a reference to the ServiceRegistry (in the web-client) or the spring context (in general).

Grails Controllers/Views are a bit more complicated of course. Nevertheless, I would love to place Grails Appliation components
on a page in webstudio just as you place application portlets on a portal page. I don't yet have a clear picture how much makes
sense here and how much effort it is to get there.

cheers
Andreas

Re: 'GroovyPresentationScriptProcessor'

alexander — Sat, 31 Jan 2009 17:20:37 GMT

Sounds good

What people think about security restrictions groovy scripts should have?

If we use service auto-injection (or even give access to Service Registry) then using groovy anyone can run as "system" bypassing security restrictions for this user.

Any thoughts here?

Thanks
Alexander

Re: 'GroovyPresentationScriptProcessor'

deas0815 — Sat, 31 Jan 2009 18:42:35 GMT

well not sure whether I'm missing something here, but I just felt like I had a deja vue.

Regarding grails controllers/views I guess one can go even further an generalize the idea so you can use any servlet based
webappliation framework while staying completely independent of them.

I was thinking of the idea the portals bridges people had (but start off with a webscript instead of a portlet). Have a look
at http://portals.apache.org/bridges/. In fact, in 2005 I was extending the struts bridge to support multiple
struts portlets on one page and implemented the Vignette portal interface (which is an ugly hack because I do not have
the source of their portal).

The general idea of portals bridges is to provide servlet api objects so the webapplication framework (JSF, grails, wicket or whatever)
gets what it wants.

I guess implemention effort of this approach should be far less than making the application framework SURF aware. And this approach
is far more general and even independant of the webapplication framework.

Am I missing something ?

Comments ?

cheers
Andreas

Re: 'GroovyPresentationScriptProcessor'

pmonks — Mon, 02 Feb 2009 20:06:12 GMT

While the idea of implementing a Groovy aware ScriptProcessor is a good one (particularly longer term), currently that framework is fairly heavily Javascript centric, and I don't believe it will be possible to integrate Groovy (or other scripting languages) at that level without quite a bit of knock-on work required elsewhere in the Alfresco code. And for that level of disruption / impact I'd rather wait and see what approach the Alfresco engineers are thinking of, rather than risk wasting my time heading down a path that heads off at a tangent. Of course feel free to have a crack at it if you like - don't let my risk aversion hold you back! :wink:

In the meantime however, what I've been exploring is implementing extensions in Groovy, using the Java versions of those extension points. In some cases (eg. Web Scripts) this can't be done directly and requires a little bit of (reusable) Java glue code, but for many of these extension mechanisms Groovy can already be used directly - this is possible due to Spring's dynamic beans functionality (http://static.springframework.org/spring/docs/2.0.x/reference/dynamic-language.html). In fact this approach should also work for BeanShell and JRuby, although I haven't tried that myself.

This has a number of advantages, including:

Using Spring dynamic beans means that developers can get all the usual benefits of a scripted language - hot redeployment, no server restarts etc.

The developer isn't limited to the Javascript API - they can leverage all of Alfresco's native APIs as well as any other native Java API that's in the Alfresco classpath

It doesn't break (or even change!) how Alfresco invokes extensions - from Alfresco's perspective it's dealing with just another native Java extension wired in via Spring

It doesn't change the security / access rules that Alfresco already has - Groovy extensions would play by exactly the same rules that native Java extensions already have

The only downsides I've hit to date are:

This only works for Alfresco 3 and up - the 2.x releases include an older version of Spring that doesn't support dynamic beans properly

In some cases (notably Web Scripts) you can't wire in a Spring dynamic bean directly, so some small Java glue code is required to delegate calls to the Groovy script

The initial configuration of the Groovy script can't be done dynamically ie. you have to reconfigure Spring then restart Alfresco once before you get into the edit / test cycle

IMVHO these are pretty minor concerns though, since (1) most people should be on, or looking to move to, Alfresco 3 ASAP; (2) the glue code is trivial and reusable, so it only needs to be written once then can be forgotten about; and (3) the initial configuration of a custom extension is (for me at least) typically a vanishingly small percentage of the total time I spend implementing an extension.

Cheers,
Peter

Re: 'GroovyPresentationScriptProcessor'

deas0815 — Tue, 03 Feb 2009 04:38:08 GMT

Hallo everybody, hallo Peter,

Peter: I also noticed that a "real" Groovy replacement for the Javascript Processor requires a few changes as the Javascript
based code is a bit scattered. Hence I would also appreciate a statement from the alfresco engineering team where there
are heading to regarding this.

Regarding grails controllers/views I more and more see SURF as a portal "replacement" as the framework has quite a lot
in common with a portal (w/o the personalization) - Pages, navigation, themes, chrome, regions, components and templates.
Seeing it from this perspective, I was wondering whether "application components" should be implemented just like portals
usually do it - Put the application in another servlet context and then do cross context calls.

Regarding grails, you would have to be a little careful with javascript and tags but I guess that would be the cleanest approach.
You could even implement the application without it beeing embedded in SURF and you should not have to care about
libraries beeing compatible (SURF + grails/JSF/whatever).

The bridge based approach (s. portals bridges) may head into library conflicts.

Comments ?

Suggestions ?

cheers
Andreas

Re: 'GroovyPresentationScriptProcessor'

pmonks — Tue, 03 Feb 2009 05:42:38 GMT

A Surf / Grails integration should be possible via a similar mechanism to what I've been using for repo Web Scripts - after all Surf components are just Web Scripts running outside the repo. The questions are whether Grails requires access to the raw request and response objects (which is possible in a Java backed Web Script, but is not recommended) and whether it's capable of generating page fragments rather than fully formed pages (which would remain the responsibility of Surf).

BTW, mrogers (who posted on Jan 29th) is an Alfresco engineer, so I think we already have a statement. :wink:

Cheers,
Peter

Re: 'GroovyPresentationScriptProcessor'

deas0815 — Tue, 03 Feb 2009 15:00:04 GMT

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

Re: 'GroovyPresentationScriptProcessor'

alexander — Sat, 07 Feb 2009 01:27:31 GMT

Just an update:

groovyProcessor.amp (http://forge.alfresco.com/projects/minigrails/) was updated for version 3 stable. it allows using .groovy and .gsp in webscripts running in the context of repository (but not in standalone web applications like Surf / Share).

Webscripts functionality is not enabled by default, it requires changes in webscript-framework-application-context.xml:


<bean id="webscript.default" parent="webscript" class="org.alfresco.web.scripts.DeclarativeWebScript" scope="prototype"/>
‍‍‍

has to be changed to:


<bean id="webscript.default" parent="webscript" class="org.alfresco.module.GroovyProcessor.WebScript.DeclarativeWebScript" scope="prototype">
        <property name="serviceRegistry">
            <ref bean="ServiceRegistry"/>
        </property> 
</bean>
‍‍‍‍‍‍‍

All previous functionality like custom tags, encoders etc. should still be supported (did not test too extensively).

Thanks
Alexander

Re: 'GroovyPresentationScriptProcessor'

deas0815 — Sat, 07 Feb 2009 09:38:24 GMT

@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

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

Re: 'GroovyPresentationScriptProcessor'

deas0815 — Sun, 08 Feb 2009 13:29:40 GMT

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

Re: 'GroovyPresentationScriptProcessor'

pmonks — Mon, 09 Feb 2009 05:05:20 GMT

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

Re: 'GroovyPresentationScriptProcessor'

alexander — Tue, 10 Feb 2009 19:32:41 GMT

Peter

Default model (and also ScriptNode properties and methods) make it quite intuitive to someone who wants to write SCRIPTS. It would require knowledge of Alfresco Java API to write even simple scripts if this was not the case.

This injection does no harm because:
1) Javascript API is written quite efficiently. Effectively they are just bunch of helper methods that allow working with properties faster. The only exception may be "content" operation that can not be optimised well using Javascript API.
2) One can always decide to ignore it and to provide ServiceRegistry object to your Groovy scripts and go from there. This will require building simple processor extension (class that is based on BaseProcessorExtension and wired similar to other extensions in module-context.xml).

What I plan to explore is a way to auto-inject any Alfresco beans into Groovy script by name match. For example something like this:


def documentPath = nodeService.getPath(document)
‍‍‍

will automatically find bean "nodeService" if this variable or property does not exist and bean "nodeService" is defined in Spring. Does it sound like a good idea?

Thanks
Alexander

Re: 'GroovyPresentationScriptProcessor'

pmonks — Tue, 10 Feb 2009 20:13:31 GMT

The problem is that mixing calls to the Javascript and Java APIs is not recommended (see http://wiki.alfresco.com/wiki/JavaScript_API_For_Alfresco_2.1#Native_Java_API_Access), so allowing both of them to be used from Groovy scripts (or any other scripting environment) is likely to create subtle problems that are difficult to troubleshoot. For that reason it would be better to limit Groovy scripts to one or the other, but never both at the same time - that's the best way to ensure developers (particularly those new to Alfresco) don't inadvertently get themselves into trouble. FWIW I'd prefer to see only the Java APIs available to Groovy scripts, for the simple reason that it would be difficult to make them unavailable to Groovy, given Groovy's deliberately tight integration with Java.

Now whether those native Java APIs get wrapped into "Groovier" APIs is a separate question, and I think doing so makes perfect sense. The "builder" pattern that some other Groovy libraries are following seems to me to have good applicability to the native Alfresco APIs, for example.

Cheers,
Peter