jsgui3-server 0.0.121 → 0.0.122

package/examples/controls/15) window, text field/client.js

@@ -1,256 +0,0 @@
-const jsgui = require('jsgui3-client');
-const {controls, Control, mixins} = jsgui;
-const {dragable} = mixins;
-
-
-const {Checkbox, Date_Picker, Text_Input, Text_Field, Validation_Status_Indicator} = controls;
-
-const Active_HTML_Document = require('../../../controls/Active_HTML_Document');
-
-
-
-
-class Demo_UI extends Active_HTML_Document {
-    constructor(spec = {}) {
-        spec.__type_name = spec.__type_name || 'demo_ui';
-        super(spec);
-        const {context} = this;
-        
-
-
-        if (typeof this.body.add_class === 'function') {
-            this.body.add_class('demo-ui');
-        }
-        
-
-        const compose = () => {
-
-            const window = new controls.Window({
-                context: context,
-                title: 'jsgui3-html Text_Field control',
-                pos: [5, 5]
-            });
-
-            window.size = [480, 160];
-            
-
-
-            const tf = new Text_Field({
-                context,
-                text: 'A',
-                data: {model: this.data.model}
-                //value: 'Hello'
-                //label: {
-                //    text: 'A checkbox'
-                //}
-            })
-
-            window.inner.add(tf);
-
-
-            // and give it the data model too....
-
-            // will be the view data model I think it validates against the data model.
-
-            // does now seem like 2 (or more) levels of view model would help. maybe
-
-            // Linking it to something else here could help.
-
-            const tfvsi = new Validation_Status_Indicator({
-                context,
-                //data: {model: this.data.model}
-            })
-
-            window.inner.add(tfvsi);
-            
-
-            this.body.add(window);
-
-            
-            this._ctrl_fields = this._ctrl_fields || {};
-            this._ctrl_fields.tf = this.tf = tf;
-            this._ctrl_fields.tf = this.tfvsi = tfvsi;
-            //this._ctrl_fields.ti2 = this.ti2 = ti2;
-
-
-        }
-        if (!spec.el) {
-            compose();
-            //this.add_change_listeners();
-        }
-
-
-        // Can respond to / deal with changes to the data models here, not only when activated.
-        //   The data.model and view.model system seems to offer some higher level improved programming by putting
-        //   more in the constructor. Maybe the activated code ('.activate') would not be needed on higher level controls,
-        //   because the lower level ones will connect it all up the the dom <> view <> data models / system.
-
-        // It even has a 'dom model' too, of sorts ????
-        //   Though currently it's not named that or considered that throughout the code there.
-        // Could be worth moding to dom.model
-        // then view.model
-        // then data.model
-
-        // Could be a structure that better supports non-dom models.
-        //   Though in this case, it would no yet have the refs to all the child things????
-
-        // Getting that back in the 'compose' or 'recompose' stage could help.
-        //   Though it's currently auto-recompose pre activate.
-
-        // Maybe want code to run either when activated, or post-compose.
-        //   add_change_listeners.
-
-        // Would be run server-side after compose (or when composing it like that on the client)
-        //   but when it gets recomosed on the client-side would need to run then instead.
-
-
-    }
-
-    add_change_listeners() {
-        const {tf} = this;
-
-        // And when the view data model changes, we can validate it against the data model.
-
-        // 
-
-        tf.validation.status.on('change', e => {
-            console.log('tf.validation.status change e:', e);
-        });
-
-
-
-    }
-
-
-    activate() {
-        if (!this.__active) {
-            super.activate();
-            const {context, tf} = this;
-
-            //this.add_change_listeners();
-
-            // Getting data and view models properly set up before 'activate' would be nice.
-
-
-
-
-            console.log('activate Demo_UI');
-
-            console.log('tf.data.model', tf.data.model);
-            console.log('this.data.model', this.data.model);
-            console.log('this.view.data.model', this.view.data.model);
-
-            //const this_and_tf_share_data_models_on_activation = tf.data.model === this.data.model;
-
-            const this_and_tf_share_data_models_on_activation = tf.data.model === this.view.data.model;
-
-            console.log('this_and_tf_share_data_models_on_activation', this_and_tf_share_data_models_on_activation);
-
-            if (!this_and_tf_share_data_models_on_activation) {
-                tf.data.model = this.view.data.model;
-
-                // and indicate the validity of the data in the view model too...
-
-
-
-
-                console.log('tf shares data model with this.view');
-            }
-
-            // The tf needs to get its data model from the inner Text_Input.
-            //   Though maybe they could actually be the same objects in this case.
-
-            
-
-
-            tf.data.model.on('change', e => {
-                console.log('tf data model change:', e);
-            })
-            
-            context.on('window-resize', e_resize => {
-                
-            });
-
-        }
-    }
-}
-
-// Include this in bundling.
-//  Want CSS bundling so that styles are read out from the JS document and compiled to a stylesheet.
-
-//controls.Demo_UI = Demo_UI;
-
-// A css file may be an easier way to get started...?
-//  Want to support but not require css in js.
-
-// But need to set up the serving of the CSS both on the server, and on the client.
-//  Ofc setting it up on the server first is important - then can that stage set it up in the doc sent to the client?
-
-// Including the CSS from the JS like before.
-//  Needs to extract the CSS and serve it as a separate CSS file.
-//  Should also have end-to-end regression tests so this does not break again in the future.
-//   The code was kind of clunky and got refactored away.
-//   
-
-// Would need to parse the JS files to extract the CSS.
-//  Maybe could do it an easier way??? Now that it's easy, want a faster way.
-
-
-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;
-    */
-    
-}
-`;
-
-// But may want to remove them from that flex upon picking up / dropping them.
-//  Maybe best upon drop.
-
-// Maybe want other examples that use absolute positioning to position the items at the start?
-// 
-
-
-
-//controls.Square_Box = Square_Box;
-// could export jsgui with the updated controls....
-//  so that they are in the correct Page Context.?
-
-
-controls.Demo_UI = Demo_UI;
-
-module.exports = jsgui;
-
-/*
-module.exports = {
-    Square_Box: Square_Box,
-    Demo_UI: Demo_UI
-}
-*/
-
-// Then if window...?
-
-// Need to add the Square_Box control to the context or original map of controls...
-

package/examples/controls/15) window, text field/server.js

@@ -1,39 +0,0 @@
-const jsgui = require('./client');
-
-const {Demo_UI} = jsgui.controls;
-const Server = require('../../../server');
-
-
-
-if (require.main === module) {
-
-    const server = new Server({
-        Ctrl: Demo_UI,
-        debug: true,
-        'src_path_client_js': require.resolve('./client.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');
-            }
-        });
-    })
-
-    
-
-}

package/examples/controls/16) Window([Text_Input])/client.js

@@ -1,266 +0,0 @@
-const jsgui = require('jsgui3-client');
-const {controls, Control, mixins, Data_Value, Functional_Data_Type} = jsgui;
-const {dragable} = mixins;
-
-
-const {Checkbox, Date_Picker, Text_Input, Text_Field} = controls;
-
-const Active_HTML_Document = require('../../../controls/Active_HTML_Document');
-
-
-
-
-class Demo_UI extends Active_HTML_Document {
-    constructor(spec = {}) {
-        spec.__type_name = spec.__type_name || 'demo_ui';
-        super(spec);
-        const {context} = this;
-        
-
-        if (typeof this.body.add_class === 'function') {
-            this.body.add_class('demo-ui');
-        }
-
-        
-
-        const create_app_data_model = () => {
-            
-            const app_data_model = new Data_Value({context, data_type: String});
-
-
-            return app_data_model;            
-        }
-        
-
-        const app_data_model = create_app_data_model();
-
-        app_data_model.on('change', e => {
-            console.log('app data model change e:', e);
-            const {value} = e;
-            console.log('value', value);
-
-        })
-
-        this.app_data_model = app_data_model;
-        // See if there is a way to get it to keep that Data_Model upon recomposition....?
-        //   Seems like there may be a need to load the view.ui.ll.data.model upon activation.
-
-        // Seems like a fair bit of complexity will be needed for even the simplest controls, but
-        //   those controls will have extra capabilities that are easy to use for the high level programmer.
-
-        // Or nothing needs to be low level like that for the moment.
-
-
-        // activate_data_model???
-        // activate_ctrl_data_models???
-
-
-
-        
-
-
-
-
-
-        // Want to define compositionally how data models sync with the UI.
-        //   Incl how to parse / get the value from the ui.
-        //   The lowest level data model in the case of text_input will be a string.
-
-        // view.ui.ll.data.model.value I think.
-
-        // The low level view ui data model.
-        // ---------------------------------
-
-        // Not sure it will exist in the cases of all controls.
-        // Probably also want to get it explicitly referring to .value of an element or something like that.
-        //   .get_element_value ????
-
-        // .dom.el.value would make sense, as it currently is.
-
-
-
-
-
-
-
-
-
-
-        //   Is worth keeping it verbose like that to be extremently clear what it is.
-        //     Will not need to refer to it like that in high level code.
-
-
-
-
-
-
-
-
-
-        const compose = () => {
-
-            const window = new controls.Window({
-                context: context,
-                title: 'jsgui3-html Text_Input control, using data.model.data_type = Integer',
-                pos: [5, 5]
-            });
-
-            window.size = [480, 160];
-
-            // See how easy this could be made to be set up with composition.
-            //   Or, on start of the Demo_UI.
-
-            // and give it the data.model of app_data_model.
-
-            const ti = new Text_Input({
-                context,
-
-                data: {
-                    model: app_data_model
-                    // And would not currently need to translate between strings and ints.
-                },
-                //text: 'A',
-                value: 'Hello'
-                //label: {
-                //    text: 'A checkbox'
-                //}
-            })
-
-            window.inner.add(ti);
-
-            console.log('ti.data.model.value', ti.data.model.value);
-
-            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 = this._ctrl_fields || {};
-            this._ctrl_fields.ti = this.ti = ti;
-            //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);
-        }
-
-    }
-
-    add_change_listeners() {
-        const {ti} = this;
-
-
-
-    }
-
-
-    activate() {
-        if (!this.__active) {
-            super.activate();
-
-            // Does seem like trying to deal with multiple view models makes it more difficult.
-
-
-
-
-            const {context, ti, app_data_model} = this;
-
-            //this.add_change_listeners();
-
-
-            console.log('activate Demo_UI');
-            
-            context.on('window-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.
-
-
-
-            app_data_model.value = ti.data.model.value;
-            ti.data.model = app_data_model;
-
-
-            // 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....
-
-            // 
-
-            console.log('app_data_model.value', app_data_model.value);
-            console.log('ti.data.model.value', ti.data.model.value);
-            //console.log('ti.view.ll.data.model.value', ti.view.ll.data.model.value);
-            //console.log('ti.view.ui.ll.data.model.value', ti.view.ui.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.
-
-            /*
-
-            ti.data.model.on('change', e => {
-                console.log('text_input.data.model change e', e);
-            })
-
-            */
-
-            // Should not raise the event before the value is set.
-
-            ti.view.data.model.on('change', e => {
-                // maybe the event should say how the chain has progressed?
-
-                console.log('1) text_input.view.data.model change e', e);
-                //console.trace();
-            })
-
-            //ti.view.ll.data.model.on('change', e => {
-
-            //    console.log('1) text_input.view.ll.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/16) Window([Text_Input])/server.js

@@ -1,109 +0,0 @@
-const jsgui = require('./client');
-
-const {Demo_UI} = jsgui.controls;
-const Server = require('../../../server');
-
-
-// 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) {
-
-    // By default should include the JS and the CSS.
-    // By reference, serving them from their respective paths.
-
-
-    // This API is not working right now.
-
-    // A very simple syntax for running a single control would be great.
-
-    // Need to in the default (server) configuration build and serve the client-side app.
-    // Want to be able to make interactive apps quickly with minimal server side code that needs to be written as boilerplate to
-    // get the app running.
-
-    // Though maybe defining a webpage, that serves the client js, and renders the control on the server, and activates it on the client,
-    // would be the right approach.
-
-    // Want to make the code really explicit, in a simple way.
-
-
-    // eg { '/': Demo_UI }
-    // eg { '*': Demo_UI }
-    //  as at least it explicitly assigns it to the '/' route
-
-
-    // But worth keeping the '/' Ctrl property?
-    //  Could change it to explicitly setting the route(s).
-
-    // Do want it to build the client js on start.
-
-    // Could extract the CSS from the file itself, or maybe better reading it from the classes and objects that are loaded / referenced.
-    // All kinds of complex server program structures exist already, so could use Publishers if needed for some things.
-    //  But need to keep the surface-level API really simple.
-
-    // Maybe define a Webpage and maybe use / define an HTML_Webpage_Publisher for example too.
-    // The clearest code would be really explicit about what it does, but in terms of almost English idioms
-    //  and on the surface-level not spelling out in great detail what it's doing, but referencing objects and
-    //  instructions with clear purposes, though details could be obscure at the top level. Eg it's the publisher's responsibility
-    //  to include the CSS and JS that's needed to get it to run. A publisher is referenced and used, and it does its thing.
-
-    // The Server could automatically involk the use of a Publisher.
-    //  May be better to either require or recommend more explicit code, have them in the examples,
-    //  but also to document some shortcuts, defaults, and abbreviations (though they may omit some essential info, so not recommended for beginners)
-
-    // Could have a tabbed view for examples for 'explicit' and 'short' notations when there are multiple.
-
-    // jsgui3-html-suite may be of use, for some more extended controls that are built on top of jsgui3-html, but not specifically
-    // client or server.
-
-    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');
-            }
-        });
-    })
-
-    
-
-}