jsgui3-server 0.0.98 → 0.0.100

package/publishers/helpers/assigners/static-uncompressed-response-buffers/Single_Control_Webpage_Server_Static_Uncompressed_Response_Buffers_Assigner.js

@@ -0,0 +1,104 @@
+
+
+// Making such specific classes with such long names seems kind of silly, but will help to keep the higher level code
+//   both explicit and easy to follow.
+
+// These classes will do specific things, to specific things (in specific ways)
+
+// Basically middleware that the app dev should not need to pay much attention to usually.
+
+
+
+
+// And likely will have some other class (system), maybe assigners, to set the routes on the server / server router.
+//   Or within the website resource???
+
+// So everything (main) that the server does will be done using various interchangable classes.
+//   Some classes will cover some very specific use cases.
+
+
+
+
+const Assigner = require('../Assigner');
+
+const {is_array} = require('lang-tools');
+
+// And will have some very or less specific assigners for some other things.
+//   Like the compressed (text?) response headers.
+
+
+
+
+class Single_Control_Webpage_Server_Static_Uncompressed_Response_Buffers_Assigner extends Assigner {
+
+    constructor(spec = {}) {
+        super(spec);
+    }
+
+    // assign to bundle....
+    //  or array would be better.
+
+    // assign to (bundle) items in array.
+
+    async assign(arr_bundled_items) {
+        // go through them....
+
+        // Maybe check that the correct items are in the bundle.
+
+        // Perhaps check for 1 of each js, css, html
+        //   And could use a specific other class to assign these.
+
+        //   Should be OK to make classes for really specific things.
+        //     At this part of the system / API, it's not necessary / important to limit complexity in that way.
+
+        // The goal is to provide a very simple high level interface. Powerful too.
+
+        // Could assign a static_route property to the items in the bundles.
+
+
+
+
+
+        if (is_array(arr_bundled_items)) {
+
+            for (const item of arr_bundled_items) {
+                //console.log('item', item);
+
+                const {type} = item;
+
+                // And need to create the uncompressed response buffer.
+
+                // // response_buffers.identity I think....
+
+                if (item.text) {
+                    const buf_identity_response = Buffer.from(item.text, 'utf-8');
+
+                    item.response_buffers = item.response_buffers || {};
+                    item.response_buffers.identity = buf_identity_response;
+                } else {
+
+                }
+
+                
+
+                //console.trace();
+                //throw 'stop';
+            }
+
+        } else {
+            console.trace();
+            throw 'stop';
+        }
+
+
+
+
+    }
+
+
+}
+
+
+module.exports = Single_Control_Webpage_Server_Static_Uncompressed_Response_Buffers_Assigner;
+
+

package/publishers/helpers/preparers/static/bundle/Ready_To_Serve_Preparer.js

@@ -0,0 +1,19 @@
+
+
+class Static_Bundle_Ready_To_Serve_Preparer {
+    constructor(spec) {
+
+    }
+    prepare(bundle) {
+
+
+        // Maybe only very specific code cases.
+
+
+        
+
+    }
+}
+
+
+module.exports = Static_Bundle_Ready_To_Serve_Preparer;

package/publishers/helpers/preparers/static/bundle/Static_Routes_Responses_Webpage_Bundle_Preparer.js

@@ -0,0 +1,45 @@
+const Single_Control_Webpage_Server_Static_Compressed_Response_Buffers_Assigner = require('../../../assigners/static-compressed-response-buffers/Single_Control_Webpage_Server_Static_Compressed_Response_Buffers_Assigner');
+const Single_Control_Webpage_Server_Static_Uncompressed_Response_Buffers_Assigner = require('../../../assigners/static-uncompressed-response-buffers/Single_Control_Webpage_Server_Static_Uncompressed_Response_Buffers_Assigner');
+
+const Single_Control_Webpage_Server_Static_Headers_Assigner = require('../../../assigners/static-headers/Single_Control_Webpage_Server_Static_Headers_Assigner');
+
+const Single_Control_Webpage_Server_Static_Routes_Assigner = require('../../../assigners/static-routes/Single_Control_Webpage_Server_Static_Routes_Assigner');
+
+
+class Static_Routes_Responses_Webpage_Bundle_Preparer {
+
+    constructor(spec = {}) {
+
+        // Probably should be able to operate in debug mode.
+        //   Not minifying the js, and including the js debug symbols / map as well.
+
+        // But something else prepares the bundle....
+
+        //if (spec.debug !== undefined) this.debug = spec.debug;
+
+        this.routes_assigner = new Single_Control_Webpage_Server_Static_Routes_Assigner();
+
+        // And the uncompressed response buffer(s) assigner....?
+
+        this.uncompressed_response_buffers_assigner = new Single_Control_Webpage_Server_Static_Uncompressed_Response_Buffers_Assigner();
+        this.compressed_response_buffers_assigner = new Single_Control_Webpage_Server_Static_Compressed_Response_Buffers_Assigner();
+        this.headers_assigner = new Single_Control_Webpage_Server_Static_Headers_Assigner();
+
+
+    }
+    async prepare(bundle) {
+        const {routes_assigner, uncompressed_response_buffers_assigner, compressed_response_buffers_assigner, headers_assigner} = this;
+
+        const arr_bundle_items = bundle._arr;
+
+        await routes_assigner.assign(arr_bundle_items);
+        await uncompressed_response_buffers_assigner.assign(arr_bundle_items);
+        await compressed_response_buffers_assigner.assign(arr_bundle_items);
+        await headers_assigner.assign(arr_bundle_items);
+
+        return bundle;
+
+    }
+}
+
+module.exports = Static_Routes_Responses_Webpage_Bundle_Preparer;

package/publishers/http-webpage-publisher.js

@@ -6,22 +6,42 @@
 
 
 
+// Later on will probably make some new very specific classes to encapsulate things the HTTP_Webpage_Publisher does.
+
+// Maybe have the publisher use Preparer or other (slightly) more specific classes.
+
+
+
+
+// The publisher will need to do a few things / have some things done, but make it rely on the helpers
+//   and bundlers and extractors.
+
+// The helpers maybe could call the bundlers and extractors.
+
+
+
+
+
+
 
 
 // A publisher handles HTTP requests.
 
 // This is going to take over some of the responsibilities of the old website resource, which was unfocused code that was
 //  doing some of the main / most important parts of serving the website.
-
+const jsgui_client = require('jsgui3-client');
 
 const HTTP_Publisher = require('./http-publisher');
+const Server_Static_Page_Context = require('../static-page-context');
+
+const HTTP_Webpageorsite_Publisher = require('./http-webpageorsite-publisher');
 const {obs} = require('fnl');
 
 // May want / need to more carefully and specifically define APIs.
 // It's nice to have classes for specific things like this, but need to make them do what is needed.
 //  Maybe get a 'Website' object or control ready to be served.
 //  
-
+const Static_Routes_Responses_Webpage_Bundle_Preparer = require('./helpers/preparers/static/bundle/Static_Routes_Responses_Webpage_Bundle_Preparer');
 
 
 
@@ -67,7 +87,18 @@ obs((next, complete, error) => {
 // Should include or use various other publishers, such as html or js?
 
 
-class HTTP_Webpage_Publisher extends HTTP_Publisher {
+// HTTP_Static_Webpage_Publisher perhaps....
+
+
+// Also have various Authorisers ...
+// Have Authenticators ...
+
+
+
+
+
+
+class HTTP_Webpage_Publisher extends HTTP_Webpageorsite_Publisher {
 
     // Website generally serves JS from a single address.
     //  Webpage could have its specific JS.
@@ -95,6 +126,16 @@ class HTTP_Webpage_Publisher extends HTTP_Publisher {
             }
         });
 
+
+        
+
+        // But like the website publisher, this would need to bundle the page (JS, CSS, maybe more).
+        //   Consider that an SPA may reference images. May not exactly be one page in some ways.
+
+
+
+
+
         // Probably best to come up with a bundle here, or at an early stage.
 
         // .prepare_bundle?
@@ -108,13 +149,448 @@ class HTTP_Webpage_Publisher extends HTTP_Publisher {
 
         // Bundling and compiling web content seems like a better thing to get working before serving (or attempting to serve) it.
         // .build?
+
+        /*
         setTimeout(() => {
+
+
             this.raise('ready');
         }, 0);
 
+        */
+
+        this.static_routes_responses_webpage_bundle_preparer = new Static_Routes_Responses_Webpage_Bundle_Preparer();
+
+        (async() => {
+
+            const res_get_ready = await this.get_ready();
+
+
+            // Is the HTML to be static or regenerated on page calls?
+            //   Want an easy way to specify it.
+
+
+
+            // Then set things (a single static route???) up for the webpage.
+            //    Be very explicit with classes to do specific things like this so they will be easier to find and change.
+
+            //  Should render the webpage (once)
+            //    Maybe use a class on a higher level to choose this important rendering / caching setting.
+
+            //  Maybe the server could render multiple times over a few minutes before deciding it's not going to change.
+
+            // Though telling the server it's static would help in some / many cases.
+            //   Have it as a sensible default depending on the situation.
+
+            // Could even look at the controls to see if anything is non-static.
+            //   Or mark things somehow.
+
+            // At least want to make this setting very clear in the future.
+
+
+
+
+
+
+
+            this.raise('ready', res_get_ready);
+
+        })();
+
+    }
+
+    async get_ready() {
+        //await super.get_ready();
+
+        const {static_routes_responses_webpage_bundle_preparer} = this;
+
+
+        // Its a bundle....
+        const webpage_or_website_res_get_ready = await super.get_ready();
+
+        //console.log('webpage_or_website_res_get_ready', webpage_or_website_res_get_ready);
+
+        
+
+
+        const render_webpage = async () => {
+
+            // Activate it or not....   As in serve active JSGUI control content. HTML ready to be activated on the client.
+
+            // .active();
+            //   Generally would want that as standard.
+
+            // Need to be very clear about generating active content on the server side.
+            //   Ready to be activated on the client-side.
+            //     Though could possibly activate using CSS classes.
+
+
+
+
+            // Probably best to make a Server_Page_Context here.
+            // Server_Static_Page_Context perhaps.
+
+
+
+            // Maybe a class to render the single page into the bundle?
+            //   Maybe only worth doing when there become (many) more options and divisions seem clearer.
+
+            const {webpage} = this;
+            const Ctrl = webpage.content;
+
+            // In business activating it with the page context.
+
+            const static_page_context = new Server_Static_Page_Context();
+
+            const ctrl = new Ctrl({
+                context: static_page_context
+            });
+
+            // Webpage_CSS_JS_HTML_Bundle_Ready_To_Serve_Preparer
+
+            if (ctrl.head && ctrl.body) {
+
+
+                    // Create the CSS link control
+
+                //console.log('jsgui_client.controls', jsgui_client.controls);
+
+                //console.log('jsgui_client.controls', Object.keys(jsgui_client.controls));
+
+                const ctrl_css_link = new jsgui_client.controls.link({
+                    context: static_page_context
+                });
+                ctrl_css_link.dom.attributes.rel = 'stylesheet';
+                ctrl_css_link.dom.attributes.href = '/css/css.css';
+
+                ctrl.head.add(ctrl_css_link);
+
+
+                // Then add the JS Script ref (with href) to the (end of the) body.
+
+                // Content_Incorporator perhaps???
+                // Bundle_Content_Incorporator?
+
+                // Will be worth making classes to do this when there is more variety of settings and operations.
+
+                const ctrl_js_script_link = new jsgui_client.controls.script({
+                    context: static_page_context
+                });
+
+                ctrl_js_script_link.dom.attributes.src = '/js/js.js';
+
+                ctrl.body.add(ctrl_js_script_link);
+
+                // <script src="myscripts.js"></script>
+
+
+                //console.log('!!ctrl.head', !!ctrl.head);
+                //console.log('!!ctrl.body', !!ctrl.body);
+
+                // add the css ref to the head, then the script ref to the body.
+
+                // ctrl.body????
+
+                // or add it to the body....
+                // ctrl.head.add(new jsgui.script(...))
+
+
+                // Adding script references...?
+
+                // or .activate with it working on the server...?
+
+
+
+                // Could have settings which determine which HTML elements get activated into controls, which don't.
+                ctrl.active();
+
+
+
+                // .active should do enough I think....
+
+                // Server_Page_Context being the context of a publisher doing a one-time static rendering of a only page's HTML
+                //   Does seem like the Servier_Page_Context will be needed for this to work properly.
+                //   Want to hide some details that won't need changing from the top level API.
+                //     All kinds of things like page contexts will help in the background, they should be there to make
+                //       things easier.
+
+
+
+
+
+
+                //   do we need a Server_Page_Context first?
+
+                const html = await ctrl.all_html_render();
+
+                // Produces the HTML fairly well here....
+
+
+                // Want to provide these as static resources to the server / router.
+                //  The publisher itself should not need to handle HTTP requests each time.
+                //  Keep the option for that though, it may help with some systems, more dynamic, not static responses.
+
+                // Focus a lot on ease of use to set up servers with sensible and powerful defaults.
+                //   Also not requiring a specific directory or project structure.
+                //   Serving a simple app with a simple JS file.
+
+
+
+
+
+
+
+
+                //console.log('html', html);
+
+                //console.trace();
+                //throw 'NYI';
+
+                return html;
+
+
+
+            } else {
+                console.trace();
+                throw 'NYI';
+            }
+            
+        }
+
+        // Maybe a Webpage_Rendering_Preparer could do this even?
+
+        // Webpage_Renderer even
+        //   And it could render jsx, (other react?), 
+
+
+        const webpage_html = await render_webpage();
+
+        const o_webpage_html = {
+            type: 'HTML',
+            extension: 'html',
+            text: webpage_html
+        }
+
+        webpage_or_website_res_get_ready.push(o_webpage_html);
+
+        //console.log('webpage_or_website_res_get_ready._arr.length', webpage_or_website_res_get_ready._arr.length);
+
+
+        await static_routes_responses_webpage_bundle_preparer.prepare(webpage_or_website_res_get_ready);
+
+        // Then publish it to the router...?
+        //   server.serve_prepared_static_routes_bundle ?????
+        return webpage_or_website_res_get_ready;
+
+
+
+        // But then the bundle with static routes should be given / provided to the server.
+        //   Would be nice to end the responsibility of the Publisher once the final prepared bundle with static
+        //   routes and static content (compressed in different ways, uncompressed buffer there too) and have the 
+        //   Server or Server Router do the rest.
+
+        // Improve handling of prepared to serve (HTTP response) bundles, making it easy to tell the server to use them.
+
+        // Maybe make a more advanced HTTP_Responder baked into the server.
+        //   Or an interchagable class that does it, used within the server.
+
+
+
+
+
+
+
+
+
+        // Then send it off to the final stage bundler / Final_Stage_Bundle_Preparer_That_Prepares_Static_Routes_Responses
+
+        // Some very long and explicit class names seem appropriate.
+        
+        // Final_Stage_Webpage_Bundle_Preparer_Of_Static_Routes_Responses
+
+        // Static_Routes_Responses_Webpage_Bundle_Preparer
+        //   That should be fine doing the very last part.
+
+        // But then another component to assign these static routes to the router?
+        //   Or maybe that's easy enough to do with a function call (or a few).
+
+        // Prepared_Responses_Cache???
+
+        // Don't want to make big changes to the router and server itself right now.
+        //   Though an extra function (or a few) could help within Server_Router.
+        //     Or not the router, but do it here in the handle_http function call.
+        //       With the router just routing those URLs here.
+
+        // Does seem better architecture for the publisher to hand the responsibility off to some (other) server component.
+
+
+
+
+
+
+        
+
+        // then add that webpage html to the bundle.
+
+
+
+        // Then add a new static HTML item to the bundle.
+
+
+
+        //console.log('webpage_html', webpage_html);
+
+
+        // Add it to the bundle
+        // Prepare the bundle to serve with static routes
+        // Give the prepared bundle to the server (router).
+
+        // Then see it running small and increasingly large apps.
+
+
+
+
+
+        // Add the webpage HTML to the bundle.
+        //   Then call the static routes assigner on the array in the bundle  (._arr)
+
+        // Then get server_static_route_prepared_responses.
+
+        // Then maybe some other class assigns these prepared responses to the server or server router.
+
+        // When preparing static responses, should prepare them gzipped, brotlied, and uncompressed.
+        //   Though will (always?) use UTF8, will make that explicit and allow for other encoding types.
+
+
+
+        // Preparer or Bundle_Perparer could be a final / further stage.
+        //   And would itself use other classes internally with very specific functionality
+
+
+
+
+
+
+        // Then it will be about assembling the routing instructions.
+
+        // So then different conventions / systems could be used to assign static routes.
+        //   And very clear in the code what is going on (through use of very explicit and specific class / classes that do this).
+
+
+        // Server_Static_Routes_Assigner perhaps.
+        //  subclass:
+        // Single_Control_Webpage_Server_Static_Routes_Assigner
+
+        // Assigning the static routes with a class makes sense, could hard-code things here but want better options that can be interchanged
+        //   and modified and improved separately.
+
+
+
+        // Bundle_To_Serve_Statically_Preparer
+        //  .prepare(bundle)
+
+        // Really simple function calling syntax, really clear responsibilities, and if any wind up not being used then that will be 
+        //   fine.
+
+
+
+
+
+        // Server_Prepared_Static_Routes_Responses
+
+
+        // publishers/publishing-tools perhaps....?
+
+        // Or create a bundle that then includes the HTML document.
+        //   Could add headers and compressed buffers (to write to responses) to the existing bundle items.
+        
+
+        // The system as a whole here is not massively complex, but moderately.
+        //   Changable minute details will be finite in this implementation but infinite when it comes to extending and
+        //     making subcategories especially in terms of how things are done internally to that system.
+
+
+
+
+
+
+
+
+
+        //console.trace();
+        //throw 'NYI';
+
+
+
+
+        // Probably need to call a preparer???
+        //   Need (something to) server the static things, but also if the rendered HTML itself is static, having that pre-rendered
+        //   would be best.
+
+
+        // Should make the rendering more abstract (less specific code in Server itself) and be very clear indeed what the classes
+        //   do by naming them well.
+
+        // But the publisher itself does handle the HTTP.
+        //   That possibly should not always be the case.
+
+
+        // Website_Static_Responses_Preparer
+        // Webpage_Static_Responses_Preparer
+
+
+
+        // HTTP_Response_Preparer could be a useful class and one to subclass from.
+
+        // HTTP_Static_Response_Preparer
+
+
+
+
+
+
+
+
+        // Or maybe insert references to the bundled content appropriately into the HTML.
+
+        // At the end of the body may be best for the JS???
+        //   Want nice options for this.
+
+        // Then here we need to create static HTML....
+
+
+
     }
+
+    // The publisher should not (always / usually) handle the HTTP calls.
+    //   It may be worth having architecture that allows for it when publishing dynamic content.
+    //   When publishing static content it's better to pass that static content onto the server. (specific static content for specific routes / urls)
+    //    Maybe dict or map lookup is better for those static content URLs.
+
+
+
+
+
+
     handle_http(req, res) {
 
+
+        // Don't (automatically) connect this function.
+
+        console.log('HTTP_Webpage_Publisher handle_http');
+        console.log('req.url', req.url);
+
+        // Should not (need to?) handle the HTTP here.
+
+        // Ideally the Webpage Publisher will have already bundled all the static files.
+
+
+        // HTTP_Webpage_Request_Handler perhaps?
+
+
+
+
+
         // Is the webpage rendered?
         // Does the webpage require rendering?
         //   Seems like the main question to ask here.
@@ -133,6 +609,10 @@ class HTTP_Webpage_Publisher extends HTTP_Publisher {
 
         // Could get info on what needs to be bundled from the webpage object itself.
         //  A Webpage objects could have 'requirements', or 'build requirements'.
+        //    If such things are needed, then make classes for them.
+
+
+