jsgui3-server 0.0.119 → 0.0.121

package/examples/controls/5) window, grid/client.js

@@ -3,6 +3,28 @@ const {controls, Control, mixins} = jsgui;
 const {dragable} = mixins;
 
 
+// Grids: Supporting a ctrl.view.ui.composition.model may indeed be the best way in the medium term to improve controls.
+//   Changing and upgrading composition models, so that the model can be improved and tested side-by-side and swapped.
+
+// May be worth distinguishing between composition models that result in a different UI.
+//   As in the same UI could be made in different ways, such as using float elements or flex-grid.
+
+
+// Considering the currently in development more advanced control data system, involving Data_Model...
+//   May be worth soon working on the improved Data_Object...
+//   Seeing if Data_Value can get appropriate API coverage.
+//     Being able to have multiple values inside Data_Value???
+//     As in multiple named fields, that works already.
+
+
+
+
+
+
+
+
+
+
 const {Grid} = controls;
 
 const Active_HTML_Document = require('../../../controls/Active_HTML_Document');
@@ -47,6 +69,256 @@ class Demo_UI extends Active_HTML_Document {
         // .body should not be a normal function....?
         //   a getter function would be better.
 
+        // The grid is one of the more complex controls, will likely stay one of the most complex, and get more complex still.
+        //   However, some of that complexity will in the future be handled on lower levels.
+
+        // Maybe standards such as compose_from_data_model???
+        //   Or some kind of transformation system eg:
+        //     Transform data model to composition model.
+        //     get_composition_model_from_data_model ???
+
+        // ... = Composition_Model.from(data_model) perhaps....?
+        //   But it would be a composition model specific to this control.
+
+        // Defining a composition model could help..,
+        //   composition.data.model.size perhaps
+        //  So the composition would have it's own .data.model - higher level, eg the number of columns and the number of rows.
+
+
+        //  Maybe it would also have its own compositional.content.model ????
+        //    Or even 2 or more of them.
+        //  The compositional content model being a model of what its composed by...
+        //    but what about the .content???
+
+        //  Maybe just keep the .content completely the same for the moment.
+        //  Or make a Control_Content class, extending Collection.
+        //    And could choose which Collection implementation at some points in the future.
+        
+        // compositional content ????
+        // compositional model????
+
+
+
+
+
+        // .content???
+        // .ui.content???
+
+        // Any type of content that is not within the UI?
+        //  .content seems very core to it right now.
+
+        // .content.childNodes
+        // .content.child_controls
+        // .content.children
+        // .content.ch ???
+
+        // ctrl.ch
+        // .view.ui.content.nodes
+        // .view.ui.content.controls <-- :)
+        //   SEEMS LIKE A GOOD NAME
+
+        // .view.ui.content.places (would be some specific controls, maybe even spaces between existing ones, but prob not, as
+        //   a placeholder could be used)
+
+        // Content places makes a lot of sense for things like .inner
+        // window.inner
+        // window.view.ui.content.places.inner
+
+
+        // window.view.ui.content.controls definitely makes sense as the more formal longhand of what is currently .content.
+        //
+        
+        // Maybe make New_Control_Base???
+        // Control_Base_2Point0;
+
+        // Though carefully introducing these features into current controls could work.
+        //    Putting the deeper structures in place.
+
+        // ctrl.content would refer to the ctrl.view.ui.content.child_controls
+        //   And do need to pay attention to the API so there can be 2 levels of child-control like things.
+
+        // Eg a carousel could have places for each of the items in the carousel, as a type of inner content.
+
+        // ctrl.inner.content may help a lot.
+        //  ctrl.inner.content.controls perhaps.
+        //   such as in a grid, the grid cells, or a specific content control within that grid cell.
+        //   could use elements that are hidden unless they are needed / or basically but other controls inside them.
+
+        // Have maybe inner.content.place.controls?
+        //  and refer to it with inner.content.places?
+        //   inner content places makes a lot of sense.
+        //   .inner.content.places.length would help too.
+        //   .empty.inner.content.places.length ?????
+        //     Would be a convenient high-level API syntax.
+
+        // so control.empty would have to be its own type of object it seems.
+        //   Really do want a neat highest level API. Can be slightly wordy, but the sentences will not usually be very long.
+        //   
+
+        // Does seem worth getting more explicit about ctrl.view.ui.child.controls
+        //  ctrl.child.controls
+        //  ctrl.cc or ctrl.c
+
+        // And can keep .content for the moment....
+        //   Though need to work on the .inner interface.
+
+        // .view.ui.inner.places.length;
+        // .view.ui.empty.inner.places.length;
+
+        // So it would be ui that needs the 'empty' object.
+
+        // view.ui.inner.places.names for example....?
+        // view.ui.inner.places.data.model????
+        //   probably not for now (or ever?) as the inner places will be controls.
+        // And controls currently are not going within these data_models (at this level).
+
+        // view.ui.inner.places.controls does actually make sense.
+        //  view.ui.inner.places.each
+        //  each(view.ui.inner.places, ctrl????)
+        //   Maybe syntax to iterate through them as controls????
+        //  ui.inner.controls ???
+
+        // Maybe an 'inner composition model'???
+        //   As in there is a compositional model for the control itself, including spaces it provides within itself for other controls.
+        //     Usually / often that would just be the child nodes in the DOM each with their child controls.
+        //   Want to make a system where inner content can be modified.
+
+        // Eg have a row of 10 picture frames.
+        //   When adding inner content, it puts it within the frames.
+
+        // ctrl.content
+        //   (includes the picture frames)
+        // ctrl.inner.content
+        //   (includes only what is inside the picture frames)
+        //     possibly set it to the same object as the picture frame's content / inner content???
+
+        // so make inner content a standard.
+        //   also make it within .view.ui.inner.content
+        //     or view.ui.inner.controls.
+        //     the view.ui.inner.places are where these view.ui.inner.controls can go.
+
+
+        // Let's put Control_Dom within the control.view.ui.dom
+        // or control.view.ui.media.html.dom even????
+        //   May make sense in terms of further extensibility.
+        //   Could allow controls to render themselves to different media.
+        //     Would be a structure that better allows for it.
+
+        // but shortcut to .dom as currently exists.
+
+        // Does seem like a very comprehensive change to be making to the Control.
+        //   Def worth making and working on a copy of it.
+
+        // ctrl.view.ui.compositional.data.model.size = [10, 10]
+        //   That seems like a good way to express compositional data.
+
+        
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+        // view.ui.inner.places.controls perhaps ????
+
+
+
+
+
+
+
+
+
+
+
+
+
+        //  content.inner.places???
+
+
+
+
+        
+
+        
+
+
+
+
+
+
+
+    
+
+
+        
+
+
+
+        //   and the shorthand can be easily set up.
+        //   Also, make functions once this longhand is set up that do the specific and necessary things.
+        // Aim so that on a high level, we don't need to write out long things like this.
+        //   Maybe being able to translate shorthand to longhand would help too.
+        // Defining shorthands in the data models and structures of them. Functions to help with that.
+
+        
+
+
+
+
+
+        
+
+
+
+        //  but it's really child_controls.
+        //  or could call it .childNodes
+        //    it would allow for a very familiar API.
+        //    but .childNodes would be a kind of alias as well.
+
+        //    .childNodes could be a simple getter.
+
+
+
+
+
+
+
+        
+
+
+
+
+
+
+    
+
+        // ... = Grid_Composition_Model.from(data_model) perhaps....?
+        
+
+
+
+
+
+
 
 
         if (typeof this.body.add_class === 'function') {
@@ -56,7 +328,6 @@ class Demo_UI extends Active_HTML_Document {
         //console.log('this.body', this.body);
         //console.log('this.body.add_class', this.body.add_class);
 
-
         const compose = () => {
             // put 20 of them in place.
 
@@ -70,23 +341,32 @@ class Demo_UI extends Active_HTML_Document {
 
             // Have Tab_Page items inside???
 
-            // Maybe ne
+            // .data.model.size perhaps???
+            // .data.size ???
+
+            // ui.data.model.size
+            // ui.size may be the right standard here.
+            //   But keeping things in a Data_Model, inside data.model could be effective for extensability.
+            //     Keeping utility functions out of the Data_Model (data.model) itself, as it needs to be flexible in terms
+            //       of names of properties and functions internal to it. Avoids some edge cases this way.
+            // view.ui.data.toUInt8Array(); or view.ui.data.ta perhaps.
+            // or serialise(view.ui.data)
+
+            // data.model may be a kind of formality here, but do want to be able to refer to .data in a lot of cases.
+            // Then with the data.model it may need to refer to the data.model.value.
+            //   So this will inevitably slow (some) things down.
+            //   However, it will make all kinds of state syncing and recording and streaming possible.
+
+            // view.ui.data.observe perhaps ???? creates a new observable object that itself observed that data.
             
             const grid = new Grid({
                 context,
                 grid_size: [10, 10],
                 size: [200, 200]
             })
-
             window.inner.add(grid);
-
             this.body.add(window);
 
-
-
-            
-
-
         }
         if (!spec.el) {
             compose();

package/examples/controls/5) window, grid/server.js

@@ -23,6 +23,8 @@ const Server = require('../../../server');
 // At least not for the moment.
 
 
+// 
+
 
 
 

package/examples/controls/8) window, checkbox/client.js

@@ -3,68 +3,89 @@ const {controls, Control, mixins} = jsgui;
 const {dragable} = mixins;
 
 
-const {Checkbox} = controls;
+const {Checkbox, Window} = controls;
 
 const Active_HTML_Document = require('../../../controls/Active_HTML_Document');
 
-// Maybe better to include it within an Active_HTML_Document.
 
-// Is currently a decent demo of a small active control running from the server, activated on the client.
-//   This square box is really simple, and it demonstrates the principle of the code for the draggable square box not being all that complex
-//   compared to a description of it.
-
-// A container with reorderable internal draggable items could help.
-
-// would be nice to be able to have all code in 1 file...???
-//  Though the sever code should be separate.
-
-
-// Relies on extracting CSS from JS files.
-// Usage of windows should be very easy on this level.
+class Demo_UI extends Active_HTML_Document {
+    constructor(spec = {}) {
+        spec.__type_name = spec.__type_name || 'demo_ui';
 
-// Want more demos for some specific features, such as lists.
-//   Putting a bunch of different examples within a tabbed view would help.
-//   Want quite a lot to be possible without client-side js when it can be done that way.
-//     Progressive enhancement.
+        // Could give it a compositional model in the spec here. Or add to it???
+        //   Creating one would be fine here.
+
+        // And then no 'compose' function would / should need to be given at all.
+        //   More concise definitions of controls in terms of their compositions will help.
+        //   
+
+        //spec.view.ui.
+
+        /*
+
+
+        const setup_using_controls_with_specs = () => {
+            ctrl_using_compositional_model.view.ui.compositional.model = [
+                [Control, {
+                    size: [64, 128],
+                    background: {
+                        color: '#6655CC'
+                    }
+                }], 
+                [Control, {
+                    size: [64, 128],
+                    background: {
+                        color: '#DD55CC'
+                    }
+                }]
+            ];
+            
+        }
 
+        */
 
+        // Specifying things 'inner' in a Window with a compositional model.
+        //   an 'inner' property in the compositional model.
+        //   Or the 3rd property, as an array of items inside it.
+        //    That could make sense.
 
+        // Compositional models should help to make the syntax more concise.
+        //   Will also enable easier implemention of 'display modes' as selecting the view.ui.[active].compositional.model
+        //     view.ui.compositional.models ???
+        //     view.ui.alternative.compositional.models is actually clearer.
+        //       view.ui.available.compositional.models makes most sense though as it would include the current / active one.
 
 
+        
 
 
 
-class Demo_UI extends Active_HTML_Document {
-    constructor(spec = {}) {
-        spec.__type_name = spec.__type_name || 'demo_ui';
         super(spec);
-        const {context} = this;
 
-        // 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.
 
+        
+        const {context} = this;
 
-        // .body should not be a normal function....?
-        //   a getter function would be better.
+        this.view.ui.compositional.model = [
+            [Window, {
+                title: 'jsgui3-html Checkbox Control',
+                pos: [10, 10]
+            }, [
+                [Checkbox, {
+                    label: {
+                        text: 'A checkbox'
+                    }
+                }]
+            ]]
 
+        ];
 
         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);
+        // Composition model does seem like it would be a better system to use.
+
 
 
         const compose = () => {
@@ -72,47 +93,14 @@ class Demo_UI extends Active_HTML_Document {
 
             // Then how to arrange them...?
 
-
-
-
             const window = new controls.Window({
                 context: context,
                 title: 'jsgui3-html Checkbox Control',
                 pos: [10, 10]
             });
 
-            // Have Tab_Page items inside???
-
-            // 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.
-            
+            // And a context menu on the window?
+            //   Another on the background?
 
             const checkbox = new Checkbox({
                 context,
@@ -125,14 +113,9 @@ class Demo_UI extends Active_HTML_Document {
 
             this.body.add(window);
 
-
-
-            
-
-
         }
         if (!spec.el) {
-            compose();
+            //compose();
         }
     }
     activate() {
@@ -166,27 +149,6 @@ class Demo_UI extends Active_HTML_Document {
     }
 }
 
-// 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 = `
 
 * {

package/package.json

@@ -3,21 +3,21 @@
   "main": "module.js",
   "license": "MIT",
   "dependencies": {
-    "@babel/core": "^7.23.2",
-    "@babel/generator": "^7.23.0",
-    "@babel/parser": "7.23.0",
+    "@babel/core": "^7.24.6",
+    "@babel/generator": "^7.24.6",
+    "@babel/parser": "7.24.6",
     "cookies": "^0.8.0",
-    "esbuild": "^0.19.5",
-    "fnl": "^0.0.31",
-    "fnlfs": "^0.0.29",
-    "jsgui3-client": "^0.0.106",
-    "jsgui3-html": "^0.0.144",
+    "esbuild": "^0.21.4",
+    "fnl": "^0.0.36",
+    "fnlfs": "^0.0.32",
+    "jsgui3-client": "^0.0.110",
+    "jsgui3-html": "^0.0.151",
     "jsgui3-webpage": "^0.0.8",
     "jsgui3-website": "^0.0.8",
-    "lang-tools": "^0.0.25",
+    "lang-tools": "^0.0.35",
     "multiparty": "^4.2.3",
     "ncp": "^2.0.0",
-    "obext": "^0.0.28",
+    "obext": "^0.0.31",
     "rimraf": "^3.0.2",
     "stream-to-array": "^2.3.0",
     "url-parse": "^1.5.10"
@@ -38,5 +38,5 @@
     "type": "git",
     "url": "https://github.com/metabench/jsgui3-server.git"
   },
-  "version": "0.0.119"
+  "version": "0.0.121"
 }

package/publishers/http-webpage-publisher.js

@@ -188,11 +188,6 @@ class HTTP_Webpage_Publisher extends HTTP_Webpageorsite_Publisher {
             // At least want to make this setting very clear in the future.
 
 
-
-
-
-
-
             this.raise('ready', res_get_ready);
 
         })();
@@ -242,6 +237,10 @@ class HTTP_Webpage_Publisher extends HTTP_Webpageorsite_Publisher {
 
             const static_page_context = new Server_Static_Page_Context();
 
+            // Think the control needs to be some kind of HTML document control.
+            
+
+
             const ctrl = new Ctrl({
                 context: static_page_context
             });

package/resources/jsbuilder/Abstract_Single_Declaration.js

@@ -1,7 +1,7 @@
 // Defines a single constant, which is also functionality to be built.
 
 
-const {each, Evented_Class} = require('lang-mini');
+const {each, Evented_Class} = require('lang-tools');
 
 // Is this necessary, is it worth going further than Babel AST?
 //  Or JS_AST_Node?

package/resources/jsbuilder/Abstract_Single_Declaration_Sequence.js

@@ -4,7 +4,7 @@
 //  Internally, it operates in a sequence (kind of). 
 
 
-const {each, Evented_Class} = require('lang-mini');
+const {each, Evented_Class} = require('lang-tools');
 
 class Declaration_Sequence extends Evented_Class {
     constructor(spec = {}) {

package/resources/jsbuilder/JS_AST/JS_AST_Node.js

@@ -1,6 +1,6 @@
 // Do more to get the mirrored node structure set up earlier.
 
-const {each} = require('lang-mini');
+const {each} = require('lang-tools');
 const JS_AST_Node_Changing = require('./JS_AST_Node_10-Changing');
 
 const babel_node_tools = require('../babel/babel_node_tools');

package/resources/jsbuilder/JS_AST/JS_AST_Node_0-Core.js

@@ -1,4 +1,4 @@
-const {each} = require('lang-mini');
+const {each} = require('lang-tools');
 
 class JS_AST_Node_Core {
     constructor(spec = {}) {

package/resources/jsbuilder/JS_AST/JS_AST_Node_1-Babel.js

@@ -1,5 +1,5 @@
 const babel_node_tools = require('../babel/babel_node_tools');
-const {each} = require('lang-mini');
+const {each} = require('lang-tools');
 const {deep_iterate_babel_node} = babel_node_tools;
 const parser = require('@babel/parser');
 const JS_AST_Node_Core = require('./JS_AST_Node_0-Core');

package/resources/jsbuilder/JS_AST/JS_AST_Node_3.6-Basics_Callmap.js

@@ -7,7 +7,7 @@
 // Indexing at every level looks like it would be useful.
 //  so in order to get the info about how the names relate to nodes we consult indexes.
 
-const { each } = require('lang-mini');
+const { each } = require('lang-tools');
 const JS_AST_Node_Basics_Find = require('./JS_AST_Node_3.5-Basics_Find');
 const JS_AST_Node_Indexes = require('./JS_AST_Node_4.0-Index_Indexes');