What is the difference between page and component controller?

Question

What is the difference between page and component controller?

I stuck over the question when I read the documentation:

Non-primitive Apex data types such as lists and sObjects are passed by reference to component's controller. This means that if component's controller changes the name of an account, the changes are available in page's controller.

Why I am asking here: after googling page controller salesforce, component controller salesforce I got confused even more.

But I suspect that here they mean by component controller the Lightning controller and by page controller the Visualforce controller. But I never met a situation(or heard about one) where the data would be passed between a Visualforce page and Lightning component.

So, I would be grateful if someone would substantiate my suspicion or disproof it. In order to avoid x-y problem: the result I want to get here is to understand the excerpt cited above from the documentation.

Answer 1

A component controller is the Apex controller of a Visualforce component, a reusable unit of functionality that can be embedded in one or several Visualforce pages.

The page controller is the Apex controller of the (containing) Visualforce page.

While Lightning also uses component controllers, they're written in JavaScript and follow a very different architecture. There is a later section of the Visualforce Developer Guide that specifically covers Visualforce component development.

The snippet you quote:

Non-primitive Apex data types such as lists and sObjects are passed by reference to component's controller. This means that if component's controller changes the name of an account, the changes are available in page's controller.

explains the reference style of attributes passed between the parent page and the embedded component. As in many programming languages, complex types are passed by reference rather than by value, as primitives are. This means that the controllers for the page and the component share a reference to the same object instance for objects passed as parameters, and changes made by one controller are visible to the other.

I think the example quoted is a little confusing by the use of Account. Note that DML works the same way in Visualforce as anywhere else - you have to query to see any changes made to objects by other code. It's referring to an sObject instance representing an Account here.

Unfortunately, I don't believe that Trailhead currently provides any modules that specifically touch on Visualforce component development. It's not the current direction of Salesforce's development plans - that'd be Lightning.

Answer 2

A Visualforce Component is one that starts off with <apex:component>, while a Lightning Component is one that starts off with <aura:component>. They're two different technologies, with Visualforce Components being as old as Visualforce itself (about 11-12 years now).

In Visualforce, you can do something like this:

<apex:page standardController="Account" extensions="pageController">
  <c:myCustomComponent thePagecontroller="{!pageControllerRef}" />
</apex:page>

---

<apex:component controller="componentController">
  <apex:attribute name="thePageController" assignTo="{!pageCtrlRef}" 
    description="Reference to page controller" type="pageController" />
</apex:component>

---

While this looks almost exactly like Lightning, note that c:myCustomComponent is a Visualforce Component, not a Lightning Component. Visualforce Components serve the same basic principle as Lightning Components, but for Visualforce.

You'll find the ability to create Visualforce components in the Developer Console as well as in Setup, right beneath the Develop > Visualforce Page menu item.

I suspect that one of the intents of Lightning Components was to feel as familiar as possible to Visualforce Components to ease the transition to Lightning. One core difference between the two is that Lightning Components are rendered on the client, in JavaScript, while Visualforce Components are rendered on the server, and delivered as normal HTML.