The extension directory in the Alfresco webapp and the web-extension directory in the Share webapp offer one way for a developer to selectively override and extend code in the standard codebase, without physically modifying these files (another, better way to create extensions is to package them in modules and deploy as AMP or jar-files).
The Alfresco extension directory is for repository-tier extensions, while the Share web-extension is for web-tier extensions.
You can override a file by re-creating the same directory structure and filename in the extension directory as that of the targeted file and adding your own code in it.
Of course you can also add entirely new files in these directories.
So what do we have in the content-article project?
In extension folder:
- web-client-config-custom.xml: Configuration for the (legacy) Alfresco Explorer application. Explorer is a JSP-based UI and is replaced by the Share Surf application (However, not all functionality available in Explorer is implemented in Share).
- *-context.xml: Spring Bean declarations. Alfresco makes heavy use of Spring configuration to bind the application together. There are literally hundreds of beans. This is very powerful and flexible allowing you to hook up your own beans and reconfigure as needed. Placed in the right locations they are automatically loaded on startup of the server. The root bean of the whole application is application-context.xml in WEB-INF/classes/alfresco.
- someco-workflow-context.xml: register the workflows, the workflow dictionary model and workflow message bundle (.properties file)
- someco-scripts-context.xml: register a Java class for the java-backed webscript that retrieves a Review from the repository (more later).
- someco-model-context.xml: register the custom Dictionary model that defines the Whitepaper types among others.
- someco-action-context.xml: register some custom actions.
In extension/messages folder:
- scWorkflow.properties: message bundle for the custom dictionary model. Configured in someco-model-context.xml
- somecoactions.properties: message bundle for the custom actions.
In extension/model folder:
- scModel.xml: Defines the data model for the extension by defining types, properties, associations, aspects, etc. The model defines its own namespace, and imports other models to reuse and extend the types defined here.
- scWorkflowModel.xml: Defines the types that correspond to the usertasks defined in the workflow(s). The properties of these types can be manipulated as the workflow progresses and determine the contents of the task forms (together with the Share form configuration for the type)
In extension/templates/webscripts/com/someco/bpm:
- review.get.desc.xml: Declaration of a webscript where you specify its name, REST url, return type of the webscript (in this case html), permission level, whether or not to run in an transaction, etc.
- review.get.html.ftl: The freemarker template that constructs the html. In this case where we have a java-backed webscript there is a Java class that is the controller for this template (the view). The controller can also be written in js (Rhinoscript) In this case that the controller is in content-article\src\java\com\someco\scripts\WebClient.java.
In extension/workflows:
- *.bpmn.xml: BPMN Workflow process definitions for the Activiti engine. Here you define usertasks and the flows between them. The usertasks have an attribute activi:formKey that refers to both the type defined in the workflow dictionary model as the Share form configuration used to render the task form in Share.
- The rest of the files are automatically created when using the activiti bpmn plugin in eclipse.
In src/web:
- JSP's for the Explorer interface and Faces configuration. I myself am a Share user and I have never used Explorer. I don't know anything about this stuff 😉
In src/java finally are all the Java classes.
Hope this helps. Regarding your other questions:
- For defining workflows you at least have to define a workflow dictionary model, a bpmn definition (if using the newer Activiti workflow engine, rather than the legacy jBPM engine), a message bundle and a Spring context file to hook it all up in the server.
- You need to make a decision whether to use the Share UI (recommended) or the older Explorer UI. If using share you will need to define form definitions for your workflow tasks in the file share-config-custom.xml (the Share equivalent for web-client-config-custom.xml.
How do you learn about developing on Alfresco? This depends a bit on what you want to achieve and how far you want to go with your customizations. You will find that there is no one good central location where you can find everything you need.
I would advice to start looking in the regular docs (docs.alfresco.com) and the wiki, but then quickly turn to googling to do a targeted search to find what you need. If you are doing more heavy customizations I would strongly advice to check out the Alfresco code from SVN and learn from that. Its the best way to see how things ought to be done.