Using the code for the training

You can get the complete code for this training from GitHub.

The code-package

The package ploneconf.site contains the complete code for this training excluding exercises. It is automatically downloaded from GitHub when you run buildout.

The master branch of that repository holds the code of the final chapter of this training. Each chapter that adds code to the package has a tag that can be used to get the code for that chapter.

Getting the code for a certain chapter

To use the code for a certain chapter you need to checkout the appropriate tag for the chapter. The package will then contain the complete code for that chapter (excluding exercises).

If you want to add the code for the chapter yourself you have to checkout the tag for the previous chapter.

Here is an example:

git checkout views_2

The names of the tags are the same as the URL of the chapter. The tag for the chapter https://training.plone.org/mastering-plone/registry.html is registry. You can get it with git checkout registry.

Moving from chapter to chapter

To change the code to the state of the next chapter checkout the tag for the next chapter:

git checkout views_3

If you made any changes to the code you have to get them out of the way first. This inviolved two things

Warning

Make sure you have no new files or changes in the folder structure of ploneconf.site that you want to keep because the following will delete them!!!

git clean -fd
git stash

This does two things:

1. It deletes any files that you added and are not part of the package.

2. It will move away changes to files that are part of the package but not delete them. You can get them back later. You should learn about the command git stash before you try reapply stashed changes.

Tags

These are the tags for which there is code:

Chapter	Tag-Name
About Mastering Plone
Introduction
Installation & Setup
The Case Study
The Features of Plone
The Anatomy of Plone
What's New in Plone 5, 5.1 and Plone 5.2
Configuring and Customizing Plone "Through The Web"
Theming
Extending Plone
Extend Plone With Add-On Packages
Dexterity I: "Through The Web"
Buildout I	buildout_1
Write Your Own Add-Ons to Customize Plone	eggs1
Return to Dexterity: Moving contenttypes into Code	export_code
Views I	views_1
Page Templates	zpt
Customizing Existing Templates	zpt_2
Views II: A Default View for "Talk"	views_2
Views III: A Talk List	views_3
Testing in Plone	testing
Behaviors	behaviors_1
Writing Viewlets	viewlets_1
Programming Plone
IDEs and Editors
Dexterity Types II: Growing Up	dexterity_2
Custom Search
Turning Talks into Events	events
User Generated Content	user_generated_content
Resources	resources
Using Third-Party Behaviors	thirdparty_behaviors
Dexterity Types III: Python	dexterity_3
Relations	relations
Manage Settings with Registry, Control Panels and Vocabularies	registry
Creating a Dynamic Front Page	frontpage
Creating Reusable Packages
More Complex Behaviors
A Viewlet for the Votable Behavior
Making Our Package Reusable
Using starzel.votable_behavior in ploneconf.site
Releasing Your Code
Buildout II: Getting Ready for Deployment

Updating the code-package

This section is for trainers who want to update the code in ploneconf.site after changing something in the training documentation.

The current model uses only one branch of commits and maintains the integrity through rebases.

It goes like this:

• Only one one branch (master)

• Write the code for chapter 1 and commit

• Write the code for chapter 2 and commit

• Add the code for chapter 3 and commit

• You realize that something or wrong in chapter 1

• You branch off at the commit id for chapter 1 git checkout -b temp 123456

• You cange the code and do a commit. git commit -am 'Changed foo to also do bar'

• Switch to master and rebase on the branch holding the fix which will inject the new commit into master at the right place: git checkout master git rebase temp That inserts the changes into master in the right place. You only maintain a master branch that is a sequence of commits.

• Then you need to update your chapter-docs to point to the corresponding commit ids:

  • chapter one: git checkout 121431243

  • chapter two: git checkout 498102980

Additionally you can

• set tags on the respective commits and move these tags. This way the docs do not need to be changed when the code changes.

• squash the commits between the chapters to every chapter is one commit.

To move tags after changes you do:

• Move a to another commit: git tag -a <tagname> <commithash> -f

• Move the tag on the server git push --tags -f

The final result should look like this: