Differences

This shows you the differences between two versions of the page.

--- jvx:reference [2020/06/10 11:14]
cduncan [Of Technologies and Factories]
+++ jvx:reference [2020/06/10 12:11]
cduncan [Why is the UI layer necessary?]
@@ Line 12: / Line 12: @@
 Let’s talk about the UI layer, the implementations, and the factory that powers it all.
-===== The basics =====
+===== The Basics =====
-For everyone who does not know, [[https://sourceforge.net/projects/jvx/|JVx]] allows you to write code once and run it on different GUI frameworks, without changing your code. This is achieved by hiding the concrete GUI implementations behind our own classes, the UI classes, and providing “bindings” for different GUI frameworks behind the scenes. Such a “[[https://en.wikipedia.org/wiki/Single-source_publishing|single sourcing]]” approach has many advantages, and just one of them is that migrating to a new GUI framework requires only the change of a single line, the one which controls which factory is used.
+For everyone who does not know, [[https://sourceforge.net/projects/jvx/|JVx]] allows you to write code once and run it on different GUI frameworks without changing your code. This is achieved by hiding the concrete GUI implementations behind our own classes, the UI classes, and providing “bindings” for different GUI frameworks behind the scenes. Such a “[[https://en.wikipedia.org/wiki/Single-source_publishing|single sourcing]]” approach has many advantages, one of which is that migrating to a new GUI framework requires only the change of a single line, the one which controls which factory is used.
-===== The patterns =====
+===== The Patterns =====
-[[https://en.wikipedia.org/wiki/Factory_%28object-oriented_programming%29|The factory pattern]] is an important pattern in [[https://en.wikipedia.org/wiki/Object-oriented_programming|Object-oriented programming]], it empowers us to delegate the creation of objects to another object which must not be known at design and/or compile time. That allows us to use objects which have not been created by us but merely “provided” to us by an, for us unknown, source.
+[[https://en.wikipedia.org/wiki/Factory_%28object-oriented_programming%29|The factory pattern]] is an important pattern in [[https://en.wikipedia.org/wiki/Object-oriented_programming|Object-oriented programming]] It empowers us to delegate the creation of objects to another object that is not known at design and/or compile time. That allows us to use objects which have not been created by us but merely “provided” to us by an unknown-to-us source.
-[[https://en.wikipedia.org/wiki/Bridge_pattern|The bridge pattern]] on the other hand describes a technique which wraps implementations in another implementation and forwards all/most functionality to that wrapped implementation. This allows us to mix and match functionality without the need to have it in all implementations at once.
+[[https://en.wikipedia.org/wiki/Bridge_pattern|The bridge pattern]], on the other hand, describes a technique which wraps implementations in another implementation and forwards all or most functionality to that wrapped implementation. This allows us to mix and match functionality without the need to have it in all implementations at once.
-===== Like an onion =====
+===== Like an Onion =====
-[[https://sourceforge.net/projects/jvx/|JVx]] is separated into different layers, with the UI layer being at the top and of the most concern to users.
+[[https://sourceforge.net/projects/jvx/|JVx]] is separated into different layers with the UI layer being at the top and of the most concern to users.
 {{:jvx:reference:layers.png?nolink|The four layers of VisionX: UI, Implementation, Extension and Technology.}}
@@ Line 30: / Line 30: @@
 ==== Technology ====
-Obviously, the first one in the chain is the so called “technology” layer. It represents the UI technology, for example Swing, JavaFX or Vaadin, which is used to power the [[https://sourceforge.net/projects/jvx/|JVx]] application.
+Obviously, the first one in the chain is the so-called “technology” layer. It represents the UI technology -- for example Swing, JavaFX or Vaadin -- that is used to power the [[https://sourceforge.net/projects/jvx/|JVx]] application.
-To put it into a more simple term:
+To put it more simply:
 <code java>
@@ Line 39: / Line 39: @@
 ==== 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 which 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.
 <code java>
@@ Line 48: / Line 48: @@
 ==== Implementation ====
-After that comes the implementation layer. These implementations of the [[https://sourceforge.net/projects/jvx/|JVx]] interfaces are the actual objects returned by the factory. This is some sort of “glue” layer, it binds the technology or extended components against the interfaces which are provided by [[https://sourceforge.net/projects/jvx/|JVx]].
+After that comes the implementation layer. These implementations of the [[https://sourceforge.net/projects/jvx/|JVx]] interfaces are the actual objects returned by the factory. This is some sort of “glue” layer: it binds the technology or extended components against the interfaces which are provided by [[https://sourceforge.net/projects/jvx/|JVx]].
 <code java>
@@ Line 55: / Line 55: @@
 ==== UI ====
-Last but for sure not least is the UI layer, which wraps the implementations. It is completely Implementation independent, that means that one can swap out the stack underneath:
+Last, but definitely not least, is the UI layer, which wraps the implementations. It is completely implementation-independent, which means that one can swap out the stack underneath:
 {{:jvx:reference:swappable-layers.png?nolink|The Extension, Implementation and Technology can be swapped at will}}
-This is achieved because the UI layer is not extending the Implementation layer, but wrapping instances provided by the factory. It is oblivious to what Technology is actually underneath it.
+This is achieved because the UI layer is not extending the implementation layer but wrapping instances provided by the factory. It is oblivious to what technology is actually underneath it.
 <code java>
@@ Line 68: / Line 68: @@
 ===== Why is the UI layer necessary? =====
-It isn’t, not at all. The Implementations could be used directly without any problems, but having yet another layer has two key benefits:
+It isn’t, not at all. The implementations could be used directly without any problems, but having yet another layer has two key benefits:
   * It allows easier usage.
-  * It allows to add Technology independent features.
+  * It allows to add technology-independent features.
-By wrapping it one more time we gain a lot of freedom which we would not have otherwise, when it comes to features as when it comes to coding. The user does not need to call the factory directly and instead just needs to create a new object:
+By wrapping it one more time, we gain a lot of freedom which we would not have otherwise when it comes to features and coding. The user does not need to call the factory directly and, instead, just needs to create a new object:
 <code java>
 IButton button = new UIButton();
 </code>
-Internally, of course, the Factory is called and an implementation instance is created, but that is an implementation detail. If we would use the implementation layer directly, our code would either need to know about the implementations, which doesn’t follow the single-sourcing principle:
+Internally, of course, the factory is called and an implementation instance is created, but that is an implementation detail. If we would use the implementation layer directly, our code would need to know about the implementations, which doesn’t follow the single-sourcing principle:
 <code java>
@@ Line 88: / Line 88: @@
 IButton button = UIFactoryManager.getFactory().createButton();
 </code>
-Both can be avoided by using another layer which does the factory calls for us:
+Both can be avoided by using another layer that the factory calls for us:
 <code java>
@@ Line 106: / Line 106: @@
 }
 </code>
-Additionally this layer allows us to implement features which can be technology independent, our naming scheme, which we created during stress testing of an Vaadin application, is a very good example of that. The names of the components are derived in the UI layer without any knowledge of the underlying Technology or Implementation.
+Additionally, this layer allows us to implement features that can be technology-independent. Our naming scheme, which we created during stress testing of a Vaadin application, is a very good example of that. The names of the components are derived in the UI layer without any knowledge of the underlying technology or implementation.
-Also it does provide us (and everyone else of course) with a layer which allows to rapidly and easily build [[#compound_components|compound components]] out of already existing ones, like this:
+Also, it provides us (and everyone else, of course) with a layer which allows to rapidly and easily build [[#compound_components|compound components]] out of already existing ones, like this:
 <code java>
@@ Line 134: / Line 134: @@
 }
 </code>
-Of course that is not even close to sophisticated, or a good example for that matter. But it shows that one can build new components out of already existing ones without having to deal with the Technology or Implementation at all, creating truly cross-technology controls.
+Of course, that is not even close to sophisticated, or even a good example for that matter. However, it shows that one can build new components out of already existing ones without having to deal with the technology or implementation at all, creating truly cross-technology controls.
 ===== The Factory =====