jsgui3-server 0.0.121 → 0.0.123

package/examples/controls/13) window, shared model mirrored lat_long/client.js

@@ -1,933 +0,0 @@
-const jsgui = require('jsgui3-client');
-const {equals, controls, Control, mixins, Data_Object, Data_Value, Functional_Data_Type, field, Control_Data, Control_View} = jsgui;
-
-
-
-const {Checkbox, Date_Picker, Text_Input, Text_Field} = controls;
-
-const Active_HTML_Document = require('../../../controls/Active_HTML_Document');
-
-// To get this working, looks like it's worth making more examples.
-//   Possibly showing validation status as well.
-
-// Data_Model and Data_Value ease of use on both the client and the server.
-
-
-
-// Would be nice to make other things like this that are more advanced.
-//   Could handle parsing text to multiple values in an array, eg [lat, long]
-
-
-// Want to support convenient high and mid level code, where the format of data gets described concisely.
-
-// Functional_Data_Type lat_long perhaps???
-//   it could be an array internally even.
-
-// Or make classes that can handle this stuff too...?
-//   Standardise a simple API for data types / allow multiple APIs / ways of expressing them.
-
-// Also other validation functions and properties.
-//   eg string between 4 and 32 characters long.
-//    failing validation with a reason as well.
-//      Maybe programatically expressed and then can render messages to different languages in an extendable way.
-
-// Working on making the lower level supports for data types could be very useful.
-//   Controls could use a lower level API to better interact with (shared) data.
-
-// Controls, such as Text_Field, should have a Validation_Status_Display or similar.
-//   Role assignment of controls?
-//     So some kind of icon / message display control could be given the role of validation status display / view.
-//       Or it's data.model could be the validation status.
-
-// Does seem like it would make for (very) good linking without having to write the wiring / plumbing code on the highest level.
-
-
-// Will make Date_Picker use progressive enhancement.
-//   On activation would create a new element? Create a new sibling?
-//     May want code that checks for .el being changed.
-
-
-
-// Want the data sharing to be really simple and intuitive to set up.
-//   But not so simple the comlexities of data flow can't be expressed when needed.
-
-
-// Make it so sharing a data model is very easy.
-//   Sharing a single value, or referring to different values within it.
-
-// Be able to handle errors when the view model can't update the data_model for some reason(s).
-
-
-
-// Want to see about latitude and longitude UI components, and linking the components with a data model.
-//   Have the view data model and the data model working together properly.
-
-// control.view.data.model and control.data.model together seem very effective.
-//   May be worth integrating on a lower level.
-
-// Also want to get the color palette data model working properly.
-//   Could be a bit more complex. Array of colors. Colors defined in some detail, or dealt with in a functional way for the moment.
-
-
-
-// Want to see about rendering controls that are automatically composed according to their data.model
-//  or view.data.model 
-
-
-// Want some kind of flexible property or data editor?
-//   Maybe later, but let's make it easy to build and use specific controls to edit specific data.
-
-// Could have mirrored lat_long_coords control.
-
-
-// Need the Lat_Long control here.
-
-// Would contain two text fields.
-//   Then could make lower / mid level abstraction(s) that automatically create it from the Data_Type or Data_Type_Definition
-//    perhaps.
-
-// Definitional_Data_Type possibly.
-// Definitional_And_Functional_Data_Type ????
-
-// Presentational_Data_Type possibly???
-
-// Data_Type_Presentation???
-// Data_Type_Representation ???
-//   And that gets closer to the control.ui.data.model
-//   ctrl.presentation.data.model ???
-
-// .ui will make sense when that time comes.
-
-
-// This codebase here should have a bit more than the essentials to get it to work.
-//   Want to work on some lower level things to get it to work more effectively.
-
-// A Properties_Editor type of Control could be a very effective one for the moment, to get everything working nicely
-//  and because it would be a useful control in itself.
-// Could easily be within jsgui3-html, as one of the more advanced / standard / non-core controls.
-//   Though make it simple and idiomatic, it could be in the core more easily.
-
-
-
-
-
-
-
-const fdt_latitude = new Functional_Data_Type({
-    name: 'latitude',
-    value_js_type: Number,
-    validate: x => {
-        const tx = tof(x);
-        //console.log('latitude tx', tx);
-        // or get the sig.
-        const sig_x = get_item_sig(x);
-        //console.log('latitude sig_x', sig_x);
-        if (sig_x === 'n') {
-            // then are the within the right ranges...?
-            // Latitude is specified in degrees within the range [-90, 90]. Longitude is specified in degrees within the range [-180, 180).
-            if (x >= -90 && x <= 90) {
-                return true;
-            }
-        }
-        return false;
-    }
-});
-
-
-// Something to say it's a number / integer???
-
-const fdt_longitude = new Functional_Data_Type({
-    name: 'longitude',
-    value_js_type: Number,
-    validate: x => {
-        const tx = tof(x);
-        // or get the sig.
-        //console.log('longitude tx', tx);
-        const sig_x = get_item_sig(x);
-        //console.log('longitude sig_x', sig_x);
-        if (sig_x === 'n') {
-            // then are the within the right ranges...?
-            // Latitude is specified in degrees within the range [-90, 90]. Longitude is specified in degrees within the range [-180, 180).
-            if (x >= -180 && x <= 180) {
-                return true;
-            }
-        }
-        return false;
-    }
-});
-
-
-const fdt_lat_long = new Functional_Data_Type({
-    name: '[latitude, longitude]',
-    value_js_type: Array,
-    named_property_access: true,
-    property_names: ['latitude', 'longitude'],
-    property_data_types: [fdt_latitude, fdt_longitude],
-    // And the property types as well being the same in this case?
-    abbreviated_property_names: ['lat', 'long'],
-    numbered_property_access: true, // Maybe that's good enough to make it like an array when there are 2 properties.
-
-    // wrap_value property???  maybe not because the Data_Value with this Data_Type does wrap that value already.
-
-
-    //   so if it's an array it wraps that?
-    // wrap_properties - does make sense, as properties may need to be their own Data_Value of that Data_Type.
-    wrap_properties: true,
-    wrap_value_inner_values: true,
-
-    // wrap_value_inner_values???
-
-
-
-
-    // zero_indexed_numbered_property_access perhaps???
-
-    // something to say it's an array pair?
-    //   maybe the 'sig'???
-    // Here focus more on getting the validation working than using the definition.
-    //   However, providing the definition / description could help.
-
-    validate: x => {
-        const sig_x = get_a_sig(x);
-        if (sig_x === '[n,n]') {
-            const [lat, long] = x;
-            return fdt_latitude.validate(lat) && fdt_longitude.validate(long);
-        }
-        return false;
-    }
-});
-
-// Then the control to represent them both....
-
-
-// This could indeed have base functionality to get the data.model and view.data.model set up.
-// Maybe even define some control.view.ui.composition.model.content which would take the place of control.content
-
-// Getting much more explicit with names for parts of control functionality will help. The point will be to avoid confusion.
-//   Often when using controls we would not need to be so explicit, the app will know which explicit thing to use on a lower level.
-
-
-
-
-// Classes for controls that inherently have some kind(s) of data...?
-
-
-// Late 2023 - Does seem best right now not to make breaking changes, or try them, when it comes to control compositional model.
-//   May be worth isolating the code where possible so those breaking changes could be attempted and switched in / out.
-
-
-
-// Controls where the compositional model follows the data model.
-
-// Need to be able to talk to, and talk about, controls on different levels.
-
-// What they represent (both what they are showing now, and the assigned and accepted model that the app is using). How they represent it.
-//   Data_Type or data.model.data_type seems very important. Maybe just access it as data.type.
-//    data.model would be the instance. It may have a .data_type property.
-
-// But control.data.type makes sense.
-//   And give it a functional data type, or maybe a different sort, maybe have functional data types
-//     created from definitions.
-
-
-// Data_Type definitely seems useful / important.
-//   Definitional_Data_Type ???
-//   Grammar_Data_Type ??? Grammar_Specified_Data_Type ???
-
-
-// Would like Data_Type to be fairly simple and to-the-point where possible.
-//   Focusing on making it work as a schema for data that's made out of JS objects and easy to turn into JSON would help.
-//     Be able to keep some of the hard work / complexity behind the scenes.
-
-// Will work towards simpler component specification and use where it's according to / editing / viewing specific data types.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-class Base_Lat_Long extends Control {
-
-
-    constructor(spec) {
-        super(spec);
-
-
-
-    }
-
-
-}
-
-
-
-// Want creation of a control to interact with data to be easy to make.
-//   Could make use of sensible defaults on a lower and mid level.
-
-// A somewhat basic control that represents a Data_Value that itself contains a pair of Data_Values...?
-//   And specify which controls it uses internally as the view for those values...?
-
-
-// Definitely need to simplify making the controls that avt as a view for a Data_Value.
-//  Basically controls that represent a value.
-
-// The compositional model.
-// Then how to compositional model relates to the data model?
-//   Or include info on what data the various parts have access to (and specifically edit) within the composition model?
-
-// Maybe some new kind of 'model' or object that represents how the data in the data / view model gets represented in terms of
-//   the compositional model?
-
-// Ie the data representation model?
-//  data.view.model even????
-
-// Do want to get the high level code to be both very concise and explicit.
-//   Unambiguous, yet also not many words used to express it.
-//     Though a small number of words that describe it explicitly is fine.
-
-// view.ui.composition.model 
-// view.ui.data.representation.model
-//   does make sense for defining how data (referencing the data model and view data model) gets represented.
-
-// data.representation.model
-//    does make a lot of sense to have this thing.
-//    want to be able to approach it in a declarative kind of way.
-
-// composition and representation together....?
-//   could be possible.
-
-// maybe call it a 'view definition'.
-//   or a 'combined representation model'?
-//   or a 'composition and representation model'?
-
-// The two things are closely related, maybe ok giving info about how the data gets represented inside the composition model.
-//   However, explicitly giving both makes a lot of sense.
-
-// Defining the control composition model(s) would be very helpful.
-//   It mean the normal compose() functions will no longer be needed, many will be able to be expressed much more concisely.
-
-// The data composition???
-//   The data.representation makes most sense.
-//   How, within the composition, is the data represented.
-
-// eg which control, by name, operates on which property of a Data_Model?
-
-// Anyway, need to set up the control.view.ui.composition.model
-//   A composition model could extend Data_Value, and have an underlying array.
-//   Makes sense that way.
-
-// Composition models in cases where things get repeated (by some number maybe from the data.model, view.data.model, view.ui.composition.data.model)
-
-// both composition model, and the composition data model???
-//   not so sure about yet another data model, being the compositional data model.
-//     But it could make sense for the data that's directly got to do with how the control gets composed.
-//     
-
-// For the moment, extend these capabilities to all controls.
-//   Need to be careful though about slowing down controls in general.
-//   Not every control would have / need a compositional model (I currently assume)
-//     Though it may make sense as where what's inside that control, and tagName, or other info, get stored.
-//     Eg store the fact that it's composed as a DOM node, then the fact it's composed as an element.
-//       Compositions which include text nodes too....
-
-// It seems worth working on some simpler controls to implement and use the compositional model system.
-//   Text_Field, maybe Text_Input too...?
-
-// Maybe the compositional model would help with things like inserting a label inside the Text_Input control.
-
-
-// The compositional model will be a really quick way to express what the control is made out of.
-//   (other controls).
-// Also would specify internal spaces.
-
-// Perhaps sometimes derive the data representational model?
-//  data-representation-composition???
-
-// model_that_defines_how_the_data_model_corresponds_to_the_compositional_model
-// data_model_compositional_model_correspondance????
-
-// Do need to be able to go into a lot of (necessary) detail about controls.
-//   The lower level parts of it seem essential when it comes to expressing things really concisely and explicitly on a high level.
-
-// ctrl.view.ui.data.compositional.model
-//   That may make sense as to where some model of how the data from the data model gets composed into the controls in the
-//   ctrl.view.ui.compositional.model
-
-
-// Late 2023 - does seem worth introducting these things as new features that work alongside with what already exists.
-//   For the moment, don't change control.content
-//     deep descriptive namespaces will help the high and mid level code avoid ambiguity.
-
-// Seems like integrating this into the core of control makes sense.
-//   Or maybe implementing it all as a mixin for the moment???
-
-// Data_Features?
-// Control_Multi_Modal_System???
-
-// MVVMMM??
-
-// the xM system perhaps?
-// xMVM
-// view_and_models???
-
-// view_and_data_and_composition_models
-
-// model_view_data_composition_representation
-
-// DMVDMVCMVDRM
-
-// Doing this all in a mixin could make sense.
-//   
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-class Simple_Lat_Long extends Base_Lat_Long {
-    constructor(spec) {
-        super(spec);
-
-        this.__type_name = 'simple_lat_long';
-
-        // But also define the data types of those fields...?
-
-        // Though likely these fields would not need to be specified as it's part of the Data_Model.
-        //   But possibly we really do need a Data_Type to give to the control.data.model
-
-
-
-        field(this, 'lat', fdt_latitude);
-        field(this, 'long', fdt_longitude);
-
-        const {context} = this;
-        const construct_synchronised_data_and_view_models = () => {
-            this.data = new Control_Data({context})
-            if (spec.data && spec.data.model) {
-                this.data.model = spec.data.model;
-            } else {
-                this.data.model = new Data_Object({context});
-                field(this.data.model, 'value');
-            }
-            this.view = new Control_View({context})
-            if (spec.view && spec.view.data.model) {
-                this.view.data.model = spec.view.data.model;
-            } else {
-                this.view.data.model = new Data_Object({context});
-                field(this.view.data.model, 'value');
-            }
-            // 
-
-            this.data.model.on('change', e => {
-                const {name, value, old} = e;
-                if (name === 'value') {
-                    if (!equals(value, old)) {
-                        this.view.data.model.value = value;
-                    }
-                }
-            });
-            this.view.data.model.on('change', e => {
-                const {name, value, old} = e;
-                if (name === 'value') {
-                    if (!equals(value, old)) {
-                        this.data.model.value = value;
-
-                        /*
-
-                        if (this.dom.el) {
-                            this.dom.el.value = value;
-                        }
-
-                        */
-
-
-                    }
-                }
-            });
-        }
-        construct_synchronised_data_and_view_models();
-
-
-        // and specify the Data_Type for the Text_Field control too.
-        //   Want to introduce powerful features into core / easy to access and use controls.
-        //    Maybe not just on composition...?
-        //    Be able to have the text field know its data-jsgui-data-type
-        //      and these data-types would be registered or available somehow within jsgui.
-
-        // Where possible, want the high level API not to need mention of data models, but they work well in the background.
-
-        // May be worth completely redoing / majorly refactoring this lat/long example.
-        //   Possibly defining a 'compositional model' would help.
-        //     Would itself be a Data_Value probably.
-
-
-
-
-
-
-
-        const compose = () => {
-            const {context} = this;
-            const tf_lat = new Text_Field({
-                context,
-                name: 'Latitude',
-                text: 'Latitude'
-            });
-
-            const tf_long = new Text_Field({
-                context,
-                name: 'Longitude',
-                text: 'Longitude'
-            });
-
-            this.add(tf_lat);
-            this.add(tf_long);
-
-            this.tf_lat = tf_lat;
-            this.tf_long = tf_long;
-
-            this._ctrl_fields = this._ctrl_fields || {};
-
-            this._ctrl_fields.tf_lat = tf_lat;
-            this._ctrl_fields.tf_long = tf_long;
-
-        }
-        if (!spec.el) compose();
-    }
-
-    activate() {
-
-        if (!this.__active) {
-
-
-            // Want to get concise and efficient data model and view model access idioms set up.
-            //   However, for the moment, be very explicit about what it's doing before making idioms.
-
-
-
-
-            super.activate();
-
-
-            // Just listening to the changes here for debug purposes.
-
-            this.tf_lat.on('change', e => {
-
-                // Need the more advanced Data_Value / Data_Model equals(supporting?) function.
-
-
-
-                if (!equals(e.value, e.old)) {
-
-
-                    console.log('tf_lat change e', e);
-                }
-
-            })
-
-            this.tf_long.on('change', e => {
-                //console.log('Simple_Lat_Long tf_long change e', e);
-
-                if (!equals(e.value, e.old)) {
-                    //this.long = e.value;
-
-                    console.log('tf_long change e', e);
-
-                }
-            });
-
-            // Maybe look more specifically at this.data.model.change, this.view.data.model.change.
-
-            // Though will want to set up shortcut access on the control to what's in the data.model.
-            //   Generally referring to the data.model will be best, however confusion will be avoided by having and using both
-            //   data.model and view.data.model.
-
-            // Will be easy enough eventually.
-            //   The subtleties must be made to work on a lower level.
-
-
-
-            /*
-
-            this.on('change', e => {
-                const {name, value} = e;
-
-                //console.log('Simple_Lat_Long change e', e);
-                //console.log('[name, value]', [name, value]);
-    
-                // text_field.value should work.
-    
-                if (name === 'lat') {
-                    // then change it in the ui / the view????
-                    // .view.ui ????
-    
-                    this.tf_lat.value = value + '';
-    
-                } else if (name === 'long') {
-                    this.tf_long.value = value + '';
-                }
-            });
-
-            */
-        }
-
-    }
-}
-
-controls.Simple_Lat_Long = Simple_Lat_Long;
-
-//jsgui.controls.register(Simple_Lat_Long);
-
-
-
-
-
-
-
-
-class Demo_UI extends Active_HTML_Document {
-
-    constructor(spec = {}) {
-        spec.__type_name = spec.__type_name || 'demo_ui';
-        super(spec);
-        const {context} = this;
-
-        const setup_demo_ui_data_model = () => {
-            this.data = {
-                model: new Data_Value({
-                    context,
-                    data_type: fdt_lat_long
-                })
-            }
-            //field(this.data.model, 'value');
-            context.register_control(this.data.model);
-        }
-        setup_demo_ui_data_model();
-
-
-        if (typeof this.body.add_class === 'function') {
-            this.body.add_class('demo-ui');
-        }
-
-        //console.log('this.body', this.body);
-        //console.log('this.body.add_class', this.body.add_class);
-
-        const compose = () => {
-
-            const window = new controls.Window({
-                context: context,
-                title: 'jsgui3-html Shared data.model integer Mirrored Text_Input controls',
-                pos: [5, 5]
-            });
-
-            window.size = [480, 160];
-
-            const ti1 = new Simple_Lat_Long({
-                context,
-                data: {
-                    model: this.data.model
-                }
-            })
-            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 Simple_Lat_Long({
-                context,
-                data: {
-                    model: this.data.model
-                }
-            })
-            window.inner.add(ti2);
-            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;
-
-
-        }
-        if (!spec.el) {
-            compose();
-        }
-    }
-    activate() {
-        if (!this.__active) {
-            super.activate();
-            const {context, ti1, ti2} = this;
-
-            console.log('activate Demo_UI');
-
-
-            // Reconstructing the 
-
-            const activate_demo_ui_data_model = () => {
-
-
-                
-                //
-
-                if (ti1.data && ti2.data) {
-
-                    console.log('ti1.data.model === ti2.data.model', ti1.data.model === ti2.data.model);
-
-                    if (ti1.data.model === ti2.data.model) {
-                        // This is really the way it should be. Can see about fixing it on a lower level.
-
-                    } else {
-
-                        // 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.
-
-
-
-
-                        const dm = new Data_Value({context,
-                            data_type: Functional_Data_Type.integer});
-
-                        // Should be enough here....
-                        
-                        //field(dm, 'value');
-                        ti1.data.model = dm;
-                        ti2.data.model = dm;
-
-                        // 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();
-
-
-                    }
-
-                } else {
-                    console.log('missing ti1.data && ti2.data');
-                }
-
-                
-            }
-
-            activate_demo_ui_data_model();
-            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...
-