Changes between Version 13 and Version 14 of PRO_LIB_CORE_TUTORIAL_NEW

Timestamp:

06/30/09 21:28:09 (16 years ago)

Author:

gogov

Comment:

--

PRO_LIB_CORE_TUTORIAL_NEW

@@ -181 +181 @@
     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]]
     '''Something very important:''' compute() will be recomputed only in the cases when some of the '''Properties''' used inside it change their value!! If compute() depends on some normal Java field, there's no way for the ProLib to know when this field has changed its value and then notify the AutoProperty to change its value!! '''There's no magic here!!''' Expecting the ProLib to detect that means hooking to JVM's system events and maybe bytecode instrumentation which obviously we don't want to use (:
-    
+   * Actually, AutoProperties have a '''doSet()''' method, which can be overriden to provide setting manually a value of a given AutoProperty. This can be used in ''very rare cases'' when you have an AutoProperty X which depends on other Properties but also there's an AutoProperty Y which depends on X. So let's say that we need Y to have a valid value but at this stage of execution of our program we don't have all the Properties which X depends on initialized. That's when we can manually set the value of X, so Y gets property computed, and later, when all the Properties X depends on initialize, then X gets recomputed and Y respectively.[[BR]]
+    This should be used very rarely, so if you think you need this, consult first with someone else (:
+   * There's a special case of AutoProperties which are '''const''' AutoProperties. Such AutoProperties depend on some other Properties, but their value should be computed only once.
+    For instance you can have this case:
+{{{
+    public Prop<Integer> X() { ... }
+    public Prop<Char> Y() { ... }
+    public Prop<String> Z() { ... }
+
+    @Const
+    @Override
+    public Prop<JLabel> swingComponent() {
+        class swingComponent extends AutoProperty<JLabel> {
+            @Override
+            protected JLabel compute() {
+                assert getLastValue() == null;
+
+                JLabel res = new JLabel();
+                res.setBackground(Color.green);
+                res.setText("text is " + X().get() + ", " + Y().get() + ", " + Z().get());
+        
+                return res;
+            }
+        }
+
+    return getBean().makeProp(swingComponent.class);
+}
+}}}
+    In this case the AutoProperty swingComponent() depends on X(), Y(), Z(), provide some relatively complex initializing logic in the compute() method and you want to make sure this component is created only once. Thus:
+    * You'll be happy if you don't want to worry about when X(), Y() and Z() get initialized and this way the ProLib can do it for you,
+    * You can capsulate the initialization logic in the compute() method so your ProObject constructor doesn't get bloated with it instead,
+    * By convention you insert ''assert getLastValue() == null;'' assertion which makes sure that the Property is still not initialized by the time the compute() method is called (which means that it's value is still null).
+    * Also by convention, you annotate such AutoProperties with '''@Const'''.
 
  * Multiple Properties (RED):