Trace:
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision Next revision Both sides next revision | ||
|
jvx:reference [2020/06/10 12:52] cduncan [Creating custom components] |
jvx:reference [2020/06/10 12:55] cduncan [An important note about the component hierarchy] |
||
|---|---|---|---|
| Line 238: | Line 238: | ||
| Because UI component is an abstract component designed for exactly this usage, the example might not be the most exciting one, but it clearly illustrates the mechanic. | Because UI component is an abstract component designed for exactly this usage, the example might not be the most exciting one, but it clearly illustrates the mechanic. | ||
| - | ===== Bolting on functionality ===== | + | ===== Bolting on Functionality ===== |
| - | Also from from the [[#part_about_creating_custom_components|part about creating custom components]] we can reuse the ''%%PostfixedLabel%%'' as example: | + | Also, from the [[#part_about_creating_custom_components|part about creating custom components]], we can reuse the ''%%PostfixedLabel%%'' as example: |
| <code java> | <code java> | ||
| Line 251: | Line 251: | ||
| }; | }; | ||
| </code> | </code> | ||
| - | Now ''%%testLabel%%'' will be using the ''%%PostfixedLabel%%'' internally, but with no indication to the user of the object that this is the case. This allows to extend the functionality of a component completely transparently, especially in combination with functions which do return an ''%%UIComponent%%'' and similar. | + | Now ''%%testLabel%%'' will be using the ''%%PostfixedLabel%%'' internally but with no indication to the user of the object that this is the case. This allows us to extend the functionality of a component completely transparently, especially in combination with functions that return a ''%%UI component%%'' and similar. |
| - | ===== An important note about the component hierarchy ===== | + | ===== An Important Note About the Component Hierarchy ===== |
| If we create a simple component extensions, like the ''%%BeepComponent%%'' above, it is important to note that there is one other layer of indirection in regards to the hierarchy on the technology layer. If we create a simple frame with the ''%%BeepComponent%%'' in it, one might expect the following hierarchy: | If we create a simple component extensions, like the ''%%BeepComponent%%'' above, it is important to note that there is one other layer of indirection in regards to the hierarchy on the technology layer. If we create a simple frame with the ''%%BeepComponent%%'' in it, one might expect the following hierarchy: | ||
| Line 268: | Line 268: | ||
| \-Button | \-Button | ||
| </code> | </code> | ||
| - | With the BeepComponent added and its sub-components as its children. However, the actual hierarchy looks like this: | + | with the BeepComponent added and its subcomponents as its children. However, the actual hierarchy looks like this: |
| <code> | <code> | ||
| Line 280: | Line 280: | ||
| \-Button | \-Button | ||
| </code> | </code> | ||
| - | That is because such extended components are not “passed” to the Technology, they do only exist on the UI layer because they do not have a Technology component which could be used. That is done by adding the ''%%UIComponent%%'' to the UI parent, but for adding the actual Technology component the set UIResource is used. | + | That is because such extended components are not “passed” to the technology; they only exist on the UI layer because they do not have a Technology component which could be used. That is done by adding the ''%%UI component%%'' to the UI parent, but for adding the actual technology component the set UI resource is used. |
| ===== The special case of containers ===== | ===== The special case of containers ===== | ||