'GroovyPresentationScriptProcessor'

[deas0815]

Hallo everybody,

I was wondering whether (and how) one would/should implement a "GroovyPresentationScriptProcessor" so one would use
groovy 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  reinventing the wheel.

I stepped across "groovyProcessor.amp" at http://forge.alfresco.com/frs/?group_id=105. The project looks
close to what I want but seems orphaned.

Is this approach (groovyProcessor.amp and the idea in general) wrong ?

Suggestions/Hints how/where to continue are appreciated.

regards
Andreas

[mrogers]

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.

[pmonks]

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).

[deas0815]

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

[alexander]

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

[deas0815]

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

[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

[deas0815]

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

[alexander]

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

[deas0815]

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