jsgui3-server 0.0.121 → 0.0.123

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

@@ -1,494 +0,0 @@
-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

@@ -1,24 +0,0 @@
-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

@@ -1,73 +0,0 @@
-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');
-            }
-        });
-    })
-
-    
-
-}