Great then we can axe ie11 for good for now, I wont test until I really have the time to do it.
Btw. one feature we have now is that we now have a brotli and gzip build. As far as I can see atm we do not serve those files upon request. We probably should add this feature to our resource loader, given we serve those files from our jars ourselves. This reduces the filesize sent over the net significantly and it is a feature which comes barebones with the browsers with no extra effort. 100K reduced but raw js compared to 21k brotli. Mapping file loading already works here locally. I fixed this today. I can see the ts files and debug into them when I load the final jsf.js files. Werner Am Fr., 23. Sept. 2022 um 12:27 Uhr schrieb Udo Schnurpfeil < [email protected]>: > Short: no IE11 support > > Details: > > This jsf.js impl ist only relevant for Tobago 5 and higher. > > Since Tobago 5 we use Bootstrap 5. Bootstrap 5 has no support for IE11. => > Tobago 5 also has no support for IE11. > > Udo > Am 23.09.22 um 12:10 schrieb Werner Punz: > > mhh... I will replace it for now completely which cuts down on the code, > we still can readd the old codebase with a switch if the need arises, if > that is ok with everyone. > I am not just sure wheter the code still works on IE11, have not tested > the codebase for a long time with it. > I probably need to run a set of tests to see that. Either way, lets go for > a full replacement for now, we still can readd it. > I will run ie11 as baseline tests next week. Also expect my commit/push on > the myfaces codebase next week. > > Re Ie11 Tobago guys, have you run tests regarding it? Or are we going to > skip this one as baseline? > > > Werner > > > Am Fr., 23. Sept. 2022 um 10:40 Uhr schrieb Thomas Andraschko < > [email protected]>: > >> TBH i would not add it in older versions, maybe just 2.3-next >> >> 2.3 is stable >> 3.0 is the exact same codebase as 2.3 and isnt really used in public, 99% >> of the people just skip JakartaEE9 >> >> >> Am Fr., 23. Sept. 2022 um 10:35 Uhr schrieb Udo Schnurpfeil < >> [email protected]>: >> >>> I think: >>> >>> for version 4.0: replace it >>> >>> for version 2.3, 2.3-next, 3.0: it should be configurable - of course >>> only if it is to be integrated there at all >>> >>> Udo >>> Am 23.09.22 um 09:56 schrieb Werner Punz: >>> >>> Hi I would need an answer, to my original question, now that I have >>> picked up the work on MyFaces again. >>> Are we going to completely replace the scripts or at allow some kind of >>> dual mode where users can switch between old and new >>> for some period of time? >>> >>> Werner >>> >>> >>> >>> Am Do., 22. Sept. 2022 um 12:50 Uhr schrieb Werner Punz < >>> [email protected]>: >>> >>>> Re Myfaces 2.3, not sure, the idea of the new codebase was to get a >>>> cleaner code and get rid of all this dead old browser legacy support >>>> which messed up the readability with tons of fallbacks for everything >>>> we did) >>>> >>>> So that we can have a cleaner more maintainable codebase to move >>>> forward onwards. >>>> If you want to integrate it into a stable version then I would make a >>>> fork or switch the codebases via context param. >>>> Neither really is a solution. I would recommend for Tobago to leave it >>>> in for now until the baseline is higher than 2.3! >>>> It is the same codebase in the long run anyway. >>>> >>>> >>>> Am Do., 22. Sept. 2022 um 12:46 Uhr schrieb Werner Punz < >>>> [email protected]>: >>>> >>>>> Hi sorry for being silent for so long. I was on vacation last week as >>>>> announced but I have picked up work again. >>>>> Following I was basically spending this week, to fix a ton of smaller >>>>> issues I ran along in mona-dish and the typescript codebase. >>>>> Also I did some code improvement in the jsf.js codebase to get rid of >>>>> some legacy code which is covered in a better way now regarding >>>>> file inputs. >>>>> Also the github project which is my main workbench for the scripts now >>>>> integrates the streams and query lib on source level so that the code maps >>>>> are down to the last and only dependency reachable as well. (see >>>>> https://github.com/werpu/jsfs_js_ts for the latest codebase before it >>>>> makes it into myfaces) >>>>> >>>>> I will now pick up the integration into myfaces again. >>>>> Question is: >>>>> Do we still want to have the old scripts reachable or not? >>>>> If not we can drop a ton of custom code in the resource loaders, >>>>> because all the compressed, uncompressed single file stuff is not needed >>>>> anymore. >>>>> The new implementation can provide sourcemaps, so the users can always >>>>> reach the sources for debugging. >>>>> A simple development/production flag should be enough to serve the >>>>> files mangled or unmangled, subsequent source map requests done by the >>>>> browser can do the rest. >>>>> >>>>> Also one advantage of the new codebase is that files with gzip and >>>>> brotli compression are generated with the rest of the build and the server >>>>> can serve those as well >>>>> reducing bandwidth. >>>>> >>>>> Downside is if we do not provide the old scripts then some legacy >>>>> browsers won't have a working impl anymore. >>>>> >>>>> Werner >>>>> >>>>> >>>>> >>>>> Am Fr., 16. Sept. 2022 um 10:39 Uhr schrieb Udo Schnurpfeil < >>>>> [email protected]>: >>>>> >>>>>> Tobago 4 works with the jsf.js from MyFaces only with several >>>>>> modifications. >>>>>> >>>>>> Tobago 5 was migrated to use Werner's Typescript implementation. It >>>>>> works without patches 😁. This version was never released with MyFaces, >>>>>> and >>>>>> you don't want, because it's stable (I think that is fine). But the >>>>>> consequence is: there is no MyFaces 2.3 based application server working >>>>>> with Tobago when we remove the jsf.js from Tobago. >>>>>> Am 16.09.22 um 10:21 schrieb Thomas Andraschko: >>>>>> >>>>>> Isnt that maybe outdated? >>>>>> the last fixes on our JS was in 2018: >>>>>> https://github.com/apache/myfaces/commits/2.3.x/api/src/main/javascript/META-INF/resources/myfaces >>>>>> >>>>>> Am Fr., 16. Sept. 2022 um 10:18 Uhr schrieb Udo Schnurpfeil < >>>>>> [email protected]>: >>>>>> >>>>>>> The reason is, that problems in the jsf.js often breaks Tobago to be >>>>>>> unusable, and some application servers tent to need much time to update >>>>>>> there external libs (e.g. MyFaces) and some users of Tobago need much >>>>>>> time >>>>>>> to update there application servers. I know the solution is not pretty, >>>>>>> but >>>>>>> it fixes real world problems. I've spent too much time in the last >>>>>>> years to >>>>>>> solve this category of problems, I'm exhausted. >>>>>>> Am 16.09.22 um 09:57 schrieb Thomas Andraschko: >>>>>>> >>>>>>> I always wonder why you need it in tobago? doesnt you just reuse >>>>>>> jsf.js from the impl? >>>>>>> >>>>>>> If we really really really need it, we could create something like a >>>>>>> myfaces-js repo and create a master and 2.3 branch there + release it in >>>>>>> NPM. >>>>>>> >>>>>>> Otherwise i would just like to have the source in the myfaces-core >>>>>>> master branch and compile it. Multiple repos always makes everything >>>>>>> harder >>>>>>> to release. >>>>>>> >>>>>>> Am Fr., 16. Sept. 2022 um 09:30 Uhr schrieb Udo Schnurpfeil < >>>>>>> [email protected]>: >>>>>>> >>>>>>>> It would be nice to have a branch or project where the JSF 2.3 >>>>>>>> compatible version can live, because we may need it for fixes. >>>>>>>> >>>>>>>> Maybe in Werners own project (but its not real community), or in >>>>>>>> the Tobago project. The disadvantage is, that fixes for both versions >>>>>>>> affects sources in different projects. It's a bit more error-prone and >>>>>>>> more >>>>>>>> work... >>>>>>>> >>>>>>>> Maybe we put the built in the branch of MyFaces 2.3 or 3 but do not >>>>>>>> use it there, only releasing to NPM? This may a bit more transparent. >>>>>>>> >>>>>>>> Regards >>>>>>>> >>>>>>>> Udo >>>>>>>> Am 15.09.22 um 17:26 schrieb Thomas Andraschko: >>>>>>>> >>>>>>>> I would only add it in 4.0 (Jakarta), all other branches are stable >>>>>>>> >>>>>>>> Udo Schnurpfeil <[email protected]> schrieb am Do., 15. Sept. >>>>>>>> 2022, 16:43: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> in which versions of MyFaces this will be integrated? I think >>>>>>>>> there is a difference because of the jakarta namespace for the new >>>>>>>>> version. >>>>>>>>> >>>>>>>>> In Tobago we integrate the generated js file directly in the npm >>>>>>>>> build process of Tobago. The JS will be provieded by Tobago, NOT from >>>>>>>>> the >>>>>>>>> used JSF implemantation. The reason is old (but might be right >>>>>>>>> today), some >>>>>>>>> application servers bring old versions of JSF with them, and the JS >>>>>>>>> was >>>>>>>>> buggy. >>>>>>>>> >>>>>>>>> My question: >>>>>>>>> >>>>>>>>> Will it be possible in the future to get the JS via npm in both >>>>>>>>> versions (namespace javax and namespace jakarta). >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Udo >>>>>>>>> Am 09.09.22 um 19:19 schrieb Werner Punz: >>>>>>>>> >>>>>>>>> Hi I think the build speed does not make a huge difference. >>>>>>>>> But I think the best option would be to simply make the build >>>>>>>>> optional and for normal builds just use the js files, which of course >>>>>>>>> can be comitted together with the ts files. >>>>>>>>> Theoretically we do not need to rebuild every time, a simple copy >>>>>>>>> of the javascripts >>>>>>>>> to the target directory is enough. But a working build must be in >>>>>>>>> there for verification. >>>>>>>>> >>>>>>>>> Timetable, second issue. I thought I could wrap things up this >>>>>>>>> week, but given I am on vacation next week, it will be probably the >>>>>>>>> week >>>>>>>>> after. >>>>>>>>> I have a pretty well working myfaces setup already which however >>>>>>>>> atm still runs the build every time, but we can move to "optional". >>>>>>>>> >>>>>>>>> Atm 3 of my external integration tests fail on extreme corner >>>>>>>>> cases atm, I have to check why. >>>>>>>>> So I will need another 2-3 days the week after next to wrap things >>>>>>>>> up, I guess. >>>>>>>>> >>>>>>>>> Werner >>>>>>>>> >>>>>>>>> >>>>>>>>> Am Fr., 9. Sept. 2022 um 12:44 Uhr schrieb Udo Schnurpfeil < >>>>>>>>> [email protected]>: >>>>>>>>> >>>>>>>>>> Hi Werner, >>>>>>>>>> >>>>>>>>>> good to hear from you. >>>>>>>>>> >>>>>>>>>> About the build process: All the JavaScript code of Tobago was >>>>>>>>>> migrated to TypeScript and we use the maven-frontend-plugin to >>>>>>>>>> compile it >>>>>>>>>> to JavaScript. >>>>>>>>>> >>>>>>>>>> Because of the problems you have indicated, we build the TS -> JS >>>>>>>>>> with Maven profile -Pfrontend to activate the NPM. >>>>>>>>>> >>>>>>>>>> We commit the generated code as resources in the project. So, we >>>>>>>>>> can build with or without regenerating the JavaScript code. >>>>>>>>>> >>>>>>>>>> advantage: >>>>>>>>>> >>>>>>>>>> - normal build is faster >>>>>>>>>> - independent from npm infrastructure >>>>>>>>>> >>>>>>>>>> disadvantage: >>>>>>>>>> >>>>>>>>>> - generated code under source control >>>>>>>>>> - explicit re-generation is needed, sometimes >>>>>>>>>> >>>>>>>>>> What is the best option for MyFaces core? >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> >>>>>>>>>> Udo >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Am 08.09.22 um 15:55 schrieb Werner Punz: >>>>>>>>>> >>>>>>>>>> Sorry for my silence the last few days. >>>>>>>>>> >>>>>>>>>> Given my long "hiatus" it took me a little bit to get everything >>>>>>>>>> together again. >>>>>>>>>> Following, I think i found a solution I think we can live with >>>>>>>>>> >>>>>>>>>> a) The main hosting for now of the scripts and the monadish base >>>>>>>>>> lib still is on github, but >>>>>>>>>> b) I basically added s small node project to the api, which pulls >>>>>>>>>> the npm files from node and extracts the sources and tests and >>>>>>>>>> pushes them >>>>>>>>>> into the myfaces source structure, that way we can host the sources >>>>>>>>>> on the >>>>>>>>>> myfaces side >>>>>>>>>> c) You can run then a full build via node and also can run all >>>>>>>>>> the tests on both projects >>>>>>>>>> d) The final result is the jsf.js and the jsf-development.js >>>>>>>>>> along with the corresponding map files and a gz and br compressed >>>>>>>>>> version >>>>>>>>>> of the files (for browsers which reques compressed files) >>>>>>>>>> c and d) will be triggered by the maven frontend plugin which is >>>>>>>>>> a shim over node (which also does a local download and install of >>>>>>>>>> node and >>>>>>>>>> the subproject dependencies) >>>>>>>>>> >>>>>>>>>> The end result of the build process is the files at the required >>>>>>>>>> location and given we now have mapping files we can drop the special >>>>>>>>>> builds, so the >>>>>>>>>> resource loader will become smaller. >>>>>>>>>> The downside is, we now have node as intermediate step for >>>>>>>>>> building the files and some node dependencies (jsf_ts for loading the >>>>>>>>>> sources, but that is not >>>>>>>>>> needed given we host them ourselfs, and a ton of dependencies for >>>>>>>>>> the javascript based unit tests, around mocha) >>>>>>>>>> >>>>>>>>>> Unfortunately we cannot skip the entire node embedded into maven >>>>>>>>>> part.given we want to start from typescript level and want to have >>>>>>>>>> unit >>>>>>>>>> tests on top of it. >>>>>>>>>> The easier way of course would be just to use the npm packages >>>>>>>>>> and the final js files, but we want to have the full build cycle. >>>>>>>>>> >>>>>>>>>> So there are some dependencies for the build which are outside of >>>>>>>>>> maven and apache. But normally organisations have an npm proxy >>>>>>>>>> somewhere, >>>>>>>>>> so that in case the node infrastructure goes down the build >>>>>>>>>> systems survive. Does apache have something like this? Myfaces >>>>>>>>>> probably is >>>>>>>>>> not the only Apache project >>>>>>>>>> relying on node/npm infrastructure for their builds. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Werner >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Am Di., 6. Sept. 2022 um 14:06 Uhr schrieb Werner Punz < >>>>>>>>>> [email protected]>: >>>>>>>>>> >>>>>>>>>>> Yes i was just worried to drag npm into the build process, but >>>>>>>>>>> if everyone is fine going with the frontend-plugin i am perfectly >>>>>>>>>>> fine with >>>>>>>>>>> it, as well. >>>>>>>>>>> >>>>>>>>>>> This is the best way to combine npm and maven builds atm anyway, >>>>>>>>>>> because it simply relegates whatever npm has to do to npm >>>>>>>>>>> and maven takes care of the rest. You even can set local proxies >>>>>>>>>>> and have full control over the npm and node versions that way via >>>>>>>>>>> maven. >>>>>>>>>>> >>>>>>>>>>> Werner >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Am Di., 6. Sept. 2022 um 14:03 Uhr schrieb Melloware < >>>>>>>>>>> [email protected]>: >>>>>>>>>>> >>>>>>>>>>>> Absolutely this is the way to go. It will download node run >>>>>>>>>>>> your package.json script to compile the TypeScript code and put it >>>>>>>>>>>> in the >>>>>>>>>>>> right location all as part of the Maven Build. >>>>>>>>>>>> On 9/6/2022 5:46 AM, Werner Punz wrote: >>>>>>>>>>>> >>>>>>>>>>>> Just checked the code, it uses basically the frontend maven >>>>>>>>>>>> plugin, >>>>>>>>>>>> which is a maven shim over node: >>>>>>>>>>>> <plugin> >>>>>>>>>>>> >>>>>>>>>>>> <groupId>com.github.eirslett</groupId> >>>>>>>>>>>> >>>>>>>>>>>> <artifactId>frontend-maven-plugin</artifactId> >>>>>>>>>>>> >>>>>>>>>>>> <version>1.12.1</version> >>>>>>>>>>>> >>>>>>>>>>>> <configuration> >>>>>>>>>>>> >>>>>>>>>>>> <nodeVersion>v16.13.1</nodeVersion> >>>>>>>>>>>> >>>>>>>>>>>> <npmVersion>8.1.2</npmVersion> >>>>>>>>>>>> >>>>>>>>>>>> <installDirectory>${main.basedir}/target/node</installDirectory >>>>>>>>>>>> > >>>>>>>>>>>> >>>>>>>>>>>> </configuration> >>>>>>>>>>>> >>>>>>>>>>>> </plugin> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I can go this route, this would be the least painful one >>>>>>>>>>>> because it basically just downloads node and executes the node >>>>>>>>>>>> build as is, >>>>>>>>>>>> if this is ok with the apache build process. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Werner >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Am Di., 6. Sept. 2022 um 11:08 Uhr schrieb Werner Punz < >>>>>>>>>>>> [email protected]>: >>>>>>>>>>>> >>>>>>>>>>>>> Sounds great I will have a look. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks for the hint. >>>>>>>>>>>>> >>>>>>>>>>>>> Werner >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Am Di., 6. Sept. 2022 um 11:05 Uhr schrieb Melloware Inc < >>>>>>>>>>>>> [email protected]>: >>>>>>>>>>>>> >>>>>>>>>>>>>> Werner, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I can get the code building in maven even if it’s in >>>>>>>>>>>>>> Typescript. We do something similar in PF extensions. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Melloware >>>>>>>>>>>>>> @melloware on GitHub >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Sep 6, 2022, at 4:52 AM, Werner Punz < >>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi there is code reduction going on in the build step anyway, >>>>>>>>>>>>>> but I also can move the parts from mona-dish over (which i had >>>>>>>>>>>>>> in the past) >>>>>>>>>>>>>> Problem is that we still will be npm dependent for testing >>>>>>>>>>>>>> libs etc... so i cannot get npm entirely out of the loop for >>>>>>>>>>>>>> testing >>>>>>>>>>>>>> purposes shim libraries for testing etc... >>>>>>>>>>>>>> That means if we move the ts code over we have to introduce >>>>>>>>>>>>>> an npm build step. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I will work on something here and then we can all have a look >>>>>>>>>>>>>> whether this should be the way to go. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Werner >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Am Di., 6. Sept. 2022 um 10:35 Uhr schrieb Thomas Andraschko < >>>>>>>>>>>>>> [email protected]>: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Werner, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> great to hear that you are back and hope you are fine again >>>>>>>>>>>>>>> :) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> IMO the reimplementation is great and improves the >>>>>>>>>>>>>>> maintainability a lot for the future. >>>>>>>>>>>>>>> I would personally only push it in the master (4.0 / >>>>>>>>>>>>>>> jakarta.*), all other branches are "stable" and we should not >>>>>>>>>>>>>>> touch them. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Therefore we are totally fine to only support IE11+. >>>>>>>>>>>>>>> So it would be great if you can also remove some older IE >>>>>>>>>>>>>>> hacks like >>>>>>>>>>>>>>> https://github.com/werpu/jsfs_js_ts/blob/master/src/main/typescript/impl/xhrCore/RequestDataResolver.ts#L113 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Also it would be great if you can further improve >>>>>>>>>>>>>>> readability. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> For me its absolutely mandatory that all code is directly in >>>>>>>>>>>>>>> MyFaces and compiles with Maven somehow. >>>>>>>>>>>>>>> So it would also be great if you could only use a minimal of >>>>>>>>>>>>>>> your TS mona-dish lib, so we are as clean and minimalistic as >>>>>>>>>>>>>>> possible. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>> Thomas >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Am Di., 6. Sept. 2022 um 10:21 Uhr schrieb Werner Punz < >>>>>>>>>>>>>>> [email protected]>: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I will add a short summary on what we have: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The project atm is hosted on github and basically 100% my >>>>>>>>>>>>>>>> code (although split into 2 projects) >>>>>>>>>>>>>>>> it is 100% implemented in typescript and fortified with a >>>>>>>>>>>>>>>> ton of unit tests. I have yet given i did not work on it for >>>>>>>>>>>>>>>> quite some >>>>>>>>>>>>>>>> time, check the coverage percentage, but it is high. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Downside is, I cut off a ton of old browser support. I >>>>>>>>>>>>>>>> think IE11 is still supported but nothing below. >>>>>>>>>>>>>>>> The code is way more readable although some parts still can >>>>>>>>>>>>>>>> be improved. Maintainability was Prio #1 something the old >>>>>>>>>>>>>>>> code which had >>>>>>>>>>>>>>>> to support a ton of legacy browsers did not have. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Downside is, it is 100% typescript, so we need to merge >>>>>>>>>>>>>>>> that into the myfaces base one way or the other but there is >>>>>>>>>>>>>>>> no way to >>>>>>>>>>>>>>>> avoid an npm build step if we drag in the package via npm or >>>>>>>>>>>>>>>> on typescript >>>>>>>>>>>>>>>> level. >>>>>>>>>>>>>>>> Another option simply would be to fetch the compiled >>>>>>>>>>>>>>>> sources but that leaves out the connection to the original >>>>>>>>>>>>>>>> sources entirely >>>>>>>>>>>>>>>> (except for the sourcemaps), which I would not prefer. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The implementation level is atm jsf 2.x i have to check >>>>>>>>>>>>>>>> whether we need siginficant extensions for 3 when I stalled my >>>>>>>>>>>>>>>> work the >>>>>>>>>>>>>>>> status was the js parts did not change. >>>>>>>>>>>>>>>> (one thing I have on my plan for the next few days) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Werner >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Am Di., 6. Sept. 2022 um 10:13 Uhr schrieb Werner Punz < >>>>>>>>>>>>>>>> [email protected]>: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hi Sorry for my long absence. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thing is I had severe health problems last year with a >>>>>>>>>>>>>>>>> disc prolapse becoming acute, and had a ton of private stuff >>>>>>>>>>>>>>>>> on my back >>>>>>>>>>>>>>>>> this year on top of my job. >>>>>>>>>>>>>>>>> However I have now picked up the work on the JSF,js >>>>>>>>>>>>>>>>> Typescript again. >>>>>>>>>>>>>>>>> I have yet to check the latest specs of JSF given i was >>>>>>>>>>>>>>>>> out of the loop for a year if anything significant needs to >>>>>>>>>>>>>>>>> be added. >>>>>>>>>>>>>>>>> The Scripts themselve work and have been in usage in >>>>>>>>>>>>>>>>> Tobago for quite a while. >>>>>>>>>>>>>>>>> I am just asking whether we want them to add to myfaces or >>>>>>>>>>>>>>>>> not. If yes then I would start the work to add them as a >>>>>>>>>>>>>>>>> build option. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> But I want the community decide on this. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Lets start a discussion. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Werner >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>
