jsgui3-server 0.0.115 → 0.0.117

package/examples/controls/10) window, mirrored text inputs/client.js

@@ -152,26 +152,44 @@ class Demo_UI extends Active_HTML_Document {
             //   Automatically avoiding feedback somehow???
             //     If it gets changed to its current value it does not push the change...?
 
+            // on the data model change instead....
 
-            ti1.on('change', e => {
+
+            // Code has got more complex supporting things by data model changes for the moment.
+            //   May help a lot when making it more explicit.
+
+
+
+            // But could make 'on' (normally?) refer to the .data.model???
+            //   For the moment, keep the more explicit notations, as well as backwards compatibility.
+
+            // ctrl.dom.on may help, be a nicer and more concise syntax, just as explicit (considering the 'on' abbreviatrion)
+
+
+            // does seem convenient having .on refer to dom events if it's an appropriate event name for that.
+
+            
+
+
+            ti1.data.model.on('change', e => {
                 //console.log('ti1 change e', e);
 
                 if (e.value !== e.old) {
-                    ti2.value = e.value;
+                    ti2.data.model.value = e.value;
                 }
 
                 
 
-            })
-            ti2.on('change', e => {
+            });
+            ti2.data.model.on('change', e => {
                 //console.log('ti2 change e', e);
 
                 if (e.value !== e.old) {
-                    ti1.value = e.value;
+                    ti1.data.model.value = e.value;
                 }
 
                 
-            })
+            });
 
             // listen for change events.
             //   would be nice to know which change events originated from the user interacting with that specific HTML element (or ctrl???)

package/examples/controls/11) window, mirrored text fields/client.js

@@ -12,6 +12,105 @@ const Active_HTML_Document = require('../../../controls/Active_HTML_Document');
 //     May want code that checks for .el being changed.
 
 
+/*
+    Though this works through simple principles, it may be much better to do data binding with a shared ctrl.data.model.
+    Want the top-level code to be really simple and intuitive when specifying data flows, and when not specifying them
+    using sensible defaults.
+
+    The granularity between data.model and view.model should help a lot.
+
+    // Also data.model.value being a possible default.
+    // Data models will become more advanced and capable of holding multiple values.
+    //   For the moment, although the Control_Data and Control_View classes exist, will continue with a POJO.
+    //     Then could later work on getter / setters for when a data.model or a view.model gets changed.
+
+
+
+    Also should work on functional constraints or / and class based constraints for fields / text fields.
+    // Both for data in the system, as well as in the UI.
+    // Could integrate a bit more with data types / class data types.
+
+    // Typed_Data_Value perhaps.
+
+    // Anyway, want to set things up better with the .view.model and .data.model system.
+
+    // Then later support more complex (and / or app-defined) data and view models.
+
+    // Defining what the underlying data of the app is could help (a lot).
+    //   Some data may be for editing, some not.
+
+    // A data model could have a bunch of news articles, and be set up so that they can be viewed nicely.
+    //   Would not be so important to edit the articles themselves, though maybe the user may want to tag them
+    //   and comment on them.
+
+    // Mid-level complexity handling a fair bit of what needs to happen with multiple models, how updates get sequenced
+    //   but then at a high level code must be really simple.
+    // Could distinguish between view and data models at high level - may help a lot in some cases.
+    //   However, will generally assume a shared data model between controls, not a shared view model, and the data model
+    //     will be updated with at least some small / sensible hesitation.
+    //       Maybe even define the update hesitations / update hesitation mode.
+    //   Data Model Update Hesitation Mode???
+
+    // View Model To Data Model Syncing Update Hesitation Mode???
+    //   really explicit names on the more complex mid level will help the code and system to make sense.
+    
+    // syncing.view_to_data.hesitation = 'leave-control' ????
+    //   And could have that one as the default.
+    //     Or could hesitate / debounce 250ms for example.
+    // Very very explicit on the more complex mid / lower level, so that it's really simple on the higher level,
+    //   and can (quickly?) get into more explicit details when needed.
+
+    // Data model syncing seems best in general.
+    //   Then sync data model changes immediately to view models.
+    //   Then only sync view model changes to data model after necessary hesitation / event / confirmation.
+    //     Also be able to cancel view model changes (load values back from data model possibly, some contexts makes a lot more sense)
+
+
+    // The view model is essentially internal to the control - though maybe it would integrate with a whole Page_Context view
+    //   model that's for all the controls...?
+
+    // Internal and separate view models for the controls seems best for the moment.
+    //   Could always use refs to some place else.
+
+    // Have the controls automatically create their view model.
+
+    // Some controls should not determine the data model at application (or larger control) start.
+    //   Maybe some should?
+
+    // Or better to change it so that the Data_Model gets set first, then all the controls given access to it at start (on server)
+    //   and get rendered on the server with the correct data, then on the client it only sets the view_model at the start.
+    //     Or does it???
+    // Want different sensible options for getting that Data_Model to the client. Maybe getting the View_Model to the client????
+
+    // Make it simple and easy to code on the top level API.
+
+    
+    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+*/
+
 
 
 
@@ -65,45 +164,20 @@ class Demo_UI extends Active_HTML_Document {
 
             window.size = [480, 160];
 
-            // Have Tab_Page items inside???
+            // Without specifying the data model.
+            //   Should be able to use and refer to data and view models even when not specified.
+            //     Want this complexity on the lower level to enable simple (but not overly simple/simplstic) higher level programming.
 
-            // Setting a 'selectable' property at the composition stage could be very helpful in some cases,
-            //   May want composition-level mixins?
-            //   Maybe those mixins would also have code that runs on activation.
-            //     'compositional mixins' ???
 
-            // Need mixins to be very flexible to avoid the probles React had with them.
-            //   Choose what functionality the mixin provides in some cases.
-            //     Need to keep tight control over the coupling of mixins.
-            //   Each mixin may need to be somewhat complex to avoid hiccups - and to consistently act in the set modes.
-            //     If a mixin is to do something different to before that functionality should be called differently.
-
-            // mixin.enabled_feature_sets = [feature_set_1_name, feature_set_2_name] ....
-
-
-
-            // Will work on more options & perfection for month_view.
-
-            /*
-
-            new Checkbox({
-                context,
-                label: {
-                    text: 'A checkbox'
-                }
-            })
-
-            */
-            
-            // Sensible properties like this will help.
-            
-            // A progressively enhancing control could help a lot.
-            //   Something that when it's in the doc will even replace its own element.
-            //   Lower level code to enable really simple to express progressive enhancement could help, maybe would not be needed.
 
+            // Should set up its data model automatically if not specified here.
+            //   An independent data model, specifically for that text field.
 
+            // Or in the data.model.label_text perhaps?
 
+            // Want to make it easy to make and use somewhat more complex and expressive structures.
 
+            // The text label makes more sense being in the view.data.model???
 
             const ti1 = new Text_Field({
                 context,
@@ -131,20 +205,86 @@ class Demo_UI extends Active_HTML_Document {
 
             
             this._ctrl_fields = this._ctrl_fields || {};
-            this._ctrl_fields.ti1 = ti1;
-            this._ctrl_fields.ti2 = ti2;
+            this._ctrl_fields.ti1 = this.ti1 = ti1;
+            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 {ti1, ti2} = this;
+
+        // Need to fix the text_field data model and view model system.
+
+        //console.log('add_change_listeners');
+        ti1.data.model.on('change', e => {
+            //console.log('ti1 e', e);
+            if (e.name === 'value') {
+                if (e.value !== e.old) {
+                    ti2.data.model.value = e.value;
+                }
+            }
+        });
+
+        ti2.data.model.on('change', e => {
+            //console.log('ti2 e', e);
+            if (e.name === 'value') {
+                if (e.value !== e.old) {
+                    ti1.data.model.value = e.value;
+                }
+            }
+        });
+
+    }
+
+
     activate() {
         if (!this.__active) {
             super.activate();
             const {context, ti1, ti2} = this;
 
+            this.add_change_listeners();
+
+
             console.log('activate Demo_UI');
             // and events dealing with changes to those tis.
 
@@ -183,13 +323,21 @@ class Demo_UI extends Active_HTML_Document {
 
             // Need to work on having it update the dom with value changes....
 
-            ti1.view.model.on('change', e => {
-                //console.log('ti1 change e', e);
+            // .data.model change instead.
+            //   referring to a .data.model does seem like a more explicit way to do it.
+            //     definitely looks like a good way to avoid confusion, at a small cost of more code to write.
+
+            /*
+
+            ti1.data.model.on('change', e => {
+                console.log('ti1.data.model change e', e);
+
+
 
 
-                if (e.property_name === 'value') {
+                if (e.name === 'value') {
                     if (e.value !== e.old) {
-                        ti2.value = e.value;
+                        ti2.data.model.value = e.value;
                     }
                 }
 
@@ -199,17 +347,22 @@ class Demo_UI extends Active_HTML_Document {
                 
 
             })
-            ti2.view.model.on('change', e => {
-                //console.log('ti2 change e', e);
+            ti2.data.model.on('change', e => {
+                console.log('ti2.data.model change e', e);
 
                 // 
 
-                if (e.value !== e.old) {
-                    ti1.value = e.value;
+                if (e.name === 'value') {
+                    if (e.value !== e.old) {
+                        ti1.data.model.value = e.value;
+                    }
                 }
 
                 
+
+                
             })
+            */
 
             // listen for change events.
             //   would be nice to know which change events originated from the user interacting with that specific HTML element (or ctrl???)

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

@@ -0,0 +1,585 @@
+const jsgui = require('jsgui3-client');
+const {controls, Control, mixins, Data_Object} = jsgui;
+const {dragable} = mixins;
+
+const {field} = require('obext');
+
+const {Checkbox, Date_Picker, Text_Input, Text_Field} = controls;
+
+const Active_HTML_Document = require('../../../controls/Active_HTML_Document');
+
+// 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).
+
+
+
+
+
+
+class Demo_UI extends Active_HTML_Document {
+
+
+
+    constructor(spec = {}) {
+        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.
+
+
+
+
+
+        this.data = {
+            model: new Data_Object({
+                context
+            })
+        }
+
+        //  Not enough....
+
+        //   Maybe it reconnects it with a data.model on the client that lacks that?
+
+        field(this.data.model, 'value');
+
+        // 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...?
+
+
+
+
+        context.register_control(this.data.model);
+
+
+        // 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');
+        }
+
+        //console.log('this.body', this.body);
+        //console.log('this.body.add_class', this.body.add_class);
+
+
+        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.
+
+
+
+            // context.model?
+
+            // ctrl.view.model perhaps???
+            // ctrl.data.model = context.model perhaps?
+
+
+
+
+
+
+            const window = new controls.Window({
+                context: context,
+                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({
+                context,
+
+                text: 'A',
+                data: {
+                    model: this.data.model
+
+                    // model: [this.data.model, 'value'] // this seems better
+
+                    // model_property: 'value'
+                    // model_property: 'value2'  // for example
+                }
+                //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({
+                context,
+
+                text: 'B',
+                data: {
+                    model: this.data.model
+                }
+
+
+                //label: {
+                //    text: 'A checkbox'
+                //}
+            })
+
+            window.inner.add(ti2);
+
+            this.body.add(window);
+
+
+
+            
+            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');
+
+            //field(this.data.model, 'value');
+            // and events dealing with changes to those tis.
+
+            // ti1, ti2.
+
+            // 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.
+
+            // 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....
+
+            //console.log('ti1.data.model', ti1.data.model);
+            //console.log('ti2.data.model', ti2.data.model);
+
+            console.log('ti1.data.model === ti2.data.model', ti1.data.model === ti2.data.model);
+
+            if (ti1.data.model === ti2.data.model) {
+
+            } 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_Object({context});
+                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();
+
+
+            }
+
+            // 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....
+
+            const old_activate_changes = () => {
+
+                ti1.model.on('change', e => {
+                    //console.log('ti1 change e', e);
+
+
+                    if (e.property_name === 'value') {
+                        if (e.value !== e.old) {
+                            ti2.value = e.value;
+                        }
+                    }
+
+                    // setting ti2.view.model.value even????
+                    
+
+                    
+
+                })
+                ti2.model.on('change', e => {
+                    //console.log('ti2 change e', e);
+
+                    // 
+
+                    if (e.value !== e.old) {
+                        ti1.value = e.value;
+                    }
+
+                    
+                })
+            }
+
+            
+
+            // 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.
+
+
+
+
+
+
+            });
+
+        }
+    }
+}
+
+// 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/11b) window, shared model mirrored text fields/server.js

@@ -0,0 +1,118 @@
+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,
+        // Giving it the Ctrl and disk path client js should enable to server to get the JS-bundled CSS from the file(s).
+        //  Putting the JS files through proper parsing and into a syntax tree would be best.
+
+        //'js_mode': 'debug',
+        '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');
+            }
+        });
+    })
+
+    
+
+}

package/package.json

@@ -6,16 +6,14 @@
     "@babel/core": "^7.23.2",
     "@babel/generator": "^7.23.0",
     "@babel/parser": "7.23.0",
-    "babel-plugin-transform-runtime": "^6.23.0",
-    "babel-preset-minify": "^0.5.2",
     "cookies": "^0.8.0",
     "esbuild": "^0.19.5",
     "fnl": "^0.0.30",
     "fnlfs": "^0.0.29",
-    "jsgui3-client": "^0.0.101",
-    "jsgui3-html": "^0.0.139",
-    "jsgui3-webpage": "^0.0.7",
-    "jsgui3-website": "^0.0.7",
+    "jsgui3-client": "^0.0.104",
+    "jsgui3-html": "^0.0.142",
+    "jsgui3-webpage": "^0.0.8",
+    "jsgui3-website": "^0.0.8",
     "lang-tools": "^0.0.22",
     "multiparty": "^4.2.3",
     "ncp": "^2.0.0",
@@ -40,5 +38,5 @@
     "type": "git",
     "url": "https://github.com/metabench/jsgui3-server.git"
   },
-  "version": "0.0.115"
+  "version": "0.0.117"
 }