Changes between Version 37 and Version 38 of PRO_LIB_CORE_TUTORIAL_NEW

Timestamp:

07/02/09 20:25:01 (16 years ago)

Author:

gogov

Comment:

--

PRO_LIB_CORE_TUTORIAL_NEW

@@ -161 +161 @@
    Such Properties are intended to be used in cases where some user action leads to set the value of a given Property exactly once. This is different than ''const'' AutoProperties as described below.
   * '''AutoProperty<T>''':[[BR]]
-   This Property is one of the most commonly used and convenient Properties the ProLib offers.
-
-   Basically this is a Property which has a value which is computed directly from the values of some other Properties. In a way, the developer sets the logic of the computation of the AutoProperty's value in a declarative manner and the actual computation of the value is done automatically. Even more, the when some of the Properties on which the AutoProperty depends change their value, the AutoProperty automatically recomputes its value which is very convenient. This saves the developer the hassle of manually implementing some Observer like functionality in all objects a certain Java field X would logically depend and then manually notifying X when they've changed so X can then be manually forced to recompute.
-
-   So, like inside the Rectangle example, the area() AutoProperty is implemented like this:
-    {{{
+  This Property is one of the most commonly used and convenient Properties the ProLib offers.[[BR]]
+  Basically this is a Property which has a value which is computed directly from the values of some other Properties. In a way, the developer sets the logic of the computation of the AutoProperty's value in a declarative manner and the actual computation of the value is done automatically. Even more, the when some of the Properties on which the AutoProperty depends change their value, the AutoProperty automatically recomputes its value which is very convenient. This saves the developer the hassle of manually implementing some Observer like functionality in all objects a certain Java field X would logically depend and then manually notifying X when they've changed so X can then be manually forced to recompute.[[BR]]
+  So, like inside the Rectangle example, the area() AutoProperty is implemented like this:
+{{{
     Prop<Integer> area() {
         class area extends AutoProperty<Integer> {
@@ -179 +177 @@
         return getBean().makeProp(area.class);
     }
-    }}}
+}}}
     In order to create an AutoProperty, by convention you declare a method structure like the structure of the area() method which declares a local class which extends the AutoProperty class. The type argument of the local class should be identical to the type argument of the Prop which the area() method returns - after all an AutoProperty is a Property which computes a given value following some logic and that value has a type which in our case is Integer.[[BR]]
     So you override the compute() method to provide the AutoProperty's value computation logic inside. You can provide an arbitrary complex logic inside. In this example whenever the width() and height() Properties change their value, the AutoProperty is smart enough to call the compute() method again and update its value.[[BR]]