The Prudence Manual

Version 2.0-dev4
Main text written by Tal Liron

Tutorial

Installing Prudence

Further Exploration

• Start Prudence as a system service
• Logging

At a Glance

/component/

/component/applications/

/component/libraries/scripturian/

/component/libraries/prudence/

/component/libraries/web/

/component/libraries/jars/

/cache/

Further Exploration

• Learn about bootstrapping with Sincerity
• Configure your component

Your First Application

The “prudence” Command

/resources/

/libraries/

/libraries/

Further Exploration

• Configure your application
• Managing the URI-space

Generating HTML

Further Exploration

• Textual Resources
• Adding more languages

A Manual Resource

Further Exploration

• Manual Resources

Managing the URI-space

Routing Paradigms

1. Resource mapping: The filesystem hierarchy under an application’s “/resources/” subdirectory is directly mapped to URIs (but not URI templates). Both directory- and file-names are mapped in order of depth. By default, Prudence hides filename extensions from the published URIs, but uses these extensions to extracts MIME-type information for the resources. Also, mapping adds trailing slashes by default, by redirecting URIs without trailing slash to include them (on the client’s side). Filesystem mapping provides the most “transparent” management of your URI-space, because you do not need to edit any configuration file: to change URIs, you simply move or rename files and directories.
2. URI/resource separation:
   1. URI capturing: Capturing lets you map URI templates to fixed URIs, as well as perform other kinds of internal URI rewrites that are invisible to clients, allowing you to provide a published URI-space, which is different from your internal mapping structure. (Note that another common use for capturing is to add support for URI templates in resource mapping, as is explained under Resource Mapping. This use case does not belong to the URI/resource separation paradigm.)
   2. Resource dispatching: In your application’s routing.js you can map URIs or URI templates to a custom ID, which is then dispatched to your resource handling code. Dispatching provides the cleanest and most flexible separation between URIs and their implementation.

routing.js

app.hosts = {
	’default’: ’/myapp/’,
	internal: ’/myapp/’
}
​
app.routes = {
	’/*’: [
		’manual’,
		’scriptlet’,
		{type: ’cacheControl’, mediaTypes: {’image/png’: ’farFuture’, ’image/jpeg’: ’farFuture’, ’image/gif’: ’farFuture’}, next:
			{type: ’javaScriptUnifyMinify’, next:
				{type: ’zuss’, next: [
					’static’,
					{type: ’static’, root: sincerity.container.getLibrariesFile(’web’)}]}}}
	],
	’/sample1/’: ’@sample’, // (dispatched)
	’/sample2/’: ’/sample/’ // (captured)
}
​
app.dispatchers = {
	javascript: ’/manual-resources/’
}

app.routes

• Variables are strings wrapped in curly brackets. For example, here is a URI template with two variables: “/profile/{user}/{service}/”. The variables will match [TODO]. You can access the string values of there variables in your resource via the conversation.locals API.
• A wildcard can be used as the last character in the URI template. For example, “/archive/*” will match any URI that begins with “/archive/”. You can access the remainder of the URI via the [TODO] API. Note that Prudence will attempt to match non-wildcard URI templates first, so a wildcard URI template can be used as a general fallback for URIs.

Routing

Mapping

Combining

Filtering

Custom Route Types

1. Create a JavaScript class that:
   1. Implements a create(app, uri) method. The “app” argument is the instance of Prudence.Routing.Application, and the “uri” argument is the URI template to which the route type instance should be attached. The method must return an instance of a Restlet subclass.
   2. Accepts a single argument, a dict, to the constructor. The dict will be populated by the route type configuration dict in app.routes.
2. Add the class to Prudence.Routing. Remember that the class name begins with an uppercase letter, but will begin with a lowercase letter when referenced in app.routes.

Prudence.Routing.See = Sincerity.Classes.define(function() {
	var Public = {}
​
	Public._inherit = Prudence.Routing.Restlet
	Public._configure = [’uri’]
​
	Public.create = function(app, uri) {
			importClass(org.restlet.routing.Redirector)
			var redirector = new Redirector(app.context, this.uri, Redirector.MODE_CLIENT_SEE_OTHER)
			return redirector
	}
​
	return Public
}())
​
app.routes = {
	...
	’/original/’: {type: ’see’, uri: ’http://newsite.org/new/uri/’}
}

Injecting Conversation Attributes

• Captured URI targets
• Redirection URI targets
• Cache keys (see caching)

Request URIs

• {r-}: actual URI (reference)
• {h-}: virtual host URI
• {o-}: the application’s root URI on the current virtual host
• {f-}: the referring URI (sent by some clients: usually means that the client clicked a hyperlink or was redirected here from elsewhere)

• {-i}: the complete URI (identitifer)
• {-h}: the host identifier (protocol + authority)
• {-a}: the authority (for URLs, this is the host or IP address)
• {-p}: the path (everything after the authority)
• {-r}: the remaining part of the path after the base URI (see below)
• {-e}: a relative path from the URI to the application’s base URI (see below; note that this is a constructed value, not merely a string extracted from the URI)
• {-q}: the query (everything after the “?”)
• {-f}: the fragment (the tag after the “#”; note that web browsers handle fragments internally and never send them to the server, however fragments may exist in URIs sent from the server: see the “{R-}” variable mentioned below)

Request Attributes

• {p}: the protocol (“http,” “https,” “ftp,” etc.)
• {m}: the method (in HTTP, it would be “GET,” “POST,” “PUT,” “DELETE,” etc.)
• {d}: date (as a Unix timestamp)

Client Attributes

• {cia}: client IP address
• {ciua}: client upstream IP address (if the request reached us through an upstream load balancer)
• {cig}: client agent name (for example, and identifier for the browser)

Entity Attributes

• {es}: entity size (in bytes)
• {emt}: entity media (MIME) type
• {ecs}: entity character set
• {el}: entity language
• {ee}: entity encoding
• {et}: entity tag (HTTP ETag)
• {eed}: entity expiration date
• {emd}: entity modification date

Response Attributes

• {S}: the HTTP status code
• {SIA}: server IP address
• {SIP}: server port number
• {SIG}: server agent name
• {R-}: the redirection URI (see “Request URIs” above for a list of suffixes, which must also be in uppercase)

Resource Mapping

1. For manual and scriptlet resources, Prudence hides filename extensions from the URIs by default. Thus, “/resources/myresource.m.js” would be mapped to “/resources/myresource/”. The reasons are two: 1) clients should not have to know about your internal implementation of the resource, and 2) it allows for cleaner and more coherent URIs. Note the filename extensions are used internally by Prudence (differently for manual and scriptlet resources). Note that this does not apply to static resources: “/resources/images/logo.png” will be mapped to “/images/logo.png”.
2. For manual and scriptlet resources, Prudence by default requires trailing slashes for URIs. If clients do not include the trailing slash, they will receive a 404 (“not found”) error. Again, the reasons are two: 1) it makes relative URIs always unambiguous, which is especially relevant in HTML and CSS, and 2) it clarifies the extent of URI template variables. As a courtesy to sloppy clients, you can manually add a permanent redirection to a trailing slash, using the “addSlash” route type. For example:

   app.routes = {
   	...
   	’/main’, ’addSlash’,
   	’/person/profile/{id}’: ’addSlash’
   }
   

3. This mapped URI-space can be manipulated using URI hiding and URI capturing, allowing you to support URI templates and rewrite URIs.

Capturing URI Templates

app.routes = {
	...
	’/user/profile/{userId}/’: ’/user/profile/!’
}

app.routes = {
	...
	’/user/profile/{userId}/’: ’/user/profile/’,
	’/user/profile/’: ’!’
}

<html>
<body>
<p>
User profile for user <%= conversation.locals.get(’userId’) %>.
</p>
</body>
</html>

Dynamic Capturing

app.routes = {
	...
	’/user/{userId}/preferences/’: ’/database/preferences/{m}/?id={userId}’
}

app.routes = {
	...
	’/database/preferences/GET/’: ’!’,
	’/database/preferences/POST/’: ’!’
}

Limitations of Resource Mapping

1. In large URI-spaces you may suffer from having too many files. Though you can use “/libraries/” to share code between your resources, mapping still requires a file per resource type.
2. Mapped manual resources must have all their entry points (handleInit, handleGet, etc.) defined as global functions. This makes it awkward to use object oriented programming or other kinds of code reuse. If you define your resources as classes, you would have to hook your class instance via the global entry points.
3. The URI-space is your public-facing structure, but your internal implementation may benefit from an entirely different organization. For example, some resources my be backed by a relational database, others by a memory cache, and others by yet another subsystem. It may make sense for you to organize your code according to subsystems, rather than the public URI-space. For this reason, you would want the URI-space configuration to be separate from your code organization.

URI Capturing

app.routes = {
	...
	’/user/{userId}/preferences/’: ’/database/preferences/’,
	’/user/{userId}/profile/’: ’/database/profile/’,
	’/user/{userId}/session/’: ’/cache/session/’
}

Resource Dispatching

app.routes = {
	...
	’/session/{sessionId}/’: ’@session’,
	’/user/{userId}/preferences/’: ’@user’
}

app.dispatchers = {
	javascript: ’/manual-resources/’
}

var UserResource = function() {
	this.handleInit = function(conversation) {
		conversation.addMediaTypeByName(’text/plain’)
	}
​
	this.handleGet = function(conversation) {
		return ’This is user #’ + conversation.locals.get(’userId’)
	}
}
​
resources = {
	session: {
		handleInit: function(conversation) {
			conversation.addMediaTypeByName(’text/plain’)
		},
		handleGet: function(conversation) {
			return ’This is session #’ + conversation.locals.get(’sessionId’)
		}
	},
	user: new UserResource()
}

Inversion of Control

app.routes = {
	...
	’/user/{userId}/preferences’: {type: ’dispatch’, id: ’user’, locals: {section: ’preferences’}},
	’/user/{userId}/profile: {type: ’dispatch’, id: ’user’, locals: {section: ’profile’}}
}

Other Programming Languages

app.routes = {
	...
	’/session/{sessionId}/’: ’@python:session’
}
​
app.dispatchers = {
	...
	python: ’/resources/’
}

Custom Dispatching

app.dispatchers = {
	...
	javascript: {
		dispatcher: ’/dispatchers/mydispatcher/’,
		resources: ’/resources/’
	}
}

app.dispatchers = {
	...
	special: {
		dispatcher: ’/dispatchers/myspecialdispatcher/’,
		customValue1: ’hello’,
		customValue2: ’world’
	}
}

The Internal URI-space

Virtual Hosts

Advantages of using a single container

1. Possibly simpler deployment: a single base directory, and all configuration is done by JavaScript inside the container, so it can be fully dynamic.
2. Less memory use.
3. You can use application.sharedGlobals to share state between applications. (Note that if they are running in multiple containers, you can use application.distributedGlobals instead. Will also work on VMs running on separate machines in the cluster. But distributed globals have to be serializable, of course.)

Advantages of using multiple containers

1. Possibly simpler deployment: several base directories can mean separate code/distribution repositories, and configuration may happen at the reverse-proxy level with your web frontend.
2. Crashes/deadlocks/memory leaks in one VM won’t affect others.
3. You can restart the VM for one container without affecting others that are running.

Servers

var server = new Server(Protocol.HTTP, 8080)
server.name = ’myserver’
component.servers.add(server)

Hosts

var host = new VirtualHost(component.context)
host.name = “privatehost” [used when attaching applications to the host]
component.hosts.add(component.defaultHost)

host.serverAddress = [string]
host.serverPort = [string]
host.hostScheme = [string]
host.hostDomain = [string]
host.hostPort = [string]
host.resourceScheme = [string]
host.resourceDomain = [string]
host.resourcePort = [string]

Applications

app.hosts = {
	’default’: ’/publicbaseuri/’
}

app.hosts = {
	’default’: ’/publicbaseuri/’,
	’privatehost’: ’/privatebaseuri’
}

app.hosts

Architecture Tips

Nouns vs. Verbs

• Good: “/service/{id}/status/”
• Bad: “/service/{id}/start/”, “/service/{id}/stop/”

Do You Really Need REST?

Hierarchies

1. A descendant resource belongs to its ancestor, such that resources have cascading relationships in the hierarchy. This implies two rules:
   1. Operations on a resource may affect descendants. This rule is most obvious when applied to the DELETE verb: for example, if you delete “/user/{id}/”, then it is expected that the resources at “/user/{id}/profile/” and “/user/{id}/preferences/” also be deleted. A PUT, too, would also affect the descendant resources.
   2. Operations on a resource should not affect ancestors. In other words, a descendant’s state is isolated from its ancestors. For example, if I send a POST to “/user/{id}/profile/”, the representation at “/user/{id}/” should remain unaltered.
2. A descendant resource belongs to its ancestor and also represents an aspect of its ancestor, such that operations on a resource can be fine-tuned to particular aspects of it. This implies three rules:
   1. Descendant representations are included in ancestor representations. For example, a GET on “/service/{id}/” would include information about the status that you would see if you GET on “/service/{id}/status/”. The latter URI makes it easier for the client to direct operations at the status aspect.
   2. Operations on a resource may affect descendants. See above.
   3. Operations on a resource will affect ancestors. This is the opposite of the above: the descendant’s state is not isolated from its ancestors. For example, a POST to “/service/{id}/status/” would surely also affect “/service/{id}/”, which includes the status.

Plural vs. Singular

Documenting Your URI-Space

/*
 * This resource represents a service running on the server. Servers have unique
 * IDs defined by integers. A service can be either active or inactive.
 *
 * Use POST to change the name or status of an existing service. You may
 * not use it change the ID of an existing service. PUT will create a new
 * service, and DELETE will stop and remove it.
 *
 * Implementation note: if you PUT a service with an ID that already exists, then
 * it will only stop and restart the service rather than removing/recreate it,
 * which would be too resource intensive. Use DELETE if you absolutely need the
 * service to be removed first, or set the "clean" query param to "true" to
 * force removal.
 *
 * URI: /service/{id:decimal}/
 * Aspects: /service/{id:decimal}/status/
 * Verbs: GET, POST, PUT, DELETE
 * Media types: application/json, application/xml, text/plain (as JSON)
 * Query params:
 *  indent: decimal - if non-zero will return a human-readable indented version
 *          of the representation with lines indented by the integer value
 *  clean: boolean - if "true" or "yes" or "1" wil force removal of an existing
 *         service during a PUT operation on an existing service
 *
 * Representation as application/json:
 *  {
 *   "id": number,
 *   "name": string (the service name),
 *   "status": string:"active"|"inactive"
 *  }
 *
 * POST/PUT payload as application/json:
 *  {
 *   "name": ...
 *   "status": ...
 *  }
 */
​
/*
 * This resource represents the status of a service. 
 *
 * DELETE on this resource is identical to PUT or POST with "inactive".
 * PUT and POST are handled identically.
 *
 * URI: /service/{id:decimal}/status/
 * Aspect of: /service/{id:decimal}/
 * Verbs: GET, POST, PUT, DELETE
 * Media types: text/plain
 *
 * Representation as text/plain:
 *   "active"|"inactive"
 */

Under the Hood

app.preheat

Implementing Resources

Comparison Table

Manual Resources

Mapping vs. Dispatching

handleGetInfo

Controlling the Formats

Client-Side Caching

Server-Side Caching

Integrating Textual Resources

Scriptlet Resources

Scriptlets

Working with Different Programming Languages

Controlling the Format

Server-Side Caching

Client-Side Caching

Scriptlet Plugins

Static Resources

Controlling the Format

Client-Side Caching

CSS and JavaScript

ZUSS

Integrating Java

Caching

Introduction: Integrated Caching

Server-Side Caching

Client-Side Caching

Content Negotiation

Programming

Introduction: Scripturian

JavaScript

Other Languages

Execution Environments

Bootstrap

Manual Resources and Handlers

Textual Resources

Cron Tasks

Managing State

conversation.locals

1. To easily share conversation-scope state between scriptlets written in different languages.
2. To share state for deferred conversations---see conversation.defer (page 1↓). In such cases, your language’s globals would not persist across the thread boundaries.
3. They are Prudence’s general mechanism for sending state to your code in a conversation. For example, captured URI segments are stored here (page 1↓) as well as document.cacheKeyPattern (page 1↓) variables.

Global Variables

The exception to this is code in /resources/, in which language globals might persist. To improve performance, Prudence caches the global context for these in memory, with the side effect that your language globals persist beyond a single user request. For various reasons, however, Prudence may reset this global context. You should not rely on this side effect, and instead always use application.globals (page 1↓).

application.globals vs. application.sharedGlobals

1. To save resources. For example, if an application detects that a database connection has already been opened by another application in the Prudence instance, and stored in application.sharedGlobals, then it could use that connection rather than create a new one. This would only work, of course, if a few applications share the same database, which is common in many deployments.
2. To send messages between applications. This would be necessary if operations in one application could affect another. For example, you could place a task queue in application.sharedGlobals, where applications could queue required operations. A thread in another application would consume these and act accordingly. Of course, you will have to plan for asynchronous behavior, and especially allow for failure. What happens if the consumer application is down? It may make more sense in these cases to use a persistent storage, such as a database, for the queue.

Note for Clojure flavor: All Clojure vars are VM-wide globals equivalent in scope to executable.globals. You usually work with namespaces that Prudence creates on the fly, so they do not persist beyond the execution. However, if you explicitly define a name space, then you can use it as a place for shared state. It will then be up to you to make sure that your namespace doesn’t collide with that of another application installed in the Prudence instance. Though this approach might seem to break our rule of thumb here, of preferring application.globals to application.sharedGlobals, it is more idiomatic to Clojure and Lisps more generally.

application.sharedGlobals vs. executable.globals

Concurrency

Note for Clojure flavor: Though Clojure goes a long way towards simplifying concurrent programming, it does not solve the problem of concurrent access to global state. You still need to read this section!

def get_connection()
	data_source = application.globals[’myapp.data.source’]
	if data_source is None:
		data_source = data_source_factory.create()
		application.globals[’myapp.data.source’] = data_source
	return data_source.get_connection()

This may seem like a very rare occurrence to you: another thread would have to set the value exactly between our comparison and our set. If your application has many concurrent users, and your machine has many CPU cores, it can actually happen quite frequently. And, even if rare, your application has a chance of breaking if just two users use it at the same time. This is not a problem you can gloss over, even for simple applications.

def get_connection()
	data_source = application.globals[’myapp.data.source’]
	if data_source is None:
		data_source = data_source_factory.create()
		data_source = application.getGlobal(’myapp.data.source’, data_source)
	return data_source.get_connection()

def get_connection()
	lock = application.getGlobal(’myapp.data.source.lock’, RLock())
	lock.acquire()
	try:
		data_source = application.globals[’myapp.data.source’]
		if data_source is None:
			data_source = data_source_factory.create()
			application.globals[’myapp.data.source’] = data_source
		return data_source.get_connection()
	finally:
		lock.release()

def get_connection(lock_access=False)
	if lock_access:
		lock = application.getGlobal(’myapp.data.source.lock’, RLock())
		lock.acquire()
	try:
		data_source = application.globals[’myapp.data.source’]
		if data_source is None:
			data_source = data_source_factory.create()
			if lock_access:
				application.globals[’myapp.data.source’] = data_source
			else:
				data_source = application.getGlobal(’myapp.data.source’, data_source)
		return data_source.get_connection()
	finally:
		if lock_access:
			lock.release()

APIs

Using the Documentation

The Prudence team has spent a great amount of time on meticulously documenting the APIs. Please send us a bug report if you find a mistake, or think that the documentation can use some clarification!

JavaScript: conversation.redirectSeeOther(’http://newsite.org/’)
Python:     conversation.redirectSeeOther(’http://newsite.org/’)
Ruby:       $conversation.redirect_see_other ’http://newsite.org/’
PHP:        $conversation->redirectSeeOther(’http://newsite.org/’);
Groovy:     conversation.redirectSeeOther(’http://newsite.org/’)
Clojure:    (.. conversation redirectSeeOther "http://newsite.org/")

Prudence APIs

Scripturian API

JavaScript Libraries

• /sincerity/calendar/: Sincerity.Calendar
• /sincerity/classes/: Sincerity.Classes
• /sincerity/cryptography/: Sincerity.Cryptography
• /sincerity/files/: Sincerity.Files
• /sincerity/iterators/: Sincerity.Iterators
• /sincerity/json/: Sincerity.JSON
• /sincerity/jvm/: Sincerity.JVM
• /sincerity/localization/: Sincerity.Localization
• /sincerity/lucene/: Sincerity.Lucene
• /sincerity/mail/: Sincerity.Mail
• /sincerity/objects/: Sincerity.Objects
• /sincerity/rhino/: Sincerity.Rhino
• /sincerity/templates/: Sincerity.Templates
• /sincerity/xml/: Sincerity.XML

• /prudence/blocks/: Prudence.Blocks
• /prudence/lazy/: Prudence.Lazy
• /prudence/logging/: Prudence.Logging
• /prudence/resources/: Prudence.Resources
• /prudence/tasks/: Prudence.Tasks

• /sincerity/annotations/: Sincerity.Annotations
• /sincerity/container/: Sincerity.Container
• /prudence/routing/: Sincerity.Routing
• /prudence/lazy/: Sincerity.Lazy

Working in a Cluster

Shared Globals

Task Farming

Accepting Uploads

Cookies

Filtering

How Routing Works

Injection

Built-in Filters

Configuring Applications

settings.js

app.settings

app.settings.description

app.settings.errors

app.settings.code

app.settings.uploads

app.settings.mediaTypes

app.globals

routing.js

app.hosts

app.routes

app.errors

app.dispatchers

Scheduling Tasks (Cron)

Default Directories

Configuring the Component

/component/servers/

/component/clients/

/component/hosts/

/component/services/

caching

distributed

executor

log

singleton

scheduler

status

version

/component/templates/

Debugging

Logging

application.logger

application.getSubLogger

Configuring Logging

Debug Page

Deployment

The Joys of Sincerity

Configuration-by-Script

Plugins

Deployment Strategies

Synchronization

Packaging

Version Control

Directory Organization

Sincerity Standalone

Operating System Service

Monitoring

Security

SSL

HTTP Authentication

Locked-Down User

Firewall

Proxying

Nginx

Apache

Deploying Clusters

Loadbalancing

Security Concerns

Configuring Hazelcast

Cache Backends

Utilities for Restlet

Utility Restlets

• CacheControlFilter: A Filter that adds cache control directives to responses.
• Injector: A Filter that adds values to the request attributes before moving to the next restlet. It allows for a straightforward implementation of IoC (Inversion of Control).
• StatusRestlet: A restlet that always sets a specific status and does nothing else.

Client Data

• CompressedStringRepresentation: This is a ByteArrayRepresentation that can be constructed using text and an encoding, which it then compresses into bytes according the encoding. This is an alternative to using an Encoder filter, allowing you direct control over and access to the final representation.
• ConversationCookie: A modifiable extension of a regular Cookie. Tracks modifications, and upon calling save() stores them as a CookieSetting, likely in the Response. Also supports cookie deletion via remove().
• FormWithFiles: A form that can parse MediaType.MULTIPART_FORM_DATA entities by accepting file uploads. Files will appear as parameters of type FileParameter.

Redirection

• CapturingRedirector: A Redirector that keeps track of the captured reference.
• NormalizingRedirector: A Redirector that normalizes relative paths. This may be unnecessary in future versions of Restlet. See Restlet issue 238.

Fallback Routing

• Fallback: A restlet that delegates Restlet.handle(Request, Response) to a series of targets in sequence, stopping at the first target that satisfies the condition of wasHandled. This is very useful for allowing multiple restlets a chance to handle a request, while “falling back” to subsequent restlets when those “fail.”
• FallbackRouter: A Router that takes care to bunch identical routes under Fallback restlets.

Resolver Selection

• ResolvingTemplate: A Template that allows control over which Resolver instances it will use.
• ResolvingRedirector: A Redirector that uses ResolvingTemplate.
• ResolvingRouter: A Router that uses ResolvingTemplate for all routes.

Web Filters

• CssUnifyMinifyFilter: A Filter that automatically unifies and/or compresses CSS source files, saving them as a single file. Unifying them allows clients to retrieve the CSS via one request rather than many. Compressing them makes their retrieval faster. Compression is done via CSSMin.
• JavaScriptUnifyMinifyFilter: A Filter that automatically unifies and/or compresses JavaScript source files, saving them as a single file. Unifying them allows clients to retrieve the JavaScript via one request rather than many. Compressing them makes their retrieval faster. Compression is done via John Reilly's Java port of Douglas Crockford’s JSMin.
• ZussFilter: A Filter that automatically parses ZUSS code and renders CSS. Also supports minifying files, if the “.min.css” extension is used.

Upgrading from Prudence 1.1

Upgrading Applications

1. Start with a new application based on the default template.
   1. Rename old application (add “-old”), for example: “myapp-old”
   2. Use the “prudence” tool to create a new application for your application name:

      sincerity prudence create myapp
      

2. Copy over individual settings from settings.js, using the new Prudence Manual to find equivalences.
3. Copy over individual settings from routing.js, using the new Prudence Manual to find equivalences. Prudence 2.0 has a far more powerful and clearer routing configuration.
4. Rename “/resources/” files to add a “.m.” pre-extension (they are now called “manual resources”). Under Unix-like operation systems, you can rename the all files in the tree via a Perl expression using something like this:

   find . -name "*.js" -exec rename -v ’s/\.js$/\.m.js/i’ {} \;
   

5. Rename “/web/dynamic/” files to add a “.s.” pre-extension (they are now called “scriptlet resources”). Under Unix-like operation systems, you can rename the all files in the tree via a Perl expression using something like this:

   find . -name "*.html" -exec rename -v ’s/\.html$/\.s.html/i’ {} \;
   

6. Merge “/web/dynamic/” and “/web/static/” into “/resources/”.
7. Move “/web/fragments/” to “/libraries/scriptlet-resources”.

Upgrading the Component