jsgui3-server 0.0.120 → 0.0.121

package/examples/controls/11b) window, shared Data_Object model mirrored text fields/client.js

@@ -36,41 +36,12 @@ class Demo_UI extends Active_HTML_Document {
         spec.__type_name = spec.__type_name || 'demo_ui';
         super(spec);
         const {context} = this;
-
-
-        // Create the Data_Model here....
-
-        // Maybe on pre-activate set its values if it's already been set?
-
-        // Or better send over info about the Data_Model that gets brought into the Page_Context???
-
-        // data.model transfer needs to be automatic.
-        //   Possibly it would be a client-side resource?
-
-        // Want to make the syntax when composing / defining things as simple as possible.
-
-        // Simple enough for the moment.
-        //   Could see about auto-registering?
-        //     Maybe later on.
-        // Simple and explicit code will be best for the moment.
-        //   Must be concise, then could consider more concise and less explicit (but unambiguous) ways to declare things
-        //     to do with data and view model interactions.
-
-
-        // And using a Control_Data class here could help.
-        // Then a Control_View class.
-        //   And the Control_View has its own internal Data. Maybe even a Control_View_Data ???
-
         
-
-        // Needs a little bit more work...
-
-        //  Maybe adding the fields to the Data_Object is needed.
-
+        /*
 
         const setup_demo_ui_data_model = () => {
             this.data = {
-                model: new Data_Object({
+                model: new Data_Value({
                     context
                 })
             }
@@ -79,104 +50,11 @@ class Demo_UI extends Active_HTML_Document {
         }
         setup_demo_ui_data_model();
 
+        */
 
+        this.data.model.data_type = String;
         
 
-
-
-
-        // The app as a whole having a view.data.model ????
-
-
-        // Or want defined properties / proxies on the Data_Model?
-        //  or fields?
-
-        // want to listen for changes to the data_model.
-
-        // May need comprehensive changes to a lot of controls.
-        //   Making this system the standard / default.
-        //     Getting it working with easy idioms on the top level - don't update the data model on every keystroke.
-
-        // when setting the bounds of a rect, need to set multiple numbers at once (up to 4).
-
-        // A ctrl.view.data.model
-        //  Looks like it's worth making and making use of Control_View and Control_Data classes.
-        //    Would have / support .model.
-
-        // The view.data.model would model exactly what data is in the view.
-        //   It would only get synced to the data.model at appropriate times (like user moving on, or confirming 'ok' or 'go')
-
-        // 'cancel' and 'go' would be of use in some cases.
-        //   red (or grey) and then a green (or slightly green) button.
-        //    a slightly red grey and then a bolder and more colorful green. Would be more color blindness accessible.
-
-
-
-
-
-
-
-
-
-
-
-
-
-        // this.data.model.set('k', 'v')???
-
-        // create_shared_data_model function...
-        //   would happen on activate as well as compose.
-
-        // Or just make sure there is the 'value' field there...?
-
-
-
-
-        
-
-
-        // And have it persisted to the HTML by the server that they both use that same data.model???
-        //   A bit more lower level code to support more properties / objects being reconstructed client-side would help.
-
-
-
-
-
-
-        // Then when there is a change to that data_model...?
-
-
-
-
-        // Context would have a built-in data_model?
-        //   Maybe for HTML apps. Not all Data_Object contexts.
-
-        // Server_Page_Context also having and using a Data_Model....
-        //   Would make sense.
-        //   Same with the Client_Page_Context
-
-
-
-
-        // Make sure it requires the correct CSS.
-        //  Though making that 'effortless' on the server may help more.
-
-
-        // Maybe can't do this here???
-
-        // Does not have .body (yet) on the client.
-        //   simple way to get the client to attach the body of the Active_HTML_Document?
-        //     maybe with jsgui-data-controls?
-        //   Though automatically having the .body property available on the client without sending extra HTTP
-        //     plumbing will help.
-
-        // .body will not be available before activation.
-
-
-        // .body should not be a normal function....?
-        //   a getter function would be better.
-
-
         if (typeof this.body.add_class === 'function') {
             this.body.add_class('demo-ui');
         }
@@ -186,39 +64,19 @@ class Demo_UI extends Active_HTML_Document {
 
 
         const compose = () => {
-            // put 20 of them in place.
-
-            // Then how to arrange them...?
-
-
-            // Setting up the shared model in composition would be best....
-            //   Or maybe during init, pre-activate?
-
-            // This seems like it will need some lower level integration for ease of use.
-            //   Would like this to work server-side when setting properties, so should not rely on having this
-            //     in the 'activate' code.
-
-            // a 'model' property.
-            //  maybe two model properties: view.model, data.model.
-
-            // There could be a 'confirm / cancel' dialog when the view.model has been changed, and the view model can be updated
-
-            // Also, a single model could enable an undo history.
-
-            // app.data.model?
-            // context.data.model?
 
-            // context.view.model could make sense too, for representing the state of the app view (ie windows maximised, minimised, positions)
-            //   Could help when resuming the app at a later point, or transmitting the view of the app.
-            //   Maybe for collaborative editing, could operate like shared screen, or each user has control over their own windows.
+            // Not so sure how to persist the (shared) data_models upon composition.
+            //   Maybe explicitly reassigning them on activation for the moment.
+            //   Could actually be necessary right now, but should look into supporting it automatically on
+            //     a lower level.
 
+            // Defining shared data models in the composition...
+            //   Should be able to persist that info to the data-jsgui properties in the HTML.
+            //   Also may be best to have some very explicit code that generates the app's Data_Model, or the page's Data_Model.
 
+            // Does seem like persisting the relationships between controls, the inner parts of them, and data_models is important.
 
-            // context.model?
-
-            // ctrl.view.model perhaps???
-            // ctrl.data.model = context.model perhaps?
-
+            
 
 
 
@@ -229,58 +87,13 @@ class Demo_UI extends Active_HTML_Document {
                 title: 'jsgui3-html Shared data.model Mirrored Text_Input controls',
                 pos: [5, 5]
             });
-
             window.size = [480, 160];
-
-            // Label text better propbably?
-
-            // .value
-
-            // .data.model = context.data.model
-
-
-            // set that 'value' to a data model ??? No.
-            //  set it's 'model' or 'data.model'.
-
-            // data.model for the moment will be best.
-            //   That is what we want to bind.
-            //   View model and data model pair could allow for 'cancel | OK' options to confirm changes.
-
-
-            // 'data_model' property.
-            // 'dmodel', 'dm' too...?
-            //  'vm' possibly?
-
-            // .v.m shorthand??
-            // .d.m too?
-
-
-
-            // or data: {model: obj_data_model}
-
-            // The data model persistance must not be tricky here.
-            //   Maybe setting it up at compose is not best???
-            //    Makes for the nicest syntax here, the 'magic' about jsgui is handing things over to the client
-            //    in a working way, auto-reconstructing things client-side.
-            //   Would need to send over info on which Data_Model would be used...
-
-
-            // The shared data model should mean that these fields automatically stay in sync (somewhat)
-            //   A shared view model would mean a more immediate sync.
-
-
-            // So Text_Field would need to look at data, data.model from the spec.
-
-            // Write the code in a few controls first, see what is in common and can be abstracted into a mixin
-            //  such as control-data-model-sync
-
-
-            // Would change the 'value' property by default.
-
-            const ti1 = new Text_Field({
+            
+            const tf1 = new Text_Field({
                 context,
+                text: 'A', // label.text???
+                // name???
 
-                text: 'A',
                 data: {
                     model: this.data.model
 
@@ -292,240 +105,145 @@ class Demo_UI extends Active_HTML_Document {
                 //label: {
                 //    text: 'A checkbox'
                 //}
-            })
-
-            window.inner.add(ti1);
-
-            // Though not sure they get reconstructed with that data model?
-
-            // Want to make this easy for the app programmer to get right in particular.
-
-            // May need (much) more work on persisting the data model to the client.
-            //   Or defining it in a way / place so it can be started isomorphically.
-            //     Though it may make sense to do more to transfer models from the server to the client, with their data.
-            //       However, reconstructing models from the (values in) the DOM could make a lot of sense.
-            //       Having it read the DOM to create its DOM model, then from that its view.data model, then its data model.
-
-
-            
-
-
-
-
-
-            const ti2 = new Text_Field({
+            });
+            window.inner.add(tf1);
+            const tf2 = new Text_Field({
                 context,
 
                 text: 'B',
                 data: {
                     model: this.data.model
                 }
-
-
                 //label: {
                 //    text: 'A checkbox'
                 //}
             })
 
-            window.inner.add(ti2);
+            window.inner.add(tf2);
 
             this.body.add(window);
 
-
-
-            // ._ctrl_fields should automatically be set up.
-            //   Also make it so when there are 0 entries in there it won't render the DOM attribute.
-
-            // First get the MVC properly and explicitly working accross some more controls.
-            //   If any abstractions come really easily then do that.
-            //     Maybe a DMVM_Control could be very effective soon.
-
-            // An 'adjuster' control could possibly have no 'data model' of its own.
-            // It could be set up to adjust either a data model, or a view model.
-
-            
-
             
             this._ctrl_fields = this._ctrl_fields || {};
-            this._ctrl_fields.ti1 = ti1;
-            this._ctrl_fields.ti2 = ti2;
+            this._ctrl_fields.tf1 = tf1;
+            this._ctrl_fields.tf2 = tf2;
 
 
         }
-        if (!spec.el) {
-            compose();
-        }
-    }
-    activate() {
-        if (!this.__active) {
-            super.activate();
-            const {context, ti1, ti2} = this;
-
-            console.log('activate Demo_UI');
 
-            //field(this.data.model, 'value');
-            // and events dealing with changes to those tis.
 
-            // ti1, ti2.
+        // Only after activate???
+        //   On a higher level will not need to pay as much attention to activation.
 
-            // Some kind of tracking of what the event initiator could help?
-            //   Automatically avoiding feedback somehow???
-            //     If it gets changed to its current value it does not push the change...?
 
 
-            // a non-dom change???
-            //   or basically .view.model.change even????
 
-            // ti1.view.model.on('change') could be much clearer, disambiguating it from a dom change event.
-            //  assign .view.model events ....?
-            //    doing this on a lower level would help.
+        // Both after compose and activate, need to set up the
 
-            // Just creating .view and .view.model objects (getters and setters specified) in jsgui3-html will help
-            // when referring to them.
-
-            // Maybe see about better reconstruction....
+        if (!spec.el) {
+            compose();
+        }
 
-            //console.log('ti1.data.model', ti1.data.model);
-            //console.log('ti2.data.model', ti2.data.model);
 
-            
+    }
 
-            const activate_demo_ui_data_model = () => {
-                console.log('ti1.data.model === ti2.data.model', ti1.data.model === ti2.data.model);
+    setup_inner_listeners() {
+        // Post compose or during activate.
+        const {tf1, tf2} = this;
+        
+        tf1.data.model.on('change', e => {
+            console.log('tf1 data model e', e);
+            const {name, old, value} = e;
+            if (name === 'value') {
+                
+            }
+        })
+        
+        tf2.data.model.on('change', e => {
+            console.log('tf2 data model e', e);
+            const {name, old, value} = e;
+            if (name === 'value') {
+                
+            }
+        })
+    }
 
-                if (ti1.data.model === ti2.data.model) {
+    // A lower level way of reconstructing models on the client would help.
+    //   Eg when a control gets composed, it could be specified that an internal control's
+    //    view model is the same as, or is synced with this control's view model.
 
-                } else {
+    // Do want to handle both syncing as well as using the same JS objects where appropriate.
+    //   Same objects will be best when one thing really is the other.
 
-                    // Should not need this code.
-                    //   Want decent low/mid level code to send the info to the client so the client can automatically reconstruct it.
-                    ///    Maybe a different function as standard to assign isomorphic things.
+    // Eg a Text_Field would have it's view data model value represented using a Text_Input.
 
+    // Late consider where in the namespacing things like
+    //  label text, label text font, label icon image url etc can go.
+    //    It's not the 'core' data model.
 
-                    // What about (just) using a Data_Value???
-                    // Data_Value_Model?
-                    // Data_Model_Value???
+    // Maybe presentation model???
+    //  .ui model does seem convenient and explicit.
+    //  ctrl.view.ui.label.text.font for example.
+    //  ctrl.view.ui.label.text.font.size, ctrl.view.ui.label.text.size could be synonyms.
+    //    Make the mid-level objects work so they provide a nice and flexible top level API.
 
-                    // Just stick to Data_Value for now.
 
 
+    // So within Text_Field, would use _ctrl_fields
+    //   could also assign / reassign the data models upon activation???
 
-                    const dm = new Data_Object({context});
-                    field(dm, 'value');
-                    ti1.data.model = dm;
-                    ti2.data.model = dm;
+    // Concise code at the high level would be OK for the moment, but really want this on mid level.
 
-                    // But then need to get them to reassign their data model change listeners....?
-                    //   value change even....
+    // Or could rely on syncing for the moment....?
 
-                    ti1.assign_data_model_value_change_handler();
-                    ti2.assign_data_model_value_change_handler();
 
 
-                }
-            }
 
-            activate_demo_ui_data_model();
 
-            
 
-            // Create a new data_model (and view_model?) for both of them?
-            //   The view_model gets created by default and does not need to be shared (and should not be)
 
 
 
 
 
-            // ti1.value.on('change') ????
-            //   where the value is an Evented_Class or even Data_Object????
-            //    and where we can also get the value out of it easily / do so automatically, maybe within other useful functions.
 
 
-            // ti1.model.on('change') ????
-            //  or .view.model to be most specific for the moment...?
-            //   and raise those events within the controls on those .view.model objects.
 
-            // Maybe just try it on Text_Field for the moment.
 
 
 
-            // Need to work on having it update the dom with value changes....
+    activate() {
+        if (!this.__active) {
+            super.activate();
 
-            const old_activate_changes = () => {
 
-                ti1.model.on('change', e => {
-                    //console.log('ti1 change e', e);
 
+            const {context, tf1, tf2} = this;
 
-                    if (e.property_name === 'value') {
-                        if (e.value !== e.old) {
-                            ti2.value = e.value;
-                        }
-                    }
+            console.log('activate Demo_UI');
 
-                    // setting ti2.view.model.value even????
-                    
+            // Want data model syncing and activation done for free.
 
-                    
+            const already_same_data_models_on_activation = this.data.model === tf1.data.model === tf2.data.model;
+            console.log('already_same_data_models_on_activation', already_same_data_models_on_activation);
 
-                })
-                ti2.model.on('change', e => {
-                    //console.log('ti2 change e', e);
+            if (!already_same_data_models_on_activation) {
+                console.log('Need to reassign the data_models of the two controls [tf1, tf2].');
 
-                    // 
+                // Probably need to have the specific code in Text_Field to handle data.model changing.
 
-                    if (e.value !== e.old) {
-                        ti1.value = e.value;
-                    }
+                tf1.data.model = this.data.model;
+                tf2.data.model = this.data.model;
 
-                    
-                })
+            } else {
+                console.log('jsgui3 now supports client-side reconstruction of shared object models on a lower level.')
             }
 
+            this.setup_inner_listeners();
             
 
-            // listen for change events.
-            //   would be nice to know which change events originated from the user interacting with that specific HTML element (or ctrl???)
-
-            // e.from_user === true test.
-
-            // e.user_initiated_on_this ????
-
-
-
-
-            //console.log('activate Demo_UI');
-            // listen for the context events regarding frames, changes, resizing.
-
             context.on('window-resize', e_resize => {
                 
-                // Could see about having some window contents bound through CSS to the size of the window.
-                //   Though having a framework of adjusting CSS from the JS on-the-fly could work too.
-
-                // May be done with the 'bind' mixin, or will make more specific mixins to do things like bind
-                //   a control to the space within another control, space within a specific part of that control.
-
-                // Or bind to parent size. That should be possible with CSS though.
-                //   May make some controls make more use of CSS by default
-                //   Or having an absolutely positioned box model used extensively could avoid some ambiguity, though
-                //     making use of and supporting generally respected CSS features will help too.
-
-                //console.log('window-resize', e_resize);
-
-                // Make all internal controls go absolute in terms of position
-                //   Remove them from their containers too?
-                //   Ie their containing divs?
-
-                // Would be nice to do this really simple with a fn call or very simple piece of code.
-                // Like get absolute position, set position to be absolute, move to that position.
-                // Maybe something within jsgui3-client helps with this, this is more about what needs to be done on the client.
-                //   Though recognising perf implications, it's (more) OK to include client-side functionality in jsgui3-html.
-
-
-
-
-
-
             });
 
         }

package/examples/controls/11c) window, shared Data_Value model mirrored text fields/client.js

@@ -422,8 +422,8 @@ class Demo_UI extends Active_HTML_Document {
                     // But then need to get them to reassign their data model change listeners....?
                     //   value change even....
 
-                    ti1.assign_data_model_value_change_handler();
-                    ti2.assign_data_model_value_change_handler();
+                    //ti1.assign_data_model_value_change_handler();
+                    //ti2.assign_data_model_value_change_handler();
 
 
                 }

package/examples/controls/11d) window, shared model mirrored integer text fields/both.js

@@ -0,0 +1,17 @@
+const jsgui = require('lang-tools');
+const {Data_Value, Functional_Data_Type} = jsgui;
+const create_demo_ui_data_model = (context) => {
+    const res = new Data_Value({
+        context,
+        data_type: Functional_Data_Type.integer
+    });
+    if (context) {
+        context.register_control(res);
+    }
+
+    return res;
+    
+}
+module.exports = {
+    create_demo_ui_data_model
+}