jsf.js_next_gen 4.0.0-beta-9 → 4.0.0-beta-10

package/README.md

@@ -3,42 +3,42 @@
 ## What is this?
 
 This project is a work in progress for a next gen typescript based 
-reimplementation of jsf.js
+reimplementation of jsf.js/faces.js
 
 The main goal is maintainability. It omits legacy browsers
-with IE11 being the future the baseline for the moment.
+with Edge 14 and Ecmascript 2015 being the browser and ES baseline for the moment.
 
 It uses functional constructs on micro scale
 to keep the maintainability and uses 
 my own [mona-dish](https://github.com/werpu/mona-dish/) project as core framework base, to avoid
 unnecessary colliding dependencies.
 
-I might roll in MonaDish in the future
-via npm, but for now simply having it in the codebase suffices
-and prevents collisions with other frameworks.
-
 But it still uses classes modules and inheritance
 for code structuring.
 The reason for this is, I do not like the one function for all
-approach, Webpack can take care of the packaging.
+approach, especially given we have Typescript now as implementation language
+which allows a proper code structuring and modularization.
+
+Webpack can take care of the packaging.
 
-Having smaller code parts makes it easier to test certain
+Having smaller code parts, makes it easier to test certain
 aspects of the implementation.
 
-Also one additional aspect of the new implementation it has a proper
-test coverage via unit tests.
+Also one additional aspect of the new implementation: it has a proper
+test coverage via Mocha based unit tests.
 
 This was also severely lacking in my old implementation
 where I just ran a set of 20 integration tests on macro scale.
 
 ## Status
 
-ATM I am function complete, and the code
+ATM I am function in beta bugfixing stage, and the code
 can be tested (final beta stages)
-I probably will make a release before 2022.
+I probably will make a release at the same time MyFaces 4.0 
+final hits the scene.
 It has been testing in MyFaces Tobago now for a year
 and atm is being integrated into MyFaces as new
-JS codebase.
+JS/TS codebase.
 
 Addition, for the integration in MyFaces, the api level has been
 uplifted to Jakarta Faces 4.0
@@ -51,11 +51,31 @@ you simply just need to load the generated. jsf.js file which goes down to 2.3 c
 while loading faces.js will provide 4.0 compatibility
 
 For this reason the version now also in the npm package is 4.0.x
+(the pre changes code can still be reached in the 2.3 branch although
+this branch is basically legacy, given we have the SHIM layer doing both)
+
+### Special info    
+Due to a small api change, if you want to embed the 4.0 version (faces.js)
+in your code, a new attribute specified by the Faces 4.0 spec is not set
+at its proper value, *contextpath*. This attribute atm is a value expression
+which needs to be set by the loading implementation.
+
+Now if you want to provide your own embedded solution and you will have
+to set this value yourself. While my code does not use the attribute in the faces
+namespace, other libraries or the users might.
+
+If you serve the code from MyFaces 4 instead of embedding it, the value will be preset
+by the internal resource loader.
+
+The JSF 2.3 version (jsf.js) is not affected by this change, so nothing needs to be done.
+In fact the *contextpath* attribute is not present there.
+All other attributes behave the same in both versions as in the original legacy codebase.
+
 
 
 ## Usage
 
-It still is a work in progress, but for testing purposes
+It still is code complete and in bugfixing phase, for testing purposes
 it can be used (check the dist directory for builds, I consider
 stable enough for testing, or your own builds)
 
@@ -103,7 +123,7 @@ so it is gone now
 
 * pps disabled for the moment
 
-we had a special pps handling introduced in myfaces, a feature
+We had a special pps handling introduced in myfaces, a feature
 probably never used (you basically could reduce the parameters
 sent down by sending a list of pps ids). I have disabled it for the time being.
 The code still is in there for the moment, but will be dropped
@@ -114,30 +134,28 @@ if no demand arises to enable it again.
 In order to improve the maintainability I have dropped a lot
 of shim and legacy code which was needed to support old browsers.
 Since our main aim is long term maintainability there is a clear cut.
-The lowest supported browser for the moment is Internet Explorer 11 
-older browsers are now cut off. This should suffice for most if 
+The lowest supported browser for the moment is Edge 14.
+Older browsers are now cut off. This should suffice for most, if 
 not all important environments. If you still use an older browser than 
-IE11 you still can revert to the old codebase for the time being
+Edge 14 you still can revert to the old codebase for the time being
 (final cutoff point probably will come within the next few years)
 
-IE11 might be cut off in the future, depending on the business requirements 
-by the myfaces users
 
 * performance
 
 Given that we now have faster browsers and end user devices in the mobile
-area than 10 years ago, my main focus was maintainability.
+area than 10 years ago and the spec conformity has improved a lot, my main focus was maintainability.
 Maintainability and readability now comes before performance. So I sacrificed some
 of the performance to achieve it.
 Given that the most critical performance hits do not happen in the ajax area
-this is a sacrifice I can live with for the time being.
+this is a sacrifice I can live with, for the time being.
 
 * Client side i18n
 
 The client side i18n error message translations have become more
 of a liability than a feature.
 For the time being all client side errors are reported in english.
-I can reintroduce them, if there is a real demand.
-But the size and maintainability tradeoff compared to what they
+I can reintroduce them, if there is real demand.
+But the size and maintainability tradeoff, compared to what they
 bring was not worth it to keep them anymore.
  

package/dist/docs/index.html

@@ -19,36 +19,36 @@
   <h2>What is this?</h2>
 </a>
 <p>This project is a work in progress for a next gen typescript based 
-reimplementation of jsf.js</p>
+reimplementation of jsf.js/faces.js</p>
 <p>The main goal is maintainability. It omits legacy browsers
-with IE11 being the future the baseline for the moment.</p>
+with Edge 14 and Ecmascript 2015 being the browser and ES baseline for the moment.</p>
 <p>It uses functional constructs on micro scale
 to keep the maintainability and uses 
 my own <a href="https://github.com/werpu/mona-dish/">mona-dish</a> project as core framework base, to avoid
 unnecessary colliding dependencies.</p>
-<p>I might roll in MonaDish in the future
-via npm, but for now simply having it in the codebase suffices
-and prevents collisions with other frameworks.</p>
 <p>But it still uses classes modules and inheritance
 for code structuring.
 The reason for this is, I do not like the one function for all
-approach, Webpack can take care of the packaging.</p>
-<p>Having smaller code parts makes it easier to test certain
+approach, especially given we have Typescript now as implementation language
+which allows a proper code structuring and modularization.</p>
+<p>Webpack can take care of the packaging.</p>
+<p>Having smaller code parts, makes it easier to test certain
 aspects of the implementation.</p>
-<p>Also one additional aspect of the new implementation it has a proper
-test coverage via unit tests.</p>
+<p>Also one additional aspect of the new implementation: it has a proper
+test coverage via Mocha based unit tests.</p>
 <p>This was also severely lacking in my old implementation
 where I just ran a set of 20 integration tests on macro scale.</p>
 
 <a href="#status" id="status" style="color: inherit; text-decoration: none;">
   <h2>Status</h2>
 </a>
-<p>ATM I am function complete, and the code
+<p>ATM I am function in beta bugfixing stage, and the code
 can be tested (final beta stages)
-I probably will make a release before 2022.
+I probably will make a release at the same time MyFaces 4.0 
+final hits the scene.
 It has been testing in MyFaces Tobago now for a year
 and atm is being integrated into MyFaces as new
-JS codebase.</p>
+JS/TS codebase.</p>
 <p>Addition, for the integration in MyFaces, the api level has been
 uplifted to Jakarta Faces 4.0
 Note, this introduces some breaking changes, jsf jas been replaced with jakarta
@@ -57,12 +57,30 @@ so javax.faces.request becomes jakarta.faces.request</p>
 <p>Note, a shim layer for backwards compatibility has been provided
 you simply just need to load the generated. jsf.js file which goes down to 2.3 compatibility level
 while loading faces.js will provide 4.0 compatibility</p>
-<p>For this reason the version now also in the npm package is 4.0.x</p>
+<p>For this reason the version now also in the npm package is 4.0.x
+(the pre changes code can still be reached in the 2.3 branch although
+this branch is basically legacy, given we have the SHIM layer doing both)</p>
+
+<a href="#special-info" id="special-info" style="color: inherit; text-decoration: none;">
+  <h3>Special info</h3>
+</a>
+<p>Due to a small api change, if you want to embed the 4.0 version (faces.js)
+in your code, a new attribute specified by the Faces 4.0 spec is not set
+at its proper value, <em>contextpath</em>. This attribute atm is a value expression
+which needs to be set by the loading implementation.</p>
+<p>Now if you want to provide your own embedded solution and you will have
+to set this value yourself. While my code does not use the attribute in the faces
+namespace, other libraries or the users might.</p>
+<p>If you serve the code from MyFaces 4 instead of embedding it, the value will be preset
+by the internal resource loader.</p>
+<p>The JSF 2.3 version (jsf.js) is not affected by this change, so nothing needs to be done.
+In fact the <em>contextpath</em> attribute is not present there.
+All other attributes behave the same in both versions as in the original legacy codebase.</p>
 
 <a href="#usage" id="usage" style="color: inherit; text-decoration: none;">
   <h2>Usage</h2>
 </a>
-<p>It still is a work in progress, but for testing purposes
+<p>It still is code complete and in bugfixing phase, for testing purposes
 it can be used (check the dist directory for builds, I consider
 stable enough for testing, or your own builds)</p>
 
@@ -118,7 +136,7 @@ so it is gone now</p>
 <li><p>pps disabled for the moment</p>
 </li>
 </ul>
-<p>we had a special pps handling introduced in myfaces, a feature
+<p>We had a special pps handling introduced in myfaces, a feature
 probably never used (you basically could reduce the parameters
 sent down by sending a list of pps ids). I have disabled it for the time being.
 The code still is in there for the moment, but will be dropped
@@ -129,30 +147,28 @@ if no demand arises to enable it again.</p>
 <p>In order to improve the maintainability I have dropped a lot
 of shim and legacy code which was needed to support old browsers.
 Since our main aim is long term maintainability there is a clear cut.
-The lowest supported browser for the moment is Internet Explorer 11 
-older browsers are now cut off. This should suffice for most if 
+The lowest supported browser for the moment is Edge 14.
+Older browsers are now cut off. This should suffice for most, if 
 not all important environments. If you still use an older browser than 
-IE11 you still can revert to the old codebase for the time being
+Edge 14 you still can revert to the old codebase for the time being
 (final cutoff point probably will come within the next few years)</p>
-<p>IE11 might be cut off in the future, depending on the business requirements 
-by the myfaces users</p>
 <ul>
 <li>performance</li>
 </ul>
 <p>Given that we now have faster browsers and end user devices in the mobile
-area than 10 years ago, my main focus was maintainability.
+area than 10 years ago and the spec conformity has improved a lot, my main focus was maintainability.
 Maintainability and readability now comes before performance. So I sacrificed some
 of the performance to achieve it.
 Given that the most critical performance hits do not happen in the ajax area
-this is a sacrifice I can live with for the time being.</p>
+this is a sacrifice I can live with, for the time being.</p>
 <ul>
 <li>Client side i18n</li>
 </ul>
 <p>The client side i18n error message translations have become more
 of a liability than a feature.
 For the time being all client side errors are reported in english.
-I can reintroduce them, if there is a real demand.
-But the size and maintainability tradeoff compared to what they
+I can reintroduce them, if there is real demand.
+But the size and maintainability tradeoff, compared to what they
 bring was not worth it to keep them anymore.</p>
 </div></div>
 <div class="col-4 col-menu menu-sticky-wrap menu-highlight">

package/dist/window/faces-development.js

@@ -35,7 +35,7 @@ var __awaiter = (this && this.__awaiter) || function (thisArg, _arguments, P, ge
     });
 };
 Object.defineProperty(exports, "__esModule", ({ value: true }));
-exports.DQ = exports.DomQueryCollector = exports.DomQuery = exports.ElementAttribute = void 0;
+exports.DQ = exports.DomQueryCollector = exports.DomQuery = exports.Style = exports.ElementAttribute = void 0;
 const Monad_1 = __webpack_require__(/*! ./Monad */ "./node_modules/mona-dish/src/main/typescript/Monad.ts");
 const Stream_1 = __webpack_require__(/*! ./Stream */ "./node_modules/mona-dish/src/main/typescript/Stream.ts");
 const SourcesCollectors_1 = __webpack_require__(/*! ./SourcesCollectors */ "./node_modules/mona-dish/src/main/typescript/SourcesCollectors.ts");
@@ -69,13 +69,36 @@ var Submittables;
 function waitUntilDom(root, condition, options = { attributes: true, childList: true, subtree: true, timeout: 500, interval: 100 }) {
     const ret = new Promise((success, error) => {
         const MUT_ERROR = new Error("Mutation observer timeout");
-        if ('undefined' != typeof window.MutationObserver) {
+        //we do the same but for now ignore the options on the dom query
+        //we cannot use absent here, because the condition might search for an absent element
+        function findElement(root, condition) {
+            let found = null;
+            if (condition(root)) {
+                return root;
+            }
+            if (options.childList) {
+                found = (condition(root)) ? root : root.childNodes.first(condition).value.value;
+            }
+            else if (options.subtree) {
+                found = (condition(root)) ? root : root.querySelectorAll(" * ").first(condition).value;
+            }
+            else {
+                found = (condition(root)) ? root : null;
+            }
+            return found;
+        }
+        let foundElement = root;
+        if (foundElement = findElement(foundElement, condition)) {
+            success(new DomQuery(foundElement));
+            return;
+        }
+        if ('undefined' != typeof MutationObserver) {
             const mutTimeout = setTimeout(() => {
                 return error(MUT_ERROR);
             }, options.timeout);
             const callback = (mutationList, observer) => {
                 const found = new DomQuery(mutationList.map((mut) => mut.target)).first(condition);
-                if (found.isPresent()) {
+                if (found) {
                     clearTimeout(mutTimeout);
                     success(found);
                 }
@@ -90,19 +113,9 @@ function waitUntilDom(root, condition, options = { attributes: true, childList:
             });
         }
         else { //fallback for legacy browsers without mutation observer
-            //we do the same but for now ignore the options on the dom query
             let interval = setInterval(() => {
-                let found = null;
-                if (options.childList) {
-                    found = (condition(root)) ? root : root.childNodes.first(condition);
-                }
-                else if (options.subtree) {
-                    found = (condition(root)) ? root : root.querySelectorAll(" * ").first(condition);
-                }
-                else {
-                    found = (condition(root)) ? root : DomQuery.absent;
-                }
-                if (found.isPresent()) {
+                let found = findElement(root, condition);
+                if (found) {
                     if (timeout) {
                         clearTimeout(timeout);
                         clearInterval(interval);
@@ -150,6 +163,34 @@ class ElementAttribute extends Monad_1.ValueEmbedder {
     }
 }
 exports.ElementAttribute = ElementAttribute;
+class Style extends Monad_1.ValueEmbedder {
+    constructor(element, name, defaultVal = null) {
+        super(element, name);
+        this.element = element;
+        this.name = name;
+        this.defaultVal = defaultVal;
+    }
+    get value() {
+        let val = this.element.values;
+        if (!val.length) {
+            return this.defaultVal;
+        }
+        return val[0].style[this.name];
+    }
+    set value(value) {
+        let val = this.element.values;
+        for (let cnt = 0; cnt < val.length; cnt++) {
+            val[cnt].style[this.name] = value;
+        }
+    }
+    getClass() {
+        return ElementAttribute;
+    }
+    static fromNullable(value, valueKey = "value") {
+        return new ElementAttribute(value, valueKey);
+    }
+}
+exports.Style = Style;
 /**
  * small helper for the specialized jsf case
  * @param src
@@ -648,6 +689,9 @@ class DomQuery {
     attr(attr, defaultValue = null) {
         return new ElementAttribute(this, attr, defaultValue);
     }
+    style(cssProperty, defaultValue = null) {
+        return new Style(this, cssProperty, defaultValue);
+    }
     /**
      * hasclass, checks for an existing class in the class attributes
      *
@@ -896,7 +940,6 @@ class DomQuery {
         if (charSet) {
             xhr.setRequestHeader("Content-Type", "application/x-javascript; charset:" + charSet);
         }
-        xhr.send(null);
         xhr.onload = (responseData) => {
             //defer also means we have to process after the ajax response
             //has been processed
@@ -917,6 +960,7 @@ class DomQuery {
             throw Error(data);
         };
         //since we are synchronous we do it after not with onReadyStateChange
+        xhr.send(null);
         return this;
     }
     insertAfter(...toInsertParams) {
@@ -1146,7 +1190,7 @@ class DomQuery {
             }
         }
         catch (e) {
-            if (window.console && window.console.error) {
+            if (console && console.error) {
                 //not sure if we
                 //should use our standard
                 //error mechanisms here