Snapshot Sitecore – commit to git, export package

Go to your project directory where the .git folder is. Your Visual Studio source files should
all be somewhere in this directory.

Go to the branch you want
$ git checkout -b Ricky_Tsao

Commit your changes
$ git commit -a -m “added js to FAQ”

Push your changes
$ git push origin Ricky_Tsao

The files in your Visual Studios have been committed.

Now we need to Use Package Designer to pack what you’ve done.



Hash Map (chaining)


ref –

Hash Map with Chaining

The load factor is a measure of how full the hash table is allowed to get before its capacity is automatically increased.

When the number of entries in the hash table exceeds the product of the load factor and the current capacity,
the hash table is rehashed (that is, internal data structures are rebuilt) so that the hash table has
approximately twice the number of buckets.

The Node

.h file

.cpp file

The Hash Map


The way we go about creating the Hash Table is by using an array of pointers. Each pointer at array[i] will point to a node. That node can link to another node. This is so that we can have an array of linked list. Which by definition, is what constitutes a chained hash map.

Thus, we use double pointers to point to this array of pointers: LinkedHashEntry ** table.

*table (or table[0]) dereferences the 1st array element.
*(table+1) (or table[1]) dereferences the 2nd array element.
..and so on

In order to allocate memory, we allocate this array of pointers on the heap.

Think of it like this:

We want to allocate on the heap (new)
an array of certain size ([MAX])
of LinkedHashEntry pointers (LinkedHashEntry *):

LinkedHashEntry ** table = new LinkedHashEntry * [MAX]

By definition, we always have a pointer pointing to the address of the first element of the array.

In every array, we always assign an array anchor (a pointer) to the 1st element of the array.
For example, an array of integers, int * i = new int [8];

int * i points to the first integer element’s address.
*i will dereference and get the int value.

In our case, since our first element is a pointer, we need a pointer to a pointer to act as the array anchor, and that is
why we use LinkedHashEntry ** table.

Now, we have an array of LinkedHashEntry pointers, and we are set to work.


While certain operations for a given algorithm may have a significant cost in resources, other operations may not be as costly.

Amortized analysis considers both the costly and less costly operations together over the whole series of operations of the algorithm. This may include accounting for different types of input, length of the input, and other factors that affect its performance

insertion O(1) average and amortized case complexity, however it suffers from O(n) worst case time complexity.

Hash tables suffer from O(n) worst time complexity due to two reasons:

If too many elements were hashed into the same key. Thus, it degrades into a linked list
for that particular slot. Searching through this list may take O(n) time. see 2), where it keeps appending elements at the same slot.

Once a hash table has passed its load balance, it has to rehash [create a new bigger table, and re-insert each element to the table].

The reason why it is O(1) average and amortized case because:

  • It is very rare that many items will be hashed to the same key
  • if you chose a good hash function and you don’t have too big load balance.
  • The rehash operation, which is O(n), can at most happen after n/2 ops
  • which are all assumed O(1): Thus when you sum the average time per op, you get : (n*O(1) + O(n)) / n) = O(1)


Deletion has the same concept as Insertion. Amortized case O(1), worst time O(n).

deleteNode is just a simple function that sets a LinkedHashEntry pointer to NULL and wipes out everything.

recurseAndRemove uses recursion to run through a list of LinkedHashEntry nodes, and remove the node with the specified key.

The list of nodes is given by LinkedHashEntry ** temp. Pointer of a pointer means that the double pointer points to the the address of a pointer. That pointer points to the address of the node.


Hence, if we want to reassign the pointer at this->table[i] to another node, it means:

this->table[i] is a pointer, thus we have to use a double pointer (HashEntry ** temp) to point to this->table[i]. Deference it like this (*temp) to control the pointer this->table[i] itself….and assign it to another node as shown in the image.

If we simply have a pointer like HashEntry * singlePtr = this->table[i], it won’t work because singlePtr will be pointing to whatever this->table[i] is pointing to. singlePtr is pushed onto the local stack, and has nothing to do with the pointer that is this->table[i].

singlePtr simply points to whatever this->table[i] points to. singlePtr is pushed onto the local stack

Once you understand this, the rest is just simple recursion and node traversal.

There are 2 cases:

  • You need to remove the first node. This means in order to get control of the first pointer, you need to get the address of the initial pointer, dereference it (at this point, you have full control of the pointer) and point it
  • You need to remove 2nd..and after node. This is simple because dereferencing the temp pointer gives you full control of the next pointer.

Controller Renderer, Static rendering, Dynamic rendering

ref –

Static Rendering





It will then produce something like this:

Enter code for when we use the @Model object. The @Model object is a representation of the template data that we create under Content.
@Model’s field properties include the fields that you specify in your Data Template. Let’s see how it works.

Say in your data template fields, you have title and AdditionalText

We can display the field in our cshtml by using @Html.Sitecore().Field(“field_name”)

Setting up the Layout attached to your Data Template

The page you create in Content uses a Data Template. When you create your Data Template, you specify which layout you it to use.


In our case, we created a layout DefaultMVCLayout, and we use that. It corresponds to the DefaultMVCLayout.cshtml in our Visual Studios. Let’s place our Rendering in that layout file.

We can statically bind our PageHeader.cshtml to the layout by using @Html.Sitecore().ViewRendering

Dynamic Rendering

Dynamic rendering involves using a Placeholder instead. In that Placeholder, you can specify what kinds of renderings to enter. That way, you can enter all different sorts of headers, footers, menus….etc.


Controller Rendering

First of all, create a controller. Right click on the folder controller.



Type in your controller name say HelloWorldController

That controller only has one method called Index. Pass in a parameter DateTime.Now. Which is a static method to get the current time.

Create View for the Controller

Under your Views folder, you will see that a folder is automatically created called HelloWorld.

Right click on the folder, Add > View. Call it Index. Make sure Create as partial View is checked.


Then insert code to show the current time.

Make Sitecore aware this controller exists.

right click Rendering > Insert > Controller Rendering.


Call it Page Content

Then under Controller, call it HelloWorld WITHOUT THE word CONTROLLER!


When you encounter this rendering, I want you to execute this Controller and return this Action.

After the controller, let’s go and add this to our Content Page’s presentation details. Click on your content page. Then click on ‘Presentation’ tab.
On the ribbon, click Details.


We add the controller to the page layout that is used by our ‘Content Page’
We add a Control, and add our controller as shown.
Then we add it to the placeholder ‘content’.

Then publish.

Make sure you deploy your files in Visual Studios.

Then you’ll see that DefaultMVCLayout.cshtml, you can see that the code we put in there matches what we have on the output.


ref –