--- title: Interfaces and Abstractions order: 2 layout: page --- [[components.interfaces]] = Interfaces and Abstractions *_This section has not yet been updated for Vaadin Framework 8_* ((("interfaces"))) Vaadin user interface components are built on a skeleton of interfaces and abstract classes that define and implement the features common to all components and the basic logic how the component states are serialized between the server and the client. This section gives details on the basic component interfaces and abstractions. The layout and other component container abstractions are described in <>. The interfaces that define the Vaadin data model are described in <>. [[figure.components.interfaces]] .Component interfaces and abstractions image::img/component-abstractions-hi.png[width=100%, scaledwidth=100%] All components are connectors that connect to the client-side widgets. ((("[classname]#Serializable#"))) In addition to the interfaces defined within the Vaadin framework, all components implement the [classname]#java.io.Serializable# interface to allow serialization. Serialization is needed in many clustering and cloud computing solutions. [[components.interfaces.component]] == [classname]#Component# Interface ((("[interfacename]#Component# interface"))) The [interfacename]#Component# interface is paired with the [classname]#AbstractComponent# class, which implements all the methods defined in the interface. === Component Tree Management Components are laid out in the user interface hierarchically. The layout is managed by layout components, or more generally components that implement the [classname]#ComponentContainer# interface. Such a container is the parent of the contained components. The [methodname]#getParent()# method allows retrieving the parent component of a component. While there is a [methodname]#setParent()#, you rarely need it as you usually add components with the [methodname]#addComponent()# method of the [classname]#ComponentContainer# interface, which automatically sets the parent. A component does not know its parent when the component is still being created, so you can not refer to the parent in the constructor with [methodname]#getParent()#. Attaching a component to an UI triggers a call to its [methodname]#attach()# method. Correspondingly, removing a component from a container triggers calling the [methodname]#detach()# method. If the parent of an added component is already connected to the UI, the [methodname]#attach()# is called immediately from [methodname]#setParent()#. [source, java] ---- public class AttachExample extends CustomComponent { public AttachExample() { } @Override public void attach() { super.attach(); // Must call. // Now we know who ultimately owns us. ClassResource r = new ClassResource("smiley.jpg"); Image image = new Image("Image:", r); setCompositionRoot(image); } } ---- The attachment logic is implemented in [classname]#AbstractComponent#, as described in <>. ((("[classname]#Component# interface"))) [[components.interfaces.abstractcomponent]] == [classname]#AbstractComponent# ((("[classname]#AbstractComponent#", id="term.components.interfaces.abstractcomponent", range="startofrange"))) [classname]#AbstractComponent# is the base class for all user interface components. It is the (only) implementation of the [classname]#Component# interface, implementing all the methods defined in the interface. When creating a new component, you should extend [classname]#AbstractComponent# or one of its subclasses. (((range="endofrange", startref="term.components.interfaces.abstractcomponent")))