|Read more about this book|
(For more resources on Alfresco, see here.)
Node references are important.
Tip: Node references are used to identify a specific node in one of the stores in the repository. You construct a node reference by combining a Store Reference such as workspace://SpacesStore with an identifier.
The identifier is a Universally Unique Identifier (UUID) and it is generated automatically when a node is created. A UUID looks something like this: 986570b5-4a1b-11dd-823c-f5095e006c11 and it represents a 128-bit value. A complete Node Reference looks like workspace://SpacesStore/986570b5-4a1b-11dd-823c-f5095e006c11.
The node reference is one of the most important concepts when developing custom behavior for Alfresco as it is required by a lot of the application interface methods.
Avoid CRUD operations directly against the database.
Tip: One should not do any CRUD operations directly against the database bypassing the foundation services when building a custom solution on top of Alfresco. This will cause the code to break in the future if the database design is ever changed. Alfresco is required to keep older APIs available for backward compatibility (if they ever change), so it is better to always use the published service APIs.
Query the database directly only when:
- The customization built with available APIs is not providing acceptable performance and you need to come up with a solution that works satisfyingly
- Reporting is necessary
- Information is needed during development for debugging purposes
- For bootstrapping tweaking, such as when you want to run a patch again
Executing patches in a specific order
Tip: If we have several patches to execute and they should be in a specific order, we can control that with the targetSchema value. The fixesToSchema value is set to Alfresco’s current schema version (that is, via the version.schema variable), which means that this patch will always be run no matter what version of Alfresco is being used.
It is a good idea to export complex folder structures into ACP packages.
Tip: When we set up more complex folder structures with rules, permission settings, template documents etc, it is a good idea to export them into Alfresco Content Packages (ACP) and store them in the version control system. The same is true for any Space Templates that we create. These packages are also useful to include in releases.
Deploying the Share JAR extension
Tip: When working with Spring Surf extensions for Alfresco Share it is not necessary to stop and start the Alfresco server between each deployment. We can set up Apache Tomcat to watch the JAR file we are working with and tell it to reload the JAR every time it changes.
Update the tomcat/conf/context.xml configuration file to include the following line:
Now every time we update this Share extension, JAR Tomcat will reload it for us and this shortens the development cycle quite a bit. The Tomcat console should print something like this when this happens:
INFO: Reloading context [/share]
To deploy a new version of the JAR just run the deploy-share-jar ant target:
C:3340_03_Codebestmoneyalf_extensionstrunk>ant -q deploy-share-jar
[echo] Packaging extension JAR file for share.war
[echo] Copies extension JAR file to share.war WEB-INF lib
Total time: 0 seconds
Debugging AMP extensions
Tip: To debug AMP extensions, start the Alfresco server so that it listens for remote debugging connections; or more correctly, start the JVM so that it listens for remote debugging connection attempts. This can be done by adding the following line to the operating system as an environment variable:
CATALINA_OPTS=-Dcom.sun.management.jmxremote -Xdebug -
This means that any Alfresco installation that we have installed locally on our development machine will be available for debugging as soon as we start it.
Change the address as you see fit according to your development environment.
With this setting we can now debug both into Alfresco’s source code and our own source code at the same time.