链接：https://pan.baidu.com/s/1LgcrRF-BT1nkLVOxRtozJg 

提取码：ejhg

Listing all Whitepapers As a quick review, recall that SomeCo writes whitepapers and manages those papers with Alfresco.

Some whitepapers are published to the web site. A custom aspect called “webable” has a flag called isActive. Whitepapers with the isActive flag set to true should be shown on the web site. For this article, we're going to ignore the webable aspect and the isActive flag. We'll just assume any sub­type

of sc:whitepaper found in the /Someco/Whitepapers folder is fair game. (If this bugs you, see the

sidebar).

Let's write a web script that returns all whitepapers. We want the list in two formats HTML and JSON. HTML will allow us to easily test the service and JSON will make it easy for code on the front­end to

process the list. This will require four files: one descriptor, one JavaScript controller, and two FreeMarker templates—one for each format. Alfresco Developer: Intro to the Web Script Framework This work is licensed under the Creative Commons Attribution­Share Alike 2.5 License Page 10 of 28

Illustration 2: The detail page also uses an AJAX call and includes the same ratings

widget as well as a download link

ecmarchitect.com

Before we start coding, let's talk a bit about organization.

First, packages. The Web Script Framework allows us to

organize script assets into a hierarchical folder or package structure. Just as it is with Java it is probably a good idea to

do this for all web scripts. Following a reverse domain name

pattern is probably a good convention. So we'll be using

“com/someco” for our package which means our files will reside under /Company Home/Data Dictionary/Web Scripts Extensions/com/someco.1 Next, URLs can follow any pattern we want, but they will always start with <alfresco webapp>/service where “<alfresco webapp>” is the name of the Alfresco web application context (usually “alfresco”). Because the URL

pattern must be unique, it is probably a good idea to incorporate the package name in the URL. In this article we'll

prefix all URLs with “someco”. Alfresco reserves certain package names and URLs for their own use (see the Alfresco wiki) but by following the

conventions proposed here, you'll steer clear of those. Finally, you've seen that web script assets can reside in the

repository, but they can also reside in the file system. The only requirement is that they be on the

classpath, but I suggest that they reside in the “alfresco/extension” directory just like your other extensions. Following the package structure suggested earlier, if we were to store our scripts on the file system, rather than the repository, we'd put them in alfresco/extension/templates/webscripts/com/ someco.

The advantage of using the file system is that the web scripts that make up your solution can be

deployed alongside your other extensions without requiring anyone to upload them to the repository. The disadvantage is that changes require a restart.

In the source code I've provided with this article, the web scripts are set up to deploy to the file system with the other extensions. If, instead of deploying the sample code, you want to follow along and you

want to avoid restarts, move my scripts out of the alfresco extension directory before you deploy, then

upload your scripts to the repository like we did for the Hello World example. 1 It isn't required that you use the “Web Scripts Extensions” folder in the repository. I did it because it seemed consistent

with how web client customizations are deployed (using the alfresco/extension folder). Web scripts placed in the “Web Scripts Extensions” folder that have the same file names as those in the “Web Scripts” folder will override the scripts stored in “Web Scripts”. For this reason, if you want others to be able to override your scripts, use the “Web Scripts” folder rather than “Web Scripts Extensions”. See the Alfresco wiki for more on web script folder search order.