Differences

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

--- jvx:reference [2020/06/10 11:23]
cduncan [UI]
+++ jvx:reference [2020/06/10 12:11]
cduncan [Why is the UI layer necessary?]
@@ 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 =====