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:31] cduncan [The Patterns] |
jvx:reference [2020/06/10 13:02] cduncan [The special case of containers] |
||
|---|---|---|---|
| Line 39: | Line 39: | ||
| ==== Extension ==== | ==== Extension ==== | ||
| - | Next comes the extension layer. Components from the technology are extended to support needed features of [[https://sourceforge.net/projects/jvx/|JVx]]. This includes creating bindings for the databook, additional style options, and changing of behavior, if necessary. From time to time, this also includes creating components from scratch if the provided ones do not meet the needs or there simply are none with the required functionality. For the most part, we do our best that these layers can be used without [[https://sourceforge.net/projects/jvx/|JVx]], meaning that they represent a solitary extension to the technology. A very good example is our JavaFX implementation, which compiles into two separate jars, the first being the complete [[https://sourceforge.net/projects/jvxfx/|JVx/JavaFX]] stack, the second being stand-alone JavaFX extensions that can be used in any application and without [[https://sourceforge.net/projects/jvx/|JVx]]. | + | Next comes the extension layer. Components from the technology are extended to support needed features of [[https://sourceforge.net/projects/jvx/|JVx]]. This includes creating bindings for the databook, additional style options, and changing of behavior, if necessary. From time to time, this also includes creating components from scratch if the provided ones do not meet the needs, or there simply are none with the required functionality. For the most part, we do our best that these layers can be used without [[https://sourceforge.net/projects/jvx/|JVx]], meaning that they represent a solitary extension to the technology. A very good example is our JavaFX implementation, which compiles into two separate jars, the first being the complete [[https://sourceforge.net/projects/jvxfx/|JVx/JavaFX]] stack, the second being stand-alone JavaFX extensions that can be used in any application and without [[https://sourceforge.net/projects/jvx/|JVx]]. |
| Theoretically, one can skip this layer and directly jump to the implementation layer, but, so far, it has proven necessary (for cleanliness of the code, object structure, and sanity reasons) to create a separate extension layer. | Theoretically, one can skip this layer and directly jump to the implementation layer, but, so far, it has proven necessary (for cleanliness of the code, object structure, and sanity reasons) to create a separate extension layer. | ||
| Line 168: | Line 168: | ||
| ===== Piecing It Together ===== | ===== Piecing It Together ===== | ||
| - | With all this in mind, we know now that [[https://sourceforge.net/projects/jvx/|JVx]] has swapable implementations underneath its UI layer for each technology it utilizes: | + | With all this in mind, we know now that [[https://sourceforge.net/projects/jvx/|JVx]] has swappable implementations underneath its UI layer for each technology it utilizes: |
| {{:jvx:reference:multi-layers.png?nolink|Multiple Extensions/Implementations/Technologies can be used}} | {{:jvx:reference:multi-layers.png?nolink|Multiple Extensions/Implementations/Technologies can be used}} | ||
| Line 176: | Line 176: | ||
| ===== What else? ===== | ===== What else? ===== | ||
| - | That is how [[https://sourceforge.net/projects/jvx/|JVx]] works in regards to the UI layer. It depends on “technology specific stacks” which can be swapped out and implemented for pretty much every GUI framework out there. We currently provide support for Swing, JavaFX, and Vaadin, but we also had implementations for GWT and Qt. Additionally, we do support a “headless” implementation which uses lightweight objects which can be serialized and send over the wire without much effort. | + | That is how [[https://sourceforge.net/projects/jvx/|JVx]] works in regards to the UI layer. It depends on “technology-specific stacks”, which can be swapped out and implemented for pretty much every GUI framework out there. We currently provide support for Swing, JavaFX, and Vaadin, but we also had implementations for GWT and Qt. Additionally, we do support a “headless” implementation, which uses lightweight objects that can be serialized and send over the wire without much effort. |
| ===== Adding a New Technology ===== | ===== Adding a New Technology ===== | ||
| Line 186: | Line 186: | ||
| Even though the stack of [[https://sourceforge.net/projects/jvx/|JVx]] is more complicated compared with other GUI or application frameworks, this complexity is set off by the benefits it brings. One can change the used GUI technology without much effort and, most importantly, without touching the application logic at all. | Even though the stack of [[https://sourceforge.net/projects/jvx/|JVx]] is more complicated compared with other GUI or application frameworks, this complexity is set off by the benefits it brings. One can change the used GUI technology without much effort and, most importantly, without touching the application logic at all. | ||
| - | ====== Resource and UIResource ====== | + | ====== Resource and UI Resource ====== |
| - | Let’s talk about Resources and UIResources, and why they sound similar but are not the same. | + | Let’s talk about resources and UI resources and why they sound similar yet are not the same. |
| ===== The Basics ===== | ===== The Basics ===== | ||
| - | We’ve [[#encapsulated_by_a_wrapper_class|encapsulated by a wrapper class]]. A “UIResource”, on the other hand, is an encapsulated concrete implementation of one of the interfaces on the UI layer. | + | We’ve [[#encapsulated_by_a_wrapper_class|encapsulated by a wrapper class]]. A “UI resource”, on the other hand, is an encapsulated concrete implementation of one of the interfaces on the UI layer. |
| - | Let’s do a short overview on how the [[https://sourceforge.net/projects/jvx/|JVx]] architecture looks like in regards to the GUI stack: | + | Let’s do a short overview of how the [[https://sourceforge.net/projects/jvx/|JVx]] architecture looks like in regards to the GUI stack: |
| {{:jvx:reference:resource.png?nolink|The JVx layers revisited. UI wrapper and implementation implement the interface, extension and technology do not.}} | {{:jvx:reference:resource.png?nolink|The JVx layers revisited. UI wrapper and implementation implement the interface, extension and technology do not.}} | ||
| - | The UI wrappers are the main UI classes that are used to create the GUI (f.e. ''%%UIButton%%''). These are wrapping the implementations (f.e. ''%%SwingButton%%''), which themselves are wrapping the extension/technology (f.e. a ''%%JVxButton%%''/''%%JButton%%''). Only the UI and implementation classes are implementing the interface are required for the component (f.e. ''%%IButton%%''). That also means that the implementation is dependent on the extension/technology component, but the UI can use any object which implements the interface. | + | The UI wrappers are the main UI classes that are used to create the GUI (f.e. ''%%UIButton%%''). These are wrapping the implementations (f.e. ''%%SwingButton%%''), which themselves are wrapping the extension/technology (f.e. a ''%%JVxButton%%''/''%%JButton%%''). Only the UI and implementation classes implementing the interface are required for the component (f.e. ''%%IButton%%''). That also means that the implementation is dependent on the extension/technology component, but the UI can use any object which implements the interface. |
| Now, with that knowledge, we can start defining what is what: | Now, with that knowledge, we can start defining what is what: | ||
| Line 206: | Line 206: | ||
| The resource itself, accessed by calling ''%%<uiwrapper>.getResource()%%'', is the extension/technology component. The UI resource can be accessed by calling ''%%<uiwrapper>.getUIResource()%%''. The UI component can be accessed by calling ''%%<uiwrapper>.getUIComponent()%%'' and is usually the UI wrapper class itself. If we use our previous Swing example, the resource would be a ''%%JVxButton%%''/''%%JButton%%'', the UI resource would be the ''%%SwingButton%%'' and the UI component would be the ''%%UIButton%%''. | The resource itself, accessed by calling ''%%<uiwrapper>.getResource()%%'', is the extension/technology component. The UI resource can be accessed by calling ''%%<uiwrapper>.getUIResource()%%''. The UI component can be accessed by calling ''%%<uiwrapper>.getUIComponent()%%'' and is usually the UI wrapper class itself. If we use our previous Swing example, the resource would be a ''%%JVxButton%%''/''%%JButton%%'', the UI resource would be the ''%%SwingButton%%'' and the UI component would be the ''%%UIButton%%''. | ||
| - | As one can see, access to all objects which comprise GUI possible at all times.. We, of course, have the UI component, we can access the implementation component, and we can access the extension/technology component. Theoretically, we could also swap them at runtime, but in [[https://sourceforge.net/projects/jvx/|JVx]], this is limited to the construction of the object to greatly reduce the error potential and complexity of the framework code. | + | As one can see, access to all objects which comprise GUI possible at all times. We, of course, have the UI component, we can access the implementation component, and we can access the extension/technology component. Theoretically, we could also swap them at runtime, but in [[https://sourceforge.net/projects/jvx/|JVx]], this is limited to the construction of the object to greatly reduce the error potential and complexity of the framework code. |
| - | ===== Creating custom components ===== | + | ===== Creating Custom Components ===== |
| - | We will use an example from the [[#part_about_creating_custom_components|part about creating custom components]] which we will come to later. The ''%%BeepComponent%%'' is a simple ''%%UIComponent%%'' extension which contains a label and two buttons inside itself. | + | We will use an example from the [[#part_about_creating_custom_components|part about creating custom components]], which we will come to later. The ''%%BeepComponent%%'' is a simple ''%%UIComponent%%'' extension which contains a label and two buttons inside itself. |
| <code java> | <code java> | ||
| Line 234: | Line 234: | ||
| } | } | ||
| </code> | </code> | ||
| - | We are setting a new UIResource (an ''%%UIPanel%%'') in the constructor (at line #5) which is to be used by the ''%%UIComponent%%''. In this case it is not an Implementation, but another UI component, but that doesn’t matter because the UIResource only must implement the expected interface. At line #15 we start using that custom UIResource. | + | We are setting a new UI resource (a ''%%UIPanel%%'') in the constructor (at line #5) that is to be used by the ''%%UI component%%''. In this case, it is not an implementation, but another UI component. However, that doesn’t matter because the UI resource only must implement the expected interface. At line #15 we start using that custom UI resource. |
| - | Because UIComponent 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 ===== |
| - | Another special case are containers. For example we could create a panel which does display an overlay in certain situations and we will need to use that throughout the whole application. | + | Another special case is containers. For example, we could create a panel that displays an overlay in certain situations, and we will need to use that throughout the whole application. |
| {{:jvx:reference:uiresourcecontainer.png?nolink|UIResourceContainer Example}} | {{:jvx:reference:uiresourcecontainer.png?nolink|UIResourceContainer Example}} | ||
| - | That means we do not want to build it every time anew, so one option would be to use a factory method to “wrap” the content, something like this: | + | That means we do not want to build it every time anew, so one option would be to use a factory method to “wrap” the content. Something like this: |
| <code java> | <code java> | ||
| Line 333: | Line 333: | ||
| } | } | ||
| </code> | </code> | ||
| - | Which is easy enough, but let’s say we’d like to add logic to that wrapper, at that point it becomes more complicated. We can’t use the same technique as for custom component from above, because in that case the “overlaying panel” would simply not be displayed. However, there is a similar mechanism for containers, setting the UIResourceContainer. | + | Which is easy enough, but let’s say we’d like to add logic to that wrapper. At that point, it becomes more complicated. We can’t use the same technique as the custom component from above because, in that case, the “overlaying panel” would simply not be displayed. However, there is a similar mechanism for containers: setting the UI resource container. |
| - | The UIResourceContainer is another special mechanism which works similar to setting the UIResource, but it works exactly the other way round. While setting the UIResource does “hide” components from the Technology which are there in UI layer, setting the UIResourceContainer does hide components from the UI layer while there are added in the Technology. A little bit complicated, here is our example again using this technique: | + | The UI resource container is another special mechanism that works similar to setting the UI resource, but it works exactly the other way round. While setting the UI resource “hides” components from the technology in UI layer, setting the UI resource container hides components from the UI layer, while they are added in the technology. A little complicated, here is our example using this technique again: |
| <code java> | <code java> | ||
| Line 363: | Line 363: | ||
| } | } | ||
| </code> | </code> | ||
| - | What we’ve done is extend an UIPanel (line #1), setting it up and adding children and then we’ve declared one of its children as the UIResourceContainer (line #22). So all methods which are specific to IContainer (adding children, setting a layout, etc.) are now forwarding to the innerPanel and manipulating the contents of the OverlayedPanel directly is not directly available. | + | What we’ve done is extend a UI panel (line #1), setting it up and adding children, and then we’ve declared one of its children as the UI resource container (line #22). So all methods that are specific to UI container (adding children, setting a layout, etc.) are now forwarding to the inner panel and manipulating the contents of the overlaid panel directly. |
| And here is how it is used: | And here is how it is used: | ||
| Line 387: | Line 387: | ||
| parentContainer.add(panel, UIBorderLayout.CENTER); | parentContainer.add(panel, UIBorderLayout.CENTER); | ||
| </code> | </code> | ||
| - | Notice that we can use it is any other panel (line #5) and simply add it to the parent (line #18). For a user of the API it is transparent as to whether there are more components or not, this is also visible in the created component hierarchy: | + | Notice that we can use it as any other panel (line #5) and simply add it to the parent (line #18). For a user of the API, it is transparent as to whether there are more components or not. This is also visible in the created component hierarchy: |
| <code> | <code> | ||