cancel
Showing results for 
Search instead for 
Did you mean: 

Javascript webscript and Java backed webscript

ratik_singhal
Star Contributor
Star Contributor
I want to know the technical difference between Javascript webscript and Java backed webscript. Also please guide me when to use which webscript ?

What I Know:

<li> For Rapid development use Javascript webscript </li>
<li> For easy maintenance purpose use Java backed webscript </li>
<li> To avoid error on production use Java backed webscript </li>

1 ACCEPTED ANSWER

ratik_singhal
Star Contributor
Star Contributor
One more or can say technical difference I have found is:

The controller can fetch content from different sources, such as the Alfresco Content Repository, or a remote Web Service on the Internet. Note that the special root object called remote, which is available for Surf Web Scripts to fetch remote data on the internet, is not available when implementing a Repository Web Script JavaScript controller. To fetch remote data on the Internet from a Repository Web Script, a Java controller is needed.

View answer in original post

5 REPLIES 5

steven_okennedy
Star Contributor
Star Contributor
Hi,

The main differences you have between a JS vs Java-backed webscript is the API that you have access to.  The Javascript API exposes a smaller subset of capabilities than the Java Foundation API that's available to Java-backed webscripts, although there are ways to increase what's exposed to Javascript or to expose new custom APIs to Javascript if you like.

The other difference which is useful at certain times, is that with a Java backed webscript you have more control over what parts of the webscript framework are used.  E.g. with a JS webscript, you are always obliged to use a template for the "view" (usually Freemarker) so that can be problematic if you want to send back a raw binary content stream, e.g. a document or other non-text based content.  With a Java-backed webscript you can define a class that implements the WebScript interface directly or uses AbstractWebscript instead of DeclarativeWebscript.  You could also do other things like look at or set request/response headers, cookies or other things that won't have access to using a Javascript controller

On the point on Rapid Development, Alfresco's support using SpringLoaded is currently not working for repository classes (i.e. in the alfresco webapp) so it is definitely true that javascript development should be a lot faster - Java webscripts will need a recompile and restart right now, but if they fix the compatibility issue with SpringLoaded, then that might go away.

Another aspect with Javascript is that webscripts can be created and deployed in a running repository without having to stop and restart - they can either be dropped in as code items in the right folder on the file system or can be deployed into the Data Dictionary itself.  This can make things easier and faster and avoid downtime windows for deployment into production systems.

Both kinds can be debugged with both logging and step-through debuggers using pretty good tools that are available, e.g. Alfresco Javascript Debug console and remote eclipse debugging for example. 

There are also test suites available to handle unit/integration/automated functional testing for both Javascript and Java webscripts, especially RESTful style black box test hitting the URL of the service so testability should not be a concern - although you'll probably find people more familiar with the Java tooling (e.g. JUnit, Mockito etc) than you will for Javascript testing frameworks

If you have a look at what Alfresco themselves use, generally the more complex webscripts are implemented in Java (as well as those that need capabilities provided only by Java APIs) and the simpler ones are done through Javascript

Regards

Steven

Is it confirmed that Javascript API exposes a smaller subset of capabilities than the Java Foundation API that's available to Java-backed webscript ? Its mean that all the things we can do in java-backed webscript, can not do by using javascript APIs. Is it True ?

Agree - You could also do other things like look at or set request/response headers, cookies or other things that won't have access to using a Javascript controller

ratik_singhal
Star Contributor
Star Contributor
One more or can say technical difference I have found is:

The controller can fetch content from different sources, such as the Alfresco Content Repository, or a remote Web Service on the Internet. Note that the special root object called remote, which is available for Surf Web Scripts to fetch remote data on the internet, is not available when implementing a Repository Web Script JavaScript controller. To fetch remote data on the Internet from a Repository Web Script, a Java controller is needed.

steven_okennedy
Star Contributor
Star Contributor
Yes, it is true that the Javascript API exposes a smaller subset of functionality (http://docs.alfresco.com/community/concepts/ws-java-backed-webscripts.html) . For a practical example, look at the audit service & attribute service exposed as part of the public Java API that don't have counterparts at all in the JS APIs.  Basically, with a Java-backed webscript you have the ability to inject any bean that's available in Alfresco - although obviously from a supportability point of view you should stick to using the ones exposed as part of the Public API.

Regards

Steven

risharommi
Champ in-the-making
Champ in-the-making
A collection of webscript examples. It provides examples on both Java-backed webscripts, aswell as Javascript-backed webscripts, touches briefly on doing proper REST webscripts with a webscript that allows GET and DELETE on nodes. It also shows how to have the same webscript controller be rendered as both JSON and XML. Finally it shows a webscript in the Share tier.

web design service