jsgui3-server 0.0.119 → 0.0.121

package/examples/controls/16a) Window([Text_Input]) Integer data.model.data_type/client.js

@@ -0,0 +1,494 @@
+const jsgui = require('jsgui3-client');
+const {controls, Control, mixins, Data_Value, Functional_Data_Type} = jsgui;
+const {dragable} = mixins;
+
+// Need to focus more on client-side recoherence of the various pieces of data.
+//   Would be nice to have the Data_Model, even if it does not contain the data itself, available at the very start.
+
+// Maybe later will include Data_Model within the Resource system.
+//   Fetching / making queries to the server to get the data would work through that system.
+
+// For the moment, need to get some of the most basic things to do with transferring data and how its modelled to the client.
+//   An isomorphic data model would make sense in many cases.
+//   Let's get these various examples well covered in terms of mid-level code that enables it all to work well.
+//     Need to move away from including larger pieces of code in the controls and apps that use them if that code
+//       can be put mid level correctly as an abstraction available to use throughout.
+
+// Client-side data coherence.
+// Data loading from variety of sources.
+// Data access checking
+// Data validity checking and status.
+//   Validity status change events could help.
+
+// Being explicit about how some data could be valid according to one criteria but not according to another.
+// Validate a according to b.
+// Validate b according to b so that it can't be set to invalid states.
+
+// data.model.allows.invalid.states = true???
+
+// Continue aiming for most expressive high-level syntax.
+
+
+const {Window, Checkbox, Date_Picker, Text_Input, Text_Field, Validation_Status_Indicator} = controls;
+
+const Active_HTML_Document = require('../../../controls/Active_HTML_Document');
+
+// Would be nice to have a validation status indicator too.
+
+// Maybe a Data_Model_History_View as well somewhere?
+
+const {create_app_data_model} = require('./isomorphic');
+
+// Maybe want simpler tests of data models and bringing them to the client.
+
+// Eg a data model being a list of numbers etc, validating them on the server, sending them to the client, validating them there.
+//   Focusing first on the app data model, then later on how it gets presented / represened.
+
+// 
+
+// Though having a control to view the validation status here too could help.
+
+// Reconstruction / recoherence of the Data_Model on the client-side and its relationship to the controls could be of great use.
+//   Want to do things by reference where appropriate.
+//     Though putting everything inside a single app data model could make sense too.
+
+// Validation of one data model according to the rules of another.
+//   Eg validation of a view data model according to app data model.
+
+// May need to be clearer about validation being the interaction between two data models.
+//   As in validate one data model according to the rules of another.
+
+// The app.data.model in many cases would not get into an invalid state.
+// The view.data.model representing a state that's invalid within the app.data.model would have a valid state sometimes
+//   from the perspective of the view.data.model itself. However it would be invalid according to another data.model.
+
+// So have something that shows the validation status according to another data_model.
+
+// no context(yet?) for this data model.
+
+
+// Does seem like creating and perfecting a few lower level complexities would help this to work.
+//   Validation states in particular.
+//   Eg a view data model could be validated according to a non-view data model.
+
+// validation.reference = other data_value.
+
+// so work on test cases for data_value.validation.
+// maybe more limited Data_Value type classes, such as Data_Integer would help here.
+//   Could make them specific and concise and that would help to define the API.
+
+
+
+
+
+// Data model validation state change events will be a convenient api.
+
+
+// .data.model.validation.state.on('change', e => {...})
+//   Somewhat complex to implement, somewhat long to write, but very clear indeed.
+
+// Getting a validation state object / observable could help. Not observable because it does not end like a promise???
+
+const app_data_model = create_app_data_model();
+
+
+
+class Demo_UI extends Active_HTML_Document {
+    constructor(spec = {}) {
+        spec.__type_name = spec.__type_name || 'demo_ui';
+        super(spec);
+        const {context} = this;
+
+        // But have a way to persist the data model to the client, easily.
+        
+
+        if (typeof this.body.add_class === 'function') {
+            this.body.add_class('demo-ui');
+        }
+
+
+        // Inner controls getting their data models set up should probably be separate to composition.
+        //   However, will be nice if code in compose could specify it all?
+        //   Probably want a setup_controls_data_model?
+
+        // Or a post_compose or post-reconstruct phase.
+
+        // Maybe a data_model_compose stage, where it's separate to normal compose, but happens post reconstruct on the client
+        //   probably at some pre-activate stage.
+
+
+        // A 'define' stage rather than 'compose'???
+        //   Where it would include data model definition things plus composition,
+        //     but client-side on activation it would get reconstructed.
+
+
+
+
+        // .ensure_compositional_data_models???
+
+        // .compose_data_models could work.
+
+
+        this.data.model = app_data_model;
+        this.data.model.context = context;
+
+        // Defining validation states?
+        //   Indicators for them???
+
+
+        context.register_data_model(this.data.model);
+
+        const setup_logging_listeners = () => {
+
+
+            app_data_model.on('change', e => {
+                console.log('app data model change e:', e);
+                const {value} = e;
+                console.log('new app model value:', value);
+    
+                // That value would be valid....
+    
+            });
+    
+            // Validate should include the value validated.
+            app_data_model.on('validate', e => {
+                console.log('app data model validate e:', e);
+                const {value} = e;
+                console.log('validate value:', value);
+    
+                // And something that shows the valiation status as well....
+    
+                // Probably only need a few small breakthroughs to get this working nicely and intuitively.
+                //   Easy to use on a high level.
+    
+            });
+
+
+
+
+        }
+
+        
+
+        const compose = () => {
+
+            const window = new Window({
+                context: context,
+                title: 'jsgui3-html Text_Input control',
+                pos: [5, 5]
+            });
+
+            window.size = [480, 160];
+
+            // No view data model specified? So a string by default.
+
+
+            const including_data_model_properties_in_spec = () => {
+
+                const ti = new Text_Input({
+                    context,
+                    data: {
+                        model: app_data_model
+                        // And would not currently need to translate between strings and ints.
+                    },
+                    //view: {data: {model: new_int_dv(context)}},
+                    //text: 'A',
+                    //value: 5
+                    //label: {
+                    //    text: 'A checkbox'
+                    //}
+                })
+                window.inner.add(ti);
+
+                // VSI showing if the text input is valid, according to the data_model.
+                
+                // Seems like a validation.state.on('change', e => {}) system would work nicely.
+                //   As in, is the view.data.model in a valid state or not?
+
+                //   view.data.validation.state ????
+
+
+
+                const vsi = new Validation_Status_Indicator({
+                    context,
+                    // reference data model???
+
+                    validation: {
+                        data: {
+                            model: app_data_model
+                            // And would not currently need to translate between strings and ints.
+                        }
+                    },
+
+                    data: {
+                        model: ti.view.data.model
+                        // And would not currently need to translate between strings and ints.
+                    }
+                })
+                window.inner.add(vsi);
+                
+            }
+
+            //including_data_model_properties_in_spec();
+
+            this._ctrl_fields = this._ctrl_fields || {};
+            const no_data_model_properties_in_spec = () => {
+
+                const ti = new Text_Input({
+                    context
+                })
+                window.inner.add(ti);
+                this._ctrl_fields.ti = this.ti = ti;
+
+                const vsi = new Validation_Status_Indicator({
+                    context
+                })
+                window.inner.add(vsi);
+                this._ctrl_fields.vsi = this.vsi = vsi;
+                
+            }
+
+            no_data_model_properties_in_spec();
+
+            //console.log('ti.data.model._id()', ti.data.model._id());
+
+            //console.log('ti.view.data.model._id()', ti.view.data.model._id());
+
+            //console.log('ti.data.model.value', ti.data.model.value);
+            //console.log('ti.data.model.data_type', ti.data.model.data_type);
+
+            this.body.add(window);
+
+            // this.add(Constructor, spec) possibly???? Would auto add the context as well.
+            // this.add('property_name', Constructor, spec) adds it as a property name and ctrl field.
+            //this._ctrl_fields.ti2 = this.ti2 = ti2;
+
+
+        }
+        if (!spec.el) {
+            compose();
+            //this.add_change_listeners();
+
+            console.log('post compose app_data_model.value:', app_data_model.value);
+        }
+
+        // But client-side, it won't have its contents loaded yet, when activating (I think).
+        // Maybe have a 'load' or 'client-ready' or 'content-loaded' event?
+
+        // 'content-ready' is fairly simple?
+        // 'content-controls-recomposed'???
+
+        // 
+
+        // 'content-controls-loaded'??? Very explicit.
+        // 'content-controls-reconstructed'????
+        //   Could then respond to it in the constructor.
+
+    }
+
+    add_change_listeners() {
+        const {ti} = this;
+
+        // This should be useful for the validation status indicator.
+
+        ti.view.data.validation.status.change('valid', e => {
+            console.log('ti.view.data.validation.status.change valid e:', e);
+        });
+
+
+    }
+
+
+    activate() {
+        if (!this.__active) {
+            super.activate();
+            const {context, ti, vsi} = this;
+
+            
+
+
+            console.log('activate Demo_UI');
+
+            this.add_change_listeners();
+            
+            context.on('window-resize', e_resize => {
+                console.log('e_resize', e_resize);
+                
+            });
+
+
+            // Nice if the obviously unambiguous things could be transferred to the client.
+            //   Maybe setting up a client side Data_Resource makes sense.
+
+            // Would like data model coherence / recomposition / whatever to be done automatically before the activate function
+            //   gets called.
+
+
+            console.log('ti.data.model', ti.data.model);
+            console.log('app_data_model', app_data_model);
+
+            //app_data_model.value = ti.data.model.value;
+
+            // Should sooner or later be done on a lower level where possible.
+
+            const cohere_data_models = () => {
+                console.log('Demo_UI activate cohere_data_models');
+                ti.data.model = app_data_model;
+
+
+                ti.validation.validator.data.model = ti.data.model;
+                ti.validation.target.data.model = ti.view.data.model;
+
+
+
+
+                // View_Validation?
+                // View_Data_Validation???
+                //   So separate to the model itself. Validates the model according to something else (like the data.model / the data)
+
+
+
+
+                // A validation data model?
+
+                /*
+                
+                vsi.validation.approach = 'validate view.data.model by data.model';
+                vsi.validation.data.model = ti.data.model;
+                vsi.validation.view.data.model = ti.view.data.model;
+
+                */
+                // And then it should attach / reattach the appropriate listener(s).
+
+
+
+                //vsi.data.model = ti.view.data.model;
+
+                // then when the validation status indicator has its data model set, it should update its appearance accordingly.
+                //   Getting into different 'view states' could help here.
+                //     Things like this would making defining some controls very simple.
+                //     Soon implement more things like this for a very convenient, concise and explicit high level API.
+
+                // Validation status of one thing according to another thing....
+
+                console.log('post Demo_UI activate cohere_data_models');
+
+            }
+
+            cohere_data_models();
+
+            // new_int_dv(context)
+
+            //ti.view.data.model = new_int_dv(context);
+
+
+
+            // Seems all the updates had not been set up (again) properly.
+            //   When some model(s) get changed.
+            //   All levels of syncing need to go flawlessly.
+
+            //  such as when the data.model is replaced....
+
+            // 
+
+            const log_some_info = () => {
+                console.log('app_data_model.value', app_data_model.value);
+                console.log('app_data_model.data_type', app_data_model.data_type);
+
+
+                console.log('ti.data.model.value', ti.data.model.value);
+
+
+                console.log('ti.view.data.model.value', ti.view.data.model.value);
+            }
+
+            //console.log('ti.view.ll.data.model.value', ti.view.ll.data.model.value);
+
+            // Would be nice to set these up at a stage that works both on server and client,
+            //   whether composed or activated or both.
+
+            // The high level view data model....
+            //   Should make it so that it changes the low level view ui data model back if a change fails.
+            //   Different levels of ensuring validaton - no allowing it to show an invalid state.
+            //     Could be done using a (high level) view data model (with validation enforced)
+
+            /*
+
+            ti.data.model.on('change', e => {
+                console.log('text_input.data.model change e', e);
+            })
+
+            */
+
+            // 
+
+            // ti.data.model.on ('validate')
+
+            // though there could be a validation state data model too (perhaps)
+            //   could listen for changes to the validation state.
+
+            // Think we need to get validation status changes working properly.
+
+            // Maybe be more specific on the type of validation status - eg input validation, user / ui validation / ui input validation????
+
+            // .view.ui.validation makes sense.
+            // as does .view.validation.
+
+            // .view.data.validation too???
+            
+
+
+
+            const more_logging_listeners = () => {
+                ti.data.model.on('change', e => {
+
+
+                    console.log('text_input.data.model change e', e);
+                });
+                ti.view.data.model.on('change', e => {
+    
+    
+                    console.log('text_input.view.data.model change e', e);
+                });
+            }
+
+            
+
+        }
+    }
+}
+
+Demo_UI.css = `
+
+* {
+    margin: 0;
+    padding: 0;
+}
+
+body {
+    overflow-x: hidden;
+    overflow-y: hidden;
+    background-color: #E0E0E0;
+}
+
+.demo-ui {
+    
+    /* 
+
+    display: flex;
+    flex-wrap: wrap;
+    
+    flex-direction: column; 
+    justify-content: center;
+    align-items: center;
+    text-align: center;
+    min-height: 100vh;
+    */
+    
+}
+`;
+
+
+controls.Demo_UI = Demo_UI;
+
+module.exports = jsgui;

package/examples/controls/16a) Window([Text_Input]) Integer data.model.data_type/isomorphic.js

@@ -0,0 +1,24 @@
+const jsgui = require('jsgui3-html');
+const {controls, Control, mixins, Data_Value, Functional_Data_Type} = jsgui;
+
+const new_int_dv = (context) => new Data_Value({context, data_type: Functional_Data_Type.integer});
+
+// Meaning the app_data_model will / should have a validator.
+//   Higher level code could validate according to that.
+
+
+const create_app_data_model = (context) => {
+    const app_data_model = new Data_Value({context, data_type: Functional_Data_Type.integer});
+    //console.log('');
+    //console.log('app_data_model.context', app_data_model.context);
+    //console.log('');
+    app_data_model.value = 5;
+
+    // Could look out for some events here too....
+    
+    return app_data_model;            
+}
+
+module.exports = {
+    create_app_data_model
+}

package/examples/controls/16a) Window([Text_Input]) Integer data.model.data_type/server.js

@@ -0,0 +1,73 @@
+const jsgui = require('./client');
+
+const {Demo_UI} = jsgui.controls;
+
+// Need to load the client to serve it???
+
+const Server = require('../../../server');
+
+const {create_app_data_model} = require('./isomorphic');
+// what would be the (best?) way to include the whole thing in one JS file?
+//  Maybe don't try that right now.
+//  maybe standardise on the dir, then client.js and server.js inside.
+
+
+
+// Want to exclude this from the client bundle.
+//  Some kind of marking to say that it's server-side only?
+
+// Need to include JSGUI3 js within the client document.
+//   Seems like an earlier code simplification removed this functionality?
+//   Just specifying a Ctrl for the server - and giving it the 'disk_path_client_js'.
+//     May as well fix that....
+
+
+// The server code may be tiny, it seems best not to abstract it away totally though.
+// At least not for the moment.
+
+
+
+
+
+if (require.main === module) {
+
+    //const app_data_model = create_app_data_model();
+    //  But better to pass in the data model we have on the server???
+
+    // Would be nicer architecture to be able to access, view and manipulate a Data_Model here on the server side
+    //   before giving it to the client....
+
+    
+
+    const server = new Server({
+        Ctrl: Demo_UI,
+        //debug: true,
+        'src_path_client_js': require.resolve('./client.js'),
+        //debug: true // should not minify the js, should include the symbols.
+        //js_client: require.resolve('./square_box.js')
+    });
+    // A callback or event for when the bundling has been completed
+    //  a 'ready' event.
+
+    // then start the server....
+    // be able to choose the port / ports?
+    console.log('waiting for server ready event');
+    server.one('ready', () => {
+        console.log('server ready');
+
+        // server start will change to observable?
+
+        server.start(8080, function (err, cb_start) {
+            if (err) {
+                throw err;
+            } else {
+                // Should have build it by now...
+    
+                console.log('server started');
+            }
+        });
+    })
+
+    
+
+}