You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Werner Punz <we...@gmail.com> on 2017/10/05 07:19:05 UTC
jsf.js post 2.3 plans
Hi guys
I just wanted to start a discussion on how we are going to proceed with
the jsf.js codebase.
The issue is following:
Our codebase which currently is adapted by me for 2.3 is rather old.
It by now is around 9-10 years old and back then most of the stuff I did
made sense
a) The library needed to be self contained
b) There were an awful lot of browsers in use, which did not adhere to
any standards whatsoever
c) There was no real inheritance system available just the prototype
system which is one level below inheritance by allowing to access the
class/object tree and manipulate it on the fly
So what I did was following
Implement my own class system for not having to deal with prototype
inheritance all the time
Since I needed to be self contained integrating a library like JQuery
(which also was it its infancy at that time) was out of the question
due to possible conflicts. There also was no widespread support
for querySelector on node level some browsers had it some browsers
had other workarounds to speed the dom node lookup up.
Also no unified ajax handling, the ajax api was at its infancy and I
still had to support the archaic IE way of doing things.
To the worse there were significant differences in dom and xml handling
between the various browsers out in the wild compared to the already
defined standards (I am speaking of you IE and mobile browsers in use
back then)
So in the end I ended up with a codebase which is about 40-50% there
just to support legacy browsers. While I did some work to isolate the
quirks code and compile it out of the codebase there still is work to be
done.
Again all of this made sense back then...
Lots of things have been changed in those 10 years and now most of the
things do not make sense anymore.
a) We have saner meta languages which allow to compile to javascript,
following candidates come to my mind
- Typescript, a language which I amn very familiar with due to my day to
day work
- Coffeescript ... not very familiar with that one
- Kotlin... yes that one also has a javascript target compiler
We definitely should opt for a meta compiler instead of pure js.
The reasons are many, and I can speak here atm only for Typescript
- You can change ecma script levels on build level
- You can change the package management system in build level
- You get additional coding security by having the apis fortified at
least with some types instead of doing constantly your manual asserts
- In the end the Meta language codebase is way cleaner than the original one
The downside is
at least for typescript the maven integration is non existent, there is
a maven clientside plugin which downloads the entire node js chain onto
your machine within a build, but my guess is we do not need to do this
for the apache integration builds, because in the end we just need the
js codebase. We can add special dev profile which enables the client
side build to build the js files.
As for Kotlin, I have not evalauted their javascript stuff but what put
me off was that the website said you have to integrate kotlin.js which
is a no go, but this depends, if kotlin.js just implements their runtime
lib we can probably bypass that. I need to have a serious look at it.
The plus side probably is that it has decent maven support and a perfect
IDE support on the Jetbrains IDEs. (Dont get me wrong the IDE support
of Typescript also is very good on those, I use it on a daily base)
Browser support:
Since mobile browsers are up to rather recent standards nowadays the
problem is the desktop which at least in a corporate environment is
moving really slowly (I wonder corporations are really cautious
regarding security and yet often use stone old often outdated not
updated anymore, browsers - but that is just a snarky sidenote). But
still there things have gotten better.
From a browser support standpoint we probably can strip the support pre
IE9 level which means we finally at least can use a standard ajax api,
ajax multiform requests instead of the iframe hack I had to introduce
for jsf 2.2.
I would prefer to have IE11 as baseline, given that most corporations
probably have frozen their environment on a Windows 7 IE11 baseline by
now, but I guess we have to drag at least IE9 with us with some third
party lib support.
By mildly adding small external libraries and avoiding shims
we might get a small query monadish api on top of node.selectorAll like
jquery.
I still would avoid to integrate jquery because we have a core lib
so everything integrated needs to be small. We do not have the luxury of
for instance Prime Faces which can require or bundle a huge lib like
JQuery and JQuery UI.
Also we definitely would need promises (again rip the code out of a
proven shim lib but do not shim it, if it is not supported by the
browser natively)
So my proposal is, after 2.3 I will start with a reimplementation which
might take some time in a saner environment and with a newly defined
baseline.
And once I am done we can drop it in as alternative jsf.js codebase
for the users (we still keep the old one for 2.3)
And for 2.4 upwards we will drop the legacy codebase entirely and just
use the new reworked and cleaned up one.
Just a little bit of food for discussion.
Werner
Re: jsf.js post 2.3 plans
Posted by Kito Mann <ki...@virtua.com>.
+1 on rewriting the JS codebase. I'm personally a huge fan of TypeScript as
well and use it on a daily basis, and I don't see a downside with choosing
it since it's very popular these days.
One other possibility, however, is pure Java using JSweet (
http://www.jsweet.org/). It's certainly more build overhead than just using
TypeScipt, but since it uses the tsc compiler internally _and_ integrates
with maven, it might be a good choice. It doesn't have a runtime library
like Kotlin.
___
Kito D. Mann | @kito99 | Author, JSF in Action
Web Components, Polymer, JSF, PrimeFaces, Java EE training and consulting
Virtua, Inc. | virtua.tech
JSFCentral.com | @jsfcentral | knowesis.io - fresh Web Components info
+1 203-998-0403
* Listen to the Enterprise Java Newscast: http://enterprisejavanews.com
On Thu, Oct 5, 2017 at 3:19 AM, Werner Punz <we...@gmail.com> wrote:
> Hi guys
>
>
> I just wanted to start a discussion on how we are going to proceed with
> the jsf.js codebase.
> The issue is following:
>
> Our codebase which currently is adapted by me for 2.3 is rather old.
> It by now is around 9-10 years old and back then most of the stuff I did
> made sense
> a) The library needed to be self contained
> b) There were an awful lot of browsers in use, which did not adhere to any
> standards whatsoever
> c) There was no real inheritance system available just the prototype
> system which is one level below inheritance by allowing to access the
> class/object tree and manipulate it on the fly
>
> So what I did was following
> Implement my own class system for not having to deal with prototype
> inheritance all the time
> Since I needed to be self contained integrating a library like JQuery
> (which also was it its infancy at that time) was out of the question
> due to possible conflicts. There also was no widespread support
> for querySelector on node level some browsers had it some browsers
> had other workarounds to speed the dom node lookup up.
>
> Also no unified ajax handling, the ajax api was at its infancy and I still
> had to support the archaic IE way of doing things.
>
> To the worse there were significant differences in dom and xml handling
> between the various browsers out in the wild compared to the already
> defined standards (I am speaking of you IE and mobile browsers in use back
> then)
>
> So in the end I ended up with a codebase which is about 40-50% there just
> to support legacy browsers. While I did some work to isolate the quirks
> code and compile it out of the codebase there still is work to be done.
>
> Again all of this made sense back then...
>
>
> Lots of things have been changed in those 10 years and now most of the
> things do not make sense anymore.
>
> a) We have saner meta languages which allow to compile to javascript,
> following candidates come to my mind
>
> - Typescript, a language which I amn very familiar with due to my day to
> day work
> - Coffeescript ... not very familiar with that one
> - Kotlin... yes that one also has a javascript target compiler
>
> We definitely should opt for a meta compiler instead of pure js.
> The reasons are many, and I can speak here atm only for Typescript
>
> - You can change ecma script levels on build level
> - You can change the package management system in build level
> - You get additional coding security by having the apis fortified at least
> with some types instead of doing constantly your manual asserts
> - In the end the Meta language codebase is way cleaner than the original
> one
>
>
> The downside is
>
>
> at least for typescript the maven integration is non existent, there is a
> maven clientside plugin which downloads the entire node js chain onto your
> machine within a build, but my guess is we do not need to do this
> for the apache integration builds, because in the end we just need the js
> codebase. We can add special dev profile which enables the client side
> build to build the js files.
>
> As for Kotlin, I have not evalauted their javascript stuff but what put me
> off was that the website said you have to integrate kotlin.js which is a no
> go, but this depends, if kotlin.js just implements their runtime lib we can
> probably bypass that. I need to have a serious look at it.
>
> The plus side probably is that it has decent maven support and a perfect
> IDE support on the Jetbrains IDEs. (Dont get me wrong the IDE support
> of Typescript also is very good on those, I use it on a daily base)
>
>
> Browser support:
>
> Since mobile browsers are up to rather recent standards nowadays the
> problem is the desktop which at least in a corporate environment is moving
> really slowly (I wonder corporations are really cautious regarding security
> and yet often use stone old often outdated not updated anymore, browsers -
> but that is just a snarky sidenote). But still there things have gotten
> better.
>
> From a browser support standpoint we probably can strip the support pre
> IE9 level which means we finally at least can use a standard ajax api, ajax
> multiform requests instead of the iframe hack I had to introduce for jsf
> 2.2.
>
> I would prefer to have IE11 as baseline, given that most corporations
> probably have frozen their environment on a Windows 7 IE11 baseline by now,
> but I guess we have to drag at least IE9 with us with some third party lib
> support.
>
> By mildly adding small external libraries and avoiding shims
> we might get a small query monadish api on top of node.selectorAll like
> jquery.
>
> I still would avoid to integrate jquery because we have a core lib
> so everything integrated needs to be small. We do not have the luxury of
> for instance Prime Faces which can require or bundle a huge lib like JQuery
> and JQuery UI.
>
> Also we definitely would need promises (again rip the code out of a proven
> shim lib but do not shim it, if it is not supported by the browser
> natively)
>
> So my proposal is, after 2.3 I will start with a reimplementation which
> might take some time in a saner environment and with a newly defined
> baseline.
> And once I am done we can drop it in as alternative jsf.js codebase
> for the users (we still keep the old one for 2.3)
> And for 2.4 upwards we will drop the legacy codebase entirely and just
> use the new reworked and cleaned up one.
>
>
> Just a little bit of food for discussion.
>
> Werner
>
>
>
>
>
>
Re: jsf.js post 2.3 plans
Posted by Werner Punz <we...@gmail.com>.
Ok just to FUP... To give food for discussion:
I gave kotlin a few minutes ago a testrun, here is the result:
package test.test2
class TestClass {
val hello: String = "";
fun helloWorld() {
console.info("hello");
}
}
and the resulting Javascript was:
if (typeof kotlin === 'undefined') {
throw new Error("Error loading module 'testkotlin'. Its dependency
'kotlin' was not found. Please, check whether 'kotlin' is loaded prior
to 'testkotlin'.");
}
var testkotlin = function (_, Kotlin) {
'use strict';
function TestClass() {
this.hello = '';
}
TestClass.prototype.helloWorld = function () {
console.info('hello');
};
TestClass.$metadata$ = {
kind: Kotlin.Kind.CLASS,
simpleName: 'TestClass',
interfaces: []
};
var package$test = _.test || (_.test = {});
var package$test2 = package$test.test2 || (package$test.test2 = {});
package$test2.TestClass = TestClass;
Kotlin.defineModule('testkotlin', _);
return _;
}(typeof testkotlin === 'undefined' ? {} : testkotlin, kotlin);
The problem here is that even with a simple class kotlin maps to
kotlin,js instead of just using prototype inheritance or ES6 classes.
if (typeof kotlin === 'undefined') {
throw new Error("Error loading module 'testkotlin'. Its dependency
'kotlin' was not found. Please, check whether 'kotlin' is loaded prior
to 'testkotlin'.");
}
...
var testkotlin = function (_, Kotlin) {
....
TestClass.$metadata$ = {
kind: Kotlin.Kind.CLASS,
simpleName: 'TestClass',
interfaces: []
};
Unfortunately although I am always eager to use a new language Kotlin
for our case due to this fact is a no go:-/
Also the Kotlin.js file has about 35000 locs uncompressed.
Which is a library size which I am not very eager to bundle into a
base lib which should not interfere with other libraries and should
be as small as possible.
Just in comparison the same code compiled from Typescript to javascript
(ES5):
module test {
export module test2 {
export class HelloWorld {
hello: string;
helloWorld() {
console.info("hello");
}
}
}
}
var test;
(function (test) {
var test2;
(function (test2) {
var HelloWorld = (function () {
function HelloWorld() {
}
HelloWorld.prototype.helloWorld = function () {
console.info("hello");
};
return HelloWorld;
}());
test2.HelloWorld = HelloWorld;
})(test2 = test.test2 || (test.test2 = {}));
})(test || (test = {}));
A subsequent use would follow in following code:
var HelloWorld = test.test2.HelloWorld;
var hello;
So I guess the result is as clean as it can be. You can vary es levels
and module systems just by switching the compiler settings.
The Typescript settings were compile target ES5 and no module system
here which will be the baseline for the myfaces impl since the spec
targets a global namespacing.
(ES6 would have produced real classes)
This is just a compiler switch away:
"use strict";
var test;
(function (test) {
var test2;
(function (test2) {
class HelloWorld {
helloWorld() {
console.info("hello");
}
}
test2.HelloWorld = HelloWorld;
})(test2 = test.test2 || (test.test2 = {}));
})(test || (test = {}));
Cheers
Werner
Am 08.10.17 um 16:09 schrieb Werner Punz:
> No sync with Mojarra I have discussed that a while ago.
> The problem is a licensing problem. Mojarra basically can use
> our code but not vice versa, because the CDDL cannot be implemented in
> ASF2 code.
>
> The ASF2 license is a very liberal license, but due to the fact that it
> is so liberal, it is impossible to integrate less liberal code in our
> codebase.
>
> As for your repeated Ajax problems MYFACES-4160 that is a really old
> spec bug which reared its ugly head in multiform scenarii.
> I worked around that by providing a special config param.
> With JSF 2.3 it finally will be fixed.
>
>
>
> Werner
>
>
> Am 06.10.17 um 11:59 schrieb Dora Rajappan:
>> Thanks for detailing the future of browser and how jsf cope up with it.
>>
>> I was using mojarra for my application and the commandLink was not
>> working due to script problem.
>> So I switched to myfaces and we got some problem with repeated ajax
>> calls. (Myfaces 4160).
>>
>> Are we syncing with mojarra regarding the technology to be used with
>> the jsf.js, entire scripting arena.
>> Not sure spec say anything about the technology used for scripting.
>>
>> Thanks & Regards,
>> Dora Rajappan.
>
>
>
Re: jsf.js post 2.3 plans
Posted by Henning Nöth <he...@irian.eu>.
Hi Werner,
thank you for your work so far.
For Tobago, we had already considered of converting our JavaScript into
TypeScript.
Now that this is a topic for Myfaces, I think we should probably start
to convert the Tobago JavaScript files soon.
Regards
Henning
Am 09.10.17 um 13:24 schrieb Dora Rajappan:
> Hi Werner,
>
> I had a mvn clean package of core and checked it from IE 11 and it
> works very good.
> The fix works fine with repeated ajax calls now!
>
> Thanks & Regards,
> Dora Rajappan.
>
> .
> On Monday, October 9, 2017, 3:19:19 PM GMT+5:30, Werner Punz
> <werner.punz@gmail.com <ma...@gmail.com>> wrote:
>
>
> Just to clarify it:
>
> Before the update it looks like
>
> https://gist.github.com/werpu/ 071e11cc6328f9f439a6342b0e128e c8
> <https://gist.github.com/werpu/071e11cc6328f9f439a6342b0e128ec8>
>
> Both forms have a viewstate element.
>
> Before my fixes, the viewstate of the first form was gone.
> Hence you ran into issues:
>
> After my yesterdays update the result now looks like following (I got a
> validation error so the viewstate is recycled in the response which
> looks like)
>
> https://gist.github.com/werpu/ 172786afcdf6514b6120379ab5e236 ce
> <https://gist.github.com/werpu/172786afcdf6514b6120379ab5e236ce>
>
> The final rendered form is now:
>
> https://gist.github.com/werpu/ cd85343ddc42ef8857a806d8fe06e2 33
> <https://gist.github.com/werpu/cd85343ddc42ef8857a806d8fe06e233>
>
>
> EjSU7V49OrNPDglILvevt4kDdHyuyO RwVxrmPKQfWqfKBXoi on form 1 and 2 being
> the same.
>
>
> Before my patches, only the second form hat a valid viewstate element
> set and hence you ran into viewstate issues.
>
> Please check the jsf.js your browser is loading, if you got the old
> version in, it looks like it. The build should have produced one
> with the new version, but jsf.js is never checked in, it is built by
> the
> build system.
>
> Check your browsers jsf.js for something like mfInternal.namingModeId
> This is only in my patch but not in the old codebase.
>
>
>
> Cheers
>
> Werner
>
>
>
>
> Am 09.10.17 um 11:34 schrieb Werner Punz:
> > Hi Dora, what do you mean that the
> > behavior of repeated ajax calls is same?
> >
> >
> > I tried your example yesterday after building the final js file via a
> > mvn build and before
> > only the second form got an ajax viestate update
> > now both forms get one.
> >
> > What behavior do you get?
> > Did you make a proper mvn clean install to get the latest jsf.js in?
> >
> > ajaxresponse22.js was deleted because it is dead code it accidentally
> > was in the codebase, ajaxresponse.js now updates all forms in a
> > multiform environment under a given view root. In your example
> > the viewroot is the body element.
> >
> >
> >
> >
> >
> > Werner
> >
> >
> >
> > Am 09.10.17 um 10:46 schrieb Dora Rajappan:
> >> Hi,
> >>
> >> Thank you very much for the fix Werner.
> >> I took the latest core today and built it and tested from payara
> >> without any config changes. Found ajaxresponse22.js deleted and
> >> ajaxresponse.js changed.
> >> And the behavior of repeated ajax calls is same.
> >> Can we have the config changes exactly if any in this manner? I
> >> checked 4160 and quickly not make out the config changes.
> >> <context-param>
> >> <param-name>xyz</param-name>
> >> <param-value>abc</param-value>
> >> </context-param>
> >>
> >> Thanks & Regards,
> >> Dora Rajappan.
> >> On Sunday, October 8, 2017, 7:39:48 PM GMT+5:30, Werner Punz
> >> <werner.punz@gmail.com <ma...@gmail.com>> wrote:
> >>
> >>
> >> No sync with Mojarra I have discussed that a while ago.
> >> The problem is a licensing problem. Mojarra basically can use
> >> our code but not vice versa, because the CDDL cannot be
> implemented in
> >> ASF2 code.
> >>
> >> The ASF2 license is a very liberal license, but due to the fact
> that it
> >> is so liberal, it is impossible to integrate less liberal code in our
> >> codebase.
> >>
> >> As for your repeated Ajax problems MYFACES-4160 that is a really old
> >> spec bug which reared its ugly head in multiform scenarii.
> >> I worked around that by providing a special config param.
> >> With JSF 2.3 it finally will be fixed.
> >>
> >>
> >>
> >> Werner
> >>
> >>
> >> Am 06.10.17 um 11:59 schrieb Dora Rajappan:
> >> > Thanks for detailing the future of browser and how jsf cope up
> with
> >> it.
> >> >
> >> > I was using mojarra for my application and the commandLink was not
> >> > working due to script problem.
> >> > So I switched to myfaces and we got some problem with repeated
> ajax
> >> > calls. (Myfaces 4160).
> >> >
> >> > Are we syncing with mojarra regarding the technology to be used
> >> with the
> >> > jsf.js, entire scripting arena.
> >> > Not sure spec say anything about the technology used for
> scripting.
> >> >
> >> > Thanks & Regards,
> >> > Dora Rajappan.
> >>
> >>
> >
> >
> >
>
>
>
Re: jsf.js post 2.3 plans
Posted by Dora Rajappan <do...@yahoo.com>.
Hi Werner,
I had a mvn clean package of core and checked it from IE 11 and it works very good. The fix works fine with repeated ajax calls now!
Thanks & Regards, Dora Rajappan.
. On Monday, October 9, 2017, 3:19:19 PM GMT+5:30, Werner Punz <we...@gmail.com> wrote:
Just to clarify it:
Before the update it looks like
https://gist.github.com/werpu/ 071e11cc6328f9f439a6342b0e128e c8
Both forms have a viewstate element.
Before my fixes, the viewstate of the first form was gone.
Hence you ran into issues:
After my yesterdays update the result now looks like following (I got a
validation error so the viewstate is recycled in the response which
looks like)
https://gist.github.com/werpu/ 172786afcdf6514b6120379ab5e236 ce
The final rendered form is now:
https://gist.github.com/werpu/ cd85343ddc42ef8857a806d8fe06e2 33
EjSU7V49OrNPDglILvevt4kDdHyuyO RwVxrmPKQfWqfKBXoi on form 1 and 2 being
the same.
Before my patches, only the second form hat a valid viewstate element
set and hence you ran into viewstate issues.
Please check the jsf.js your browser is loading, if you got the old
version in, it looks like it. The build should have produced one
with the new version, but jsf.js is never checked in, it is built by the
build system.
Check your browsers jsf.js for something like mfInternal.namingModeId
This is only in my patch but not in the old codebase.
Cheers
Werner
Am 09.10.17 um 11:34 schrieb Werner Punz:
> Hi Dora, what do you mean that the
> behavior of repeated ajax calls is same?
>
>
> I tried your example yesterday after building the final js file via a
> mvn build and before
> only the second form got an ajax viestate update
> now both forms get one.
>
> What behavior do you get?
> Did you make a proper mvn clean install to get the latest jsf.js in?
>
> ajaxresponse22.js was deleted because it is dead code it accidentally
> was in the codebase, ajaxresponse.js now updates all forms in a
> multiform environment under a given view root. In your example
> the viewroot is the body element.
>
>
>
>
>
> Werner
>
>
>
> Am 09.10.17 um 10:46 schrieb Dora Rajappan:
>> Hi,
>>
>> Thank you very much for the fix Werner.
>> I took the latest core today and built it and tested from payara
>> without any config changes. Found ajaxresponse22.js deleted and
>> ajaxresponse.js changed.
>> And the behavior of repeated ajax calls is same.
>> Can we have the config changes exactly if any in this manner? I
>> checked 4160 and quickly not make out the config changes.
>> <context-param>
>> <param-name>xyz</param-name>
>> <param-value>abc</param-value>
>> </context-param>
>>
>> Thanks & Regards,
>> Dora Rajappan.
>> On Sunday, October 8, 2017, 7:39:48 PM GMT+5:30, Werner Punz
>> <we...@gmail.com> wrote:
>>
>>
>> No sync with Mojarra I have discussed that a while ago.
>> The problem is a licensing problem. Mojarra basically can use
>> our code but not vice versa, because the CDDL cannot be implemented in
>> ASF2 code.
>>
>> The ASF2 license is a very liberal license, but due to the fact that it
>> is so liberal, it is impossible to integrate less liberal code in our
>> codebase.
>>
>> As for your repeated Ajax problems MYFACES-4160 that is a really old
>> spec bug which reared its ugly head in multiform scenarii.
>> I worked around that by providing a special config param.
>> With JSF 2.3 it finally will be fixed.
>>
>>
>>
>> Werner
>>
>>
>> Am 06.10.17 um 11:59 schrieb Dora Rajappan:
>> > Thanks for detailing the future of browser and how jsf cope up with
>> it.
>> >
>> > I was using mojarra for my application and the commandLink was not
>> > working due to script problem.
>> > So I switched to myfaces and we got some problem with repeated ajax
>> > calls. (Myfaces 4160).
>> >
>> > Are we syncing with mojarra regarding the technology to be used
>> with the
>> > jsf.js, entire scripting arena.
>> > Not sure spec say anything about the technology used for scripting.
>> >
>> > Thanks & Regards,
>> > Dora Rajappan.
>>
>>
>
>
>
Re: jsf.js post 2.3 plans
Posted by Werner Punz <we...@gmail.com>.
Just to clarify it:
Before the update it looks like
https://gist.github.com/werpu/071e11cc6328f9f439a6342b0e128ec8
Both forms have a viewstate element.
Before my fixes, the viewstate of the first form was gone.
Hence you ran into issues:
After my yesterdays update the result now looks like following (I got a
validation error so the viewstate is recycled in the response which
looks like)
https://gist.github.com/werpu/172786afcdf6514b6120379ab5e236ce
The final rendered form is now:
https://gist.github.com/werpu/cd85343ddc42ef8857a806d8fe06e233
EjSU7V49OrNPDglILvevt4kDdHyuyORwVxrmPKQfWqfKBXoi on form 1 and 2 being
the same.
Before my patches, only the second form hat a valid viewstate element
set and hence you ran into viewstate issues.
Please check the jsf.js your browser is loading, if you got the old
version in, it looks like it. The build should have produced one
with the new version, but jsf.js is never checked in, it is built by the
build system.
Check your browsers jsf.js for something like mfInternal.namingModeId
This is only in my patch but not in the old codebase.
Cheers
Werner
Am 09.10.17 um 11:34 schrieb Werner Punz:
> Hi Dora, what do you mean that the
> behavior of repeated ajax calls is same?
>
>
> I tried your example yesterday after building the final js file via a
> mvn build and before
> only the second form got an ajax viestate update
> now both forms get one.
>
> What behavior do you get?
> Did you make a proper mvn clean install to get the latest jsf.js in?
>
> ajaxresponse22.js was deleted because it is dead code it accidentally
> was in the codebase, ajaxresponse.js now updates all forms in a
> multiform environment under a given view root. In your example
> the viewroot is the body element.
>
>
>
>
>
> Werner
>
>
>
> Am 09.10.17 um 10:46 schrieb Dora Rajappan:
>> Hi,
>>
>> Thank you very much for the fix Werner.
>> I took the latest core today and built it and tested from payara
>> without any config changes. Found ajaxresponse22.js deleted and
>> ajaxresponse.js changed.
>> And the behavior of repeated ajax calls is same.
>> Can we have the config changes exactly if any in this manner? I
>> checked 4160 and quickly not make out the config changes.
>> <context-param>
>> <param-name>xyz</param-name>
>> <param-value>abc</param-value>
>> </context-param>
>>
>> Thanks & Regards,
>> Dora Rajappan.
>> On Sunday, October 8, 2017, 7:39:48 PM GMT+5:30, Werner Punz
>> <we...@gmail.com> wrote:
>>
>>
>> No sync with Mojarra I have discussed that a while ago.
>> The problem is a licensing problem. Mojarra basically can use
>> our code but not vice versa, because the CDDL cannot be implemented in
>> ASF2 code.
>>
>> The ASF2 license is a very liberal license, but due to the fact that it
>> is so liberal, it is impossible to integrate less liberal code in our
>> codebase.
>>
>> As for your repeated Ajax problems MYFACES-4160 that is a really old
>> spec bug which reared its ugly head in multiform scenarii.
>> I worked around that by providing a special config param.
>> With JSF 2.3 it finally will be fixed.
>>
>>
>>
>> Werner
>>
>>
>> Am 06.10.17 um 11:59 schrieb Dora Rajappan:
>> > Thanks for detailing the future of browser and how jsf cope up with
>> it.
>> >
>> > I was using mojarra for my application and the commandLink was not
>> > working due to script problem.
>> > So I switched to myfaces and we got some problem with repeated ajax
>> > calls. (Myfaces 4160).
>> >
>> > Are we syncing with mojarra regarding the technology to be used
>> with the
>> > jsf.js, entire scripting arena.
>> > Not sure spec say anything about the technology used for scripting.
>> >
>> > Thanks & Regards,
>> > Dora Rajappan.
>>
>>
>
>
>
Re: jsf.js post 2.3 plans
Posted by Werner Punz <we...@gmail.com>.
Hi Dora, what do you mean that the
behavior of repeated ajax calls is same?
I tried your example yesterday after building the final js file via a
mvn build and before
only the second form got an ajax viestate update
now both forms get one.
What behavior do you get?
Did you make a proper mvn clean install to get the latest jsf.js in?
ajaxresponse22.js was deleted because it is dead code it accidentally
was in the codebase, ajaxresponse.js now updates all forms in a
multiform environment under a given view root. In your example
the viewroot is the body element.
Werner
Am 09.10.17 um 10:46 schrieb Dora Rajappan:
> Hi,
>
> Thank you very much for the fix Werner.
> I took the latest core today and built it and tested from payara
> without any config changes. Found ajaxresponse22.js deleted and
> ajaxresponse.js changed.
> And the behavior of repeated ajax calls is same.
> Can we have the config changes exactly if any in this manner? I
> checked 4160 and quickly not make out the config changes.
> <context-param>
> <param-name>xyz</param-name>
> <param-value>abc</param-value>
> </context-param>
>
> Thanks & Regards,
> Dora Rajappan.
> On Sunday, October 8, 2017, 7:39:48 PM GMT+5:30, Werner Punz
> <we...@gmail.com> wrote:
>
>
> No sync with Mojarra I have discussed that a while ago.
> The problem is a licensing problem. Mojarra basically can use
> our code but not vice versa, because the CDDL cannot be implemented in
> ASF2 code.
>
> The ASF2 license is a very liberal license, but due to the fact that it
> is so liberal, it is impossible to integrate less liberal code in our
> codebase.
>
> As for your repeated Ajax problems MYFACES-4160 that is a really old
> spec bug which reared its ugly head in multiform scenarii.
> I worked around that by providing a special config param.
> With JSF 2.3 it finally will be fixed.
>
>
>
> Werner
>
>
> Am 06.10.17 um 11:59 schrieb Dora Rajappan:
> > Thanks for detailing the future of browser and how jsf cope up with it.
> >
> > I was using mojarra for my application and the commandLink was not
> > working due to script problem.
> > So I switched to myfaces and we got some problem with repeated ajax
> > calls. (Myfaces 4160).
> >
> > Are we syncing with mojarra regarding the technology to be used with the
> > jsf.js, entire scripting arena.
> > Not sure spec say anything about the technology used for scripting.
> >
> > Thanks & Regards,
> > Dora Rajappan.
>
>
Re: jsf.js post 2.3 plans
Posted by Dora Rajappan <do...@yahoo.com>.
Hi,
Thank you very much for the fix Werner. I took the latest core today and built it and tested from payara without any config changes. Found ajaxresponse22.js deleted and ajaxresponse.js changed. And the behavior of repeated ajax calls is same. Can we have the config changes exactly if any in this manner? I checked 4160 and quickly not make out the config changes. <context-param> <param-name>xyz</param-name> <param-value>abc</param-value> </context-param>
Thanks & Regards,Dora Rajappan. On Sunday, October 8, 2017, 7:39:48 PM GMT+5:30, Werner Punz <we...@gmail.com> wrote:
No sync with Mojarra I have discussed that a while ago.
The problem is a licensing problem. Mojarra basically can use
our code but not vice versa, because the CDDL cannot be implemented in
ASF2 code.
The ASF2 license is a very liberal license, but due to the fact that it
is so liberal, it is impossible to integrate less liberal code in our
codebase.
As for your repeated Ajax problems MYFACES-4160 that is a really old
spec bug which reared its ugly head in multiform scenarii.
I worked around that by providing a special config param.
With JSF 2.3 it finally will be fixed.
Werner
Am 06.10.17 um 11:59 schrieb Dora Rajappan:
> Thanks for detailing the future of browser and how jsf cope up with it.
>
> I was using mojarra for my application and the commandLink was not
> working due to script problem.
> So I switched to myfaces and we got some problem with repeated ajax
> calls. (Myfaces 4160).
>
> Are we syncing with mojarra regarding the technology to be used with the
> jsf.js, entire scripting arena.
> Not sure spec say anything about the technology used for scripting.
>
> Thanks & Regards,
> Dora Rajappan.
Re: jsf.js post 2.3 plans
Posted by Werner Punz <we...@gmail.com>.
No sync with Mojarra I have discussed that a while ago.
The problem is a licensing problem. Mojarra basically can use
our code but not vice versa, because the CDDL cannot be implemented in
ASF2 code.
The ASF2 license is a very liberal license, but due to the fact that it
is so liberal, it is impossible to integrate less liberal code in our
codebase.
As for your repeated Ajax problems MYFACES-4160 that is a really old
spec bug which reared its ugly head in multiform scenarii.
I worked around that by providing a special config param.
With JSF 2.3 it finally will be fixed.
Werner
Am 06.10.17 um 11:59 schrieb Dora Rajappan:
> Thanks for detailing the future of browser and how jsf cope up with it.
>
> I was using mojarra for my application and the commandLink was not
> working due to script problem.
> So I switched to myfaces and we got some problem with repeated ajax
> calls. (Myfaces 4160).
>
> Are we syncing with mojarra regarding the technology to be used with the
> jsf.js, entire scripting arena.
> Not sure spec say anything about the technology used for scripting.
>
> Thanks & Regards,
> Dora Rajappan.
Re: jsf.js post 2.3 plans
Posted by Dora Rajappan <do...@yahoo.com>.
Thanks for detailing the future of browser and how jsf cope up with it.
I was using mojarra for my application and the commandLink was not working due to script problem.So I switched to myfaces and we got some problem with repeated ajax calls. (Myfaces 4160).
Are we syncing with mojarra regarding the technology to be used with the jsf.js, entire scripting arena.Not sure spec say anything about the technology used for scripting.
Thanks & Regards,Dora Rajappan.
On Thursday, October 5, 2017, 11:32:23 PM GMT+5:30, Thomas Andraschko <an...@gmail.com> wrote:
yep. +1 for IE11 in JSF.next
2017-10-05 14:36 GMT+02:00 Werner Punz <we...@gmail.com>:
Yeah given the timeframe, I guess IE11 is perfectly fine. We cannot
expect JSF 2.4 to hit the final spec before 2019, by then even
corporate support of Windows 7 will come to an end.
The main problem I see is that we probably will be stuck with supporting
IE11 for many years, since Microsoft still basically packs it in with every windows 10 sort of as secondary browser. So IE11 support will die about 10 years after Microsoft stops doing it.
And believe me even IE11
is currently the bottom barrely quality and speedwise you currently get
in the browser space. Even frameworks like Angular 1 basically drive the IE11 engine to its limits, the more shims you add it the bigger the browser becomes as a problem in day to day development.
I guess we once will hit the point where we will say we cannot support it anymore. Not now not in 2 years but sometime in the future.
Werner
Am 05.10.17 um 14:12 schrieb Mike Kienenberger:
I think it's ok for us to say that the baseline is IE11. If you are
concerned, take a poll on the users list.
On Thu, Oct 5, 2017 at 3:43 AM, Thomas Andraschko
<an...@gmail.com> wrote:
Hi Werner,
big +1 for doing a completely new jsf.js!
Basically it would be really great to use another lang as plain js.
But there is also another downside: most webdevelopers and commiters of
MyFaces are fimilar with plain js but maybe not with TypeScript or else.
But i think we should do it if can we can easily integrate it somehow in our
maven builds.
My personal opinion is that i would prefer plain js if the developers must
install nodejs etc. on their machines. If everything is done by maven in the
background, it's ok for me.
As you already said, we actually must avoid dependencies like kotlin.js and
jquery.js - thats a no go and also not really required.
Regards,
Thomas
2017-10-05 9:19 GMT+02:00 Werner Punz <we...@gmail.com>:
Hi guys
I just wanted to start a discussion on how we are going to proceed with
the jsf.js codebase.
The issue is following:
Our codebase which currently is adapted by me for 2.3 is rather old.
It by now is around 9-10 years old and back then most of the stuff I did
made sense
a) The library needed to be self contained
b) There were an awful lot of browsers in use, which did not adhere to any
standards whatsoever
c) There was no real inheritance system available just the prototype
system which is one level below inheritance by allowing to access the
class/object tree and manipulate it on the fly
So what I did was following
Implement my own class system for not having to deal with prototype
inheritance all the time
Since I needed to be self contained integrating a library like JQuery
(which also was it its infancy at that time) was out of the question
due to possible conflicts. There also was no widespread support
for querySelector on node level some browsers had it some browsers
had other workarounds to speed the dom node lookup up.
Also no unified ajax handling, the ajax api was at its infancy and I still
had to support the archaic IE way of doing things.
To the worse there were significant differences in dom and xml handling
between the various browsers out in the wild compared to the already
defined standards (I am speaking of you IE and mobile browsers in use back
then)
So in the end I ended up with a codebase which is about 40-50% there just
to support legacy browsers. While I did some work to isolate the quirks code
and compile it out of the codebase there still is work to be done.
Again all of this made sense back then...
Lots of things have been changed in those 10 years and now most of the
things do not make sense anymore.
a) We have saner meta languages which allow to compile to javascript,
following candidates come to my mind
- Typescript, a language which I amn very familiar with due to my day to
day work
- Coffeescript ... not very familiar with that one
- Kotlin... yes that one also has a javascript target compiler
We definitely should opt for a meta compiler instead of pure js.
The reasons are many, and I can speak here atm only for Typescript
- You can change ecma script levels on build level
- You can change the package management system in build level
- You get additional coding security by having the apis fortified at least
with some types instead of doing constantly your manual asserts
- In the end the Meta language codebase is way cleaner than the original
one
The downside is
at least for typescript the maven integration is non existent, there is a
maven clientside plugin which downloads the entire node js chain onto your
machine within a build, but my guess is we do not need to do this
for the apache integration builds, because in the end we just need the js
codebase. We can add special dev profile which enables the client side build
to build the js files.
As for Kotlin, I have not evalauted their javascript stuff but what put me
off was that the website said you have to integrate kotlin.js which is a no
go, but this depends, if kotlin.js just implements their runtime lib we can
probably bypass that. I need to have a serious look at it.
The plus side probably is that it has decent maven support and a perfect
IDE support on the Jetbrains IDEs. (Dont get me wrong the IDE support
of Typescript also is very good on those, I use it on a daily base)
Browser support:
Since mobile browsers are up to rather recent standards nowadays the
problem is the desktop which at least in a corporate environment is moving
really slowly (I wonder corporations are really cautious regarding security
and yet often use stone old often outdated not updated anymore, browsers -
but that is just a snarky sidenote). But still there things have gotten
better.
From a browser support standpoint we probably can strip the support pre
IE9 level which means we finally at least can use a standard ajax api, ajax
multiform requests instead of the iframe hack I had to introduce for jsf
2.2.
I would prefer to have IE11 as baseline, given that most corporations
probably have frozen their environment on a Windows 7 IE11 baseline by now,
but I guess we have to drag at least IE9 with us with some third party lib
support.
By mildly adding small external libraries and avoiding shims
we might get a small query monadish api on top of node.selectorAll like
jquery.
I still would avoid to integrate jquery because we have a core lib
so everything integrated needs to be small. We do not have the luxury of
for instance Prime Faces which can require or bundle a huge lib like JQuery
and JQuery UI.
Also we definitely would need promises (again rip the code out of a proven
shim lib but do not shim it, if it is not supported by the browser
natively)
So my proposal is, after 2.3 I will start with a reimplementation which
might take some time in a saner environment and with a newly defined
baseline.
And once I am done we can drop it in as alternative jsf.js codebase
for the users (we still keep the old one for 2.3)
And for 2.4 upwards we will drop the legacy codebase entirely and just
use the new reworked and cleaned up one.
Just a little bit of food for discussion.
Werner
Re: jsf.js post 2.3 plans
Posted by Thomas Andraschko <an...@gmail.com>.
yep. +1 for IE11 in JSF.next
2017-10-05 14:36 GMT+02:00 Werner Punz <we...@gmail.com>:
> Yeah given the timeframe, I guess IE11 is perfectly fine. We cannot
> expect JSF 2.4 to hit the final spec before 2019, by then even
> corporate support of Windows 7 will come to an end.
>
> The main problem I see is that we probably will be stuck with supporting
> IE11 for many years, since Microsoft still basically packs it in with
> every windows 10 sort of as secondary browser. So IE11 support will die
> about 10 years after Microsoft stops doing it.
>
> And believe me even IE11
> is currently the bottom barrely quality and speedwise you currently get
> in the browser space. Even frameworks like Angular 1 basically drive the
> IE11 engine to its limits, the more shims you add it the bigger the browser
> becomes as a problem in day to day development.
>
>
> I guess we once will hit the point where we will say we cannot support it
> anymore. Not now not in 2 years but sometime in the future.
>
>
> Werner
>
>
>
> Am 05.10.17 um 14:12 schrieb Mike Kienenberger:
>
> I think it's ok for us to say that the baseline is IE11. If you are
>> concerned, take a poll on the users list.
>>
>> On Thu, Oct 5, 2017 at 3:43 AM, Thomas Andraschko
>> <an...@gmail.com> wrote:
>>
>>> Hi Werner,
>>>
>>> big +1 for doing a completely new jsf.js!
>>>
>>> Basically it would be really great to use another lang as plain js.
>>> But there is also another downside: most webdevelopers and commiters of
>>> MyFaces are fimilar with plain js but maybe not with TypeScript or else.
>>> But i think we should do it if can we can easily integrate it somehow in
>>> our
>>> maven builds.
>>> My personal opinion is that i would prefer plain js if the developers
>>> must
>>> install nodejs etc. on their machines. If everything is done by maven in
>>> the
>>> background, it's ok for me.
>>>
>>> As you already said, we actually must avoid dependencies like kotlin.js
>>> and
>>> jquery.js - thats a no go and also not really required.
>>>
>>> Regards,
>>> Thomas
>>>
>>>
>>>
>>> 2017-10-05 9:19 GMT+02:00 Werner Punz <we...@gmail.com>:
>>>
>>>>
>>>> Hi guys
>>>>
>>>>
>>>> I just wanted to start a discussion on how we are going to proceed with
>>>> the jsf.js codebase.
>>>> The issue is following:
>>>>
>>>> Our codebase which currently is adapted by me for 2.3 is rather old.
>>>> It by now is around 9-10 years old and back then most of the stuff I did
>>>> made sense
>>>> a) The library needed to be self contained
>>>> b) There were an awful lot of browsers in use, which did not adhere to
>>>> any
>>>> standards whatsoever
>>>> c) There was no real inheritance system available just the prototype
>>>> system which is one level below inheritance by allowing to access the
>>>> class/object tree and manipulate it on the fly
>>>>
>>>> So what I did was following
>>>> Implement my own class system for not having to deal with prototype
>>>> inheritance all the time
>>>> Since I needed to be self contained integrating a library like JQuery
>>>> (which also was it its infancy at that time) was out of the question
>>>> due to possible conflicts. There also was no widespread support
>>>> for querySelector on node level some browsers had it some browsers
>>>> had other workarounds to speed the dom node lookup up.
>>>>
>>>> Also no unified ajax handling, the ajax api was at its infancy and I
>>>> still
>>>> had to support the archaic IE way of doing things.
>>>>
>>>> To the worse there were significant differences in dom and xml handling
>>>> between the various browsers out in the wild compared to the already
>>>> defined standards (I am speaking of you IE and mobile browsers in use
>>>> back
>>>> then)
>>>>
>>>> So in the end I ended up with a codebase which is about 40-50% there
>>>> just
>>>> to support legacy browsers. While I did some work to isolate the quirks
>>>> code
>>>> and compile it out of the codebase there still is work to be done.
>>>>
>>>> Again all of this made sense back then...
>>>>
>>>>
>>>> Lots of things have been changed in those 10 years and now most of the
>>>> things do not make sense anymore.
>>>>
>>>> a) We have saner meta languages which allow to compile to javascript,
>>>> following candidates come to my mind
>>>>
>>>> - Typescript, a language which I amn very familiar with due to my day to
>>>> day work
>>>> - Coffeescript ... not very familiar with that one
>>>> - Kotlin... yes that one also has a javascript target compiler
>>>>
>>>> We definitely should opt for a meta compiler instead of pure js.
>>>> The reasons are many, and I can speak here atm only for Typescript
>>>>
>>>> - You can change ecma script levels on build level
>>>> - You can change the package management system in build level
>>>> - You get additional coding security by having the apis fortified at
>>>> least
>>>> with some types instead of doing constantly your manual asserts
>>>> - In the end the Meta language codebase is way cleaner than the original
>>>> one
>>>>
>>>>
>>>> The downside is
>>>>
>>>>
>>>> at least for typescript the maven integration is non existent, there is
>>>> a
>>>> maven clientside plugin which downloads the entire node js chain onto
>>>> your
>>>> machine within a build, but my guess is we do not need to do this
>>>> for the apache integration builds, because in the end we just need the
>>>> js
>>>> codebase. We can add special dev profile which enables the client side
>>>> build
>>>> to build the js files.
>>>>
>>>> As for Kotlin, I have not evalauted their javascript stuff but what put
>>>> me
>>>> off was that the website said you have to integrate kotlin.js which is
>>>> a no
>>>> go, but this depends, if kotlin.js just implements their runtime lib we
>>>> can
>>>> probably bypass that. I need to have a serious look at it.
>>>>
>>>> The plus side probably is that it has decent maven support and a perfect
>>>> IDE support on the Jetbrains IDEs. (Dont get me wrong the IDE support
>>>> of Typescript also is very good on those, I use it on a daily base)
>>>>
>>>>
>>>> Browser support:
>>>>
>>>> Since mobile browsers are up to rather recent standards nowadays the
>>>> problem is the desktop which at least in a corporate environment is
>>>> moving
>>>> really slowly (I wonder corporations are really cautious regarding
>>>> security
>>>> and yet often use stone old often outdated not updated anymore,
>>>> browsers -
>>>> but that is just a snarky sidenote). But still there things have gotten
>>>> better.
>>>>
>>>> From a browser support standpoint we probably can strip the support pre
>>>> IE9 level which means we finally at least can use a standard ajax api,
>>>> ajax
>>>> multiform requests instead of the iframe hack I had to introduce for jsf
>>>> 2.2.
>>>>
>>>> I would prefer to have IE11 as baseline, given that most corporations
>>>> probably have frozen their environment on a Windows 7 IE11 baseline by
>>>> now,
>>>> but I guess we have to drag at least IE9 with us with some third party
>>>> lib
>>>> support.
>>>>
>>>> By mildly adding small external libraries and avoiding shims
>>>> we might get a small query monadish api on top of node.selectorAll like
>>>> jquery.
>>>>
>>>> I still would avoid to integrate jquery because we have a core lib
>>>> so everything integrated needs to be small. We do not have the luxury of
>>>> for instance Prime Faces which can require or bundle a huge lib like
>>>> JQuery
>>>> and JQuery UI.
>>>>
>>>> Also we definitely would need promises (again rip the code out of a
>>>> proven
>>>> shim lib but do not shim it, if it is not supported by the browser
>>>> natively)
>>>>
>>>> So my proposal is, after 2.3 I will start with a reimplementation which
>>>> might take some time in a saner environment and with a newly defined
>>>> baseline.
>>>> And once I am done we can drop it in as alternative jsf.js codebase
>>>> for the users (we still keep the old one for 2.3)
>>>> And for 2.4 upwards we will drop the legacy codebase entirely and just
>>>> use the new reworked and cleaned up one.
>>>>
>>>>
>>>> Just a little bit of food for discussion.
>>>>
>>>> Werner
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>
>
Re: jsf.js post 2.3 plans
Posted by Werner Punz <we...@gmail.com>.
Yeah given the timeframe, I guess IE11 is perfectly fine. We cannot
expect JSF 2.4 to hit the final spec before 2019, by then even
corporate support of Windows 7 will come to an end.
The main problem I see is that we probably will be stuck with supporting
IE11 for many years, since Microsoft still basically packs it in with
every windows 10 sort of as secondary browser. So IE11 support will die
about 10 years after Microsoft stops doing it.
And believe me even IE11
is currently the bottom barrely quality and speedwise you currently get
in the browser space. Even frameworks like Angular 1 basically drive the
IE11 engine to its limits, the more shims you add it the bigger the
browser becomes as a problem in day to day development.
I guess we once will hit the point where we will say we cannot support
it anymore. Not now not in 2 years but sometime in the future.
Werner
Am 05.10.17 um 14:12 schrieb Mike Kienenberger:
> I think it's ok for us to say that the baseline is IE11. If you are
> concerned, take a poll on the users list.
>
> On Thu, Oct 5, 2017 at 3:43 AM, Thomas Andraschko
> <an...@gmail.com> wrote:
>> Hi Werner,
>>
>> big +1 for doing a completely new jsf.js!
>>
>> Basically it would be really great to use another lang as plain js.
>> But there is also another downside: most webdevelopers and commiters of
>> MyFaces are fimilar with plain js but maybe not with TypeScript or else.
>> But i think we should do it if can we can easily integrate it somehow in our
>> maven builds.
>> My personal opinion is that i would prefer plain js if the developers must
>> install nodejs etc. on their machines. If everything is done by maven in the
>> background, it's ok for me.
>>
>> As you already said, we actually must avoid dependencies like kotlin.js and
>> jquery.js - thats a no go and also not really required.
>>
>> Regards,
>> Thomas
>>
>>
>>
>> 2017-10-05 9:19 GMT+02:00 Werner Punz <we...@gmail.com>:
>>>
>>> Hi guys
>>>
>>>
>>> I just wanted to start a discussion on how we are going to proceed with
>>> the jsf.js codebase.
>>> The issue is following:
>>>
>>> Our codebase which currently is adapted by me for 2.3 is rather old.
>>> It by now is around 9-10 years old and back then most of the stuff I did
>>> made sense
>>> a) The library needed to be self contained
>>> b) There were an awful lot of browsers in use, which did not adhere to any
>>> standards whatsoever
>>> c) There was no real inheritance system available just the prototype
>>> system which is one level below inheritance by allowing to access the
>>> class/object tree and manipulate it on the fly
>>>
>>> So what I did was following
>>> Implement my own class system for not having to deal with prototype
>>> inheritance all the time
>>> Since I needed to be self contained integrating a library like JQuery
>>> (which also was it its infancy at that time) was out of the question
>>> due to possible conflicts. There also was no widespread support
>>> for querySelector on node level some browsers had it some browsers
>>> had other workarounds to speed the dom node lookup up.
>>>
>>> Also no unified ajax handling, the ajax api was at its infancy and I still
>>> had to support the archaic IE way of doing things.
>>>
>>> To the worse there were significant differences in dom and xml handling
>>> between the various browsers out in the wild compared to the already
>>> defined standards (I am speaking of you IE and mobile browsers in use back
>>> then)
>>>
>>> So in the end I ended up with a codebase which is about 40-50% there just
>>> to support legacy browsers. While I did some work to isolate the quirks code
>>> and compile it out of the codebase there still is work to be done.
>>>
>>> Again all of this made sense back then...
>>>
>>>
>>> Lots of things have been changed in those 10 years and now most of the
>>> things do not make sense anymore.
>>>
>>> a) We have saner meta languages which allow to compile to javascript,
>>> following candidates come to my mind
>>>
>>> - Typescript, a language which I amn very familiar with due to my day to
>>> day work
>>> - Coffeescript ... not very familiar with that one
>>> - Kotlin... yes that one also has a javascript target compiler
>>>
>>> We definitely should opt for a meta compiler instead of pure js.
>>> The reasons are many, and I can speak here atm only for Typescript
>>>
>>> - You can change ecma script levels on build level
>>> - You can change the package management system in build level
>>> - You get additional coding security by having the apis fortified at least
>>> with some types instead of doing constantly your manual asserts
>>> - In the end the Meta language codebase is way cleaner than the original
>>> one
>>>
>>>
>>> The downside is
>>>
>>>
>>> at least for typescript the maven integration is non existent, there is a
>>> maven clientside plugin which downloads the entire node js chain onto your
>>> machine within a build, but my guess is we do not need to do this
>>> for the apache integration builds, because in the end we just need the js
>>> codebase. We can add special dev profile which enables the client side build
>>> to build the js files.
>>>
>>> As for Kotlin, I have not evalauted their javascript stuff but what put me
>>> off was that the website said you have to integrate kotlin.js which is a no
>>> go, but this depends, if kotlin.js just implements their runtime lib we can
>>> probably bypass that. I need to have a serious look at it.
>>>
>>> The plus side probably is that it has decent maven support and a perfect
>>> IDE support on the Jetbrains IDEs. (Dont get me wrong the IDE support
>>> of Typescript also is very good on those, I use it on a daily base)
>>>
>>>
>>> Browser support:
>>>
>>> Since mobile browsers are up to rather recent standards nowadays the
>>> problem is the desktop which at least in a corporate environment is moving
>>> really slowly (I wonder corporations are really cautious regarding security
>>> and yet often use stone old often outdated not updated anymore, browsers -
>>> but that is just a snarky sidenote). But still there things have gotten
>>> better.
>>>
>>> From a browser support standpoint we probably can strip the support pre
>>> IE9 level which means we finally at least can use a standard ajax api, ajax
>>> multiform requests instead of the iframe hack I had to introduce for jsf
>>> 2.2.
>>>
>>> I would prefer to have IE11 as baseline, given that most corporations
>>> probably have frozen their environment on a Windows 7 IE11 baseline by now,
>>> but I guess we have to drag at least IE9 with us with some third party lib
>>> support.
>>>
>>> By mildly adding small external libraries and avoiding shims
>>> we might get a small query monadish api on top of node.selectorAll like
>>> jquery.
>>>
>>> I still would avoid to integrate jquery because we have a core lib
>>> so everything integrated needs to be small. We do not have the luxury of
>>> for instance Prime Faces which can require or bundle a huge lib like JQuery
>>> and JQuery UI.
>>>
>>> Also we definitely would need promises (again rip the code out of a proven
>>> shim lib but do not shim it, if it is not supported by the browser
>>> natively)
>>>
>>> So my proposal is, after 2.3 I will start with a reimplementation which
>>> might take some time in a saner environment and with a newly defined
>>> baseline.
>>> And once I am done we can drop it in as alternative jsf.js codebase
>>> for the users (we still keep the old one for 2.3)
>>> And for 2.4 upwards we will drop the legacy codebase entirely and just
>>> use the new reworked and cleaned up one.
>>>
>>>
>>> Just a little bit of food for discussion.
>>>
>>> Werner
>>>
>>>
>>>
>>>
>>>
>>
>
Re: jsf.js post 2.3 plans
Posted by Mike Kienenberger <mk...@gmail.com>.
I think it's ok for us to say that the baseline is IE11. If you are
concerned, take a poll on the users list.
On Thu, Oct 5, 2017 at 3:43 AM, Thomas Andraschko
<an...@gmail.com> wrote:
> Hi Werner,
>
> big +1 for doing a completely new jsf.js!
>
> Basically it would be really great to use another lang as plain js.
> But there is also another downside: most webdevelopers and commiters of
> MyFaces are fimilar with plain js but maybe not with TypeScript or else.
> But i think we should do it if can we can easily integrate it somehow in our
> maven builds.
> My personal opinion is that i would prefer plain js if the developers must
> install nodejs etc. on their machines. If everything is done by maven in the
> background, it's ok for me.
>
> As you already said, we actually must avoid dependencies like kotlin.js and
> jquery.js - thats a no go and also not really required.
>
> Regards,
> Thomas
>
>
>
> 2017-10-05 9:19 GMT+02:00 Werner Punz <we...@gmail.com>:
>>
>> Hi guys
>>
>>
>> I just wanted to start a discussion on how we are going to proceed with
>> the jsf.js codebase.
>> The issue is following:
>>
>> Our codebase which currently is adapted by me for 2.3 is rather old.
>> It by now is around 9-10 years old and back then most of the stuff I did
>> made sense
>> a) The library needed to be self contained
>> b) There were an awful lot of browsers in use, which did not adhere to any
>> standards whatsoever
>> c) There was no real inheritance system available just the prototype
>> system which is one level below inheritance by allowing to access the
>> class/object tree and manipulate it on the fly
>>
>> So what I did was following
>> Implement my own class system for not having to deal with prototype
>> inheritance all the time
>> Since I needed to be self contained integrating a library like JQuery
>> (which also was it its infancy at that time) was out of the question
>> due to possible conflicts. There also was no widespread support
>> for querySelector on node level some browsers had it some browsers
>> had other workarounds to speed the dom node lookup up.
>>
>> Also no unified ajax handling, the ajax api was at its infancy and I still
>> had to support the archaic IE way of doing things.
>>
>> To the worse there were significant differences in dom and xml handling
>> between the various browsers out in the wild compared to the already
>> defined standards (I am speaking of you IE and mobile browsers in use back
>> then)
>>
>> So in the end I ended up with a codebase which is about 40-50% there just
>> to support legacy browsers. While I did some work to isolate the quirks code
>> and compile it out of the codebase there still is work to be done.
>>
>> Again all of this made sense back then...
>>
>>
>> Lots of things have been changed in those 10 years and now most of the
>> things do not make sense anymore.
>>
>> a) We have saner meta languages which allow to compile to javascript,
>> following candidates come to my mind
>>
>> - Typescript, a language which I amn very familiar with due to my day to
>> day work
>> - Coffeescript ... not very familiar with that one
>> - Kotlin... yes that one also has a javascript target compiler
>>
>> We definitely should opt for a meta compiler instead of pure js.
>> The reasons are many, and I can speak here atm only for Typescript
>>
>> - You can change ecma script levels on build level
>> - You can change the package management system in build level
>> - You get additional coding security by having the apis fortified at least
>> with some types instead of doing constantly your manual asserts
>> - In the end the Meta language codebase is way cleaner than the original
>> one
>>
>>
>> The downside is
>>
>>
>> at least for typescript the maven integration is non existent, there is a
>> maven clientside plugin which downloads the entire node js chain onto your
>> machine within a build, but my guess is we do not need to do this
>> for the apache integration builds, because in the end we just need the js
>> codebase. We can add special dev profile which enables the client side build
>> to build the js files.
>>
>> As for Kotlin, I have not evalauted their javascript stuff but what put me
>> off was that the website said you have to integrate kotlin.js which is a no
>> go, but this depends, if kotlin.js just implements their runtime lib we can
>> probably bypass that. I need to have a serious look at it.
>>
>> The plus side probably is that it has decent maven support and a perfect
>> IDE support on the Jetbrains IDEs. (Dont get me wrong the IDE support
>> of Typescript also is very good on those, I use it on a daily base)
>>
>>
>> Browser support:
>>
>> Since mobile browsers are up to rather recent standards nowadays the
>> problem is the desktop which at least in a corporate environment is moving
>> really slowly (I wonder corporations are really cautious regarding security
>> and yet often use stone old often outdated not updated anymore, browsers -
>> but that is just a snarky sidenote). But still there things have gotten
>> better.
>>
>> From a browser support standpoint we probably can strip the support pre
>> IE9 level which means we finally at least can use a standard ajax api, ajax
>> multiform requests instead of the iframe hack I had to introduce for jsf
>> 2.2.
>>
>> I would prefer to have IE11 as baseline, given that most corporations
>> probably have frozen their environment on a Windows 7 IE11 baseline by now,
>> but I guess we have to drag at least IE9 with us with some third party lib
>> support.
>>
>> By mildly adding small external libraries and avoiding shims
>> we might get a small query monadish api on top of node.selectorAll like
>> jquery.
>>
>> I still would avoid to integrate jquery because we have a core lib
>> so everything integrated needs to be small. We do not have the luxury of
>> for instance Prime Faces which can require or bundle a huge lib like JQuery
>> and JQuery UI.
>>
>> Also we definitely would need promises (again rip the code out of a proven
>> shim lib but do not shim it, if it is not supported by the browser
>> natively)
>>
>> So my proposal is, after 2.3 I will start with a reimplementation which
>> might take some time in a saner environment and with a newly defined
>> baseline.
>> And once I am done we can drop it in as alternative jsf.js codebase
>> for the users (we still keep the old one for 2.3)
>> And for 2.4 upwards we will drop the legacy codebase entirely and just
>> use the new reworked and cleaned up one.
>>
>>
>> Just a little bit of food for discussion.
>>
>> Werner
>>
>>
>>
>>
>>
>
Re: jsf.js post 2.3 plans
Posted by Werner Punz <we...@gmail.com>.
I am not very eager anymore to use plain js
especially since we have to target ES5.
Even if we use ES6 we need to recompile back into ES6.
The reason why I moved the codebase over to Typescript
from my day to day work, was that the language thanks to Angular2
got enough foodhold to be used by a wider audience and it
really improves the code a lot thanks to rather sane extensions
to the Javascript.
In fact I personally think, a bigger JS Codebase is almost
unmaintainable in the long term if you dont move it to a higher level or
pull some third party libs in thanks to the dynamic untyped nature of
the languate. You still can cover a lot of issues by extensive unit
testing, but still the language is totally untyped and allows you
literally to change anything anywhere.
And Typescript is close enough and well documented enough that moving up
is a no brainer.
Typescript is more or less just a JavaScript ++.
In the end the result always is javascript, so even if a bug is just
investigated and sent back on plain javascript level it is easy to trace
it back to the typescript origins (either via mapping files which show
the bug straight in the browser as typescript or simply by looking up
the code)
As for Kotlin, this one also gets a wide adoption atm, thanks to Android
but i have a little bit of stomac ache due to the kotlin.js issue
and due to the fact that you cannot trace the js code back as easily as
you can do on the typescript side.
Also it is a totally different abstraction layer.
Am 05.10.17 um 09:43 schrieb Thomas Andraschko:
> Hi Werner,
>
> big +1 for doing a completely new jsf.js!
>
> Basically it would be really great to use another lang as plain js.
> But there is also another downside: most webdevelopers and commiters of
> MyFaces are fimilar with plain js but maybe not with TypeScript or else.
> But i think we should do it if can we can easily integrate it somehow in
> our maven builds.
> My personal opinion is that i would prefer plain js if the developers
> must install nodejs etc. on their machines. If everything is done by
> maven in the background, it's ok for me.
>
> As you already said, we actually must avoid dependencies like kotlin.js
> and jquery.js - thats a no go and also not really required.
>
> Regards,
> Thomas
>
>
>
> 2017-10-05 9:19 GMT+02:00 Werner Punz <werner.punz@gmail.com
> <ma...@gmail.com>>:
>
> Hi guys
>
>
> I just wanted to start a discussion on how we are going to proceed
> with the jsf.js codebase.
> The issue is following:
>
> Our codebase which currently is adapted by me for 2.3 is rather old.
> It by now is around 9-10 years old and back then most of the stuff I
> did made sense
> a) The library needed to be self contained
> b) There were an awful lot of browsers in use, which did not adhere
> to any standards whatsoever
> c) There was no real inheritance system available just the prototype
> system which is one level below inheritance by allowing to access
> the class/object tree and manipulate it on the fly
>
> So what I did was following
> Implement my own class system for not having to deal with prototype
> inheritance all the time
> Since I needed to be self contained integrating a library like
> JQuery (which also was it its infancy at that time) was out of the
> question
> due to possible conflicts. There also was no widespread support
> for querySelector on node level some browsers had it some browsers
> had other workarounds to speed the dom node lookup up.
>
> Also no unified ajax handling, the ajax api was at its infancy and I
> still had to support the archaic IE way of doing things.
>
> To the worse there were significant differences in dom and xml handling
> between the various browsers out in the wild compared to the already
> defined standards (I am speaking of you IE and mobile browsers in
> use back then)
>
> So in the end I ended up with a codebase which is about 40-50% there
> just to support legacy browsers. While I did some work to isolate
> the quirks code and compile it out of the codebase there still is
> work to be done.
>
> Again all of this made sense back then...
>
>
> Lots of things have been changed in those 10 years and now most of
> the things do not make sense anymore.
>
> a) We have saner meta languages which allow to compile to
> javascript, following candidates come to my mind
>
> - Typescript, a language which I amn very familiar with due to my
> day to day work
> - Coffeescript ... not very familiar with that one
> - Kotlin... yes that one also has a javascript target compiler
>
> We definitely should opt for a meta compiler instead of pure js.
> The reasons are many, and I can speak here atm only for Typescript
>
> - You can change ecma script levels on build level
> - You can change the package management system in build level
> - You get additional coding security by having the apis fortified at
> least with some types instead of doing constantly your manual asserts
> - In the end the Meta language codebase is way cleaner than the
> original one
>
>
> The downside is
>
>
> at least for typescript the maven integration is non existent, there
> is a maven clientside plugin which downloads the entire node js
> chain onto your machine within a build, but my guess is we do not
> need to do this
> for the apache integration builds, because in the end we just need
> the js codebase. We can add special dev profile which enables the
> client side build to build the js files.
>
> As for Kotlin, I have not evalauted their javascript stuff but what
> put me off was that the website said you have to integrate kotlin.js
> which is a no go, but this depends, if kotlin.js just implements
> their runtime lib we can probably bypass that. I need to have a
> serious look at it.
>
> The plus side probably is that it has decent maven support and a
> perfect IDE support on the Jetbrains IDEs. (Dont get me wrong the
> IDE support
> of Typescript also is very good on those, I use it on a daily base)
>
>
> Browser support:
>
> Since mobile browsers are up to rather recent standards nowadays the
> problem is the desktop which at least in a corporate environment is
> moving really slowly (I wonder corporations are really cautious
> regarding security and yet often use stone old often outdated not
> updated anymore, browsers - but that is just a snarky sidenote). But
> still there things have gotten better.
>
> From a browser support standpoint we probably can strip the support
> pre IE9 level which means we finally at least can use a standard
> ajax api, ajax multiform requests instead of the iframe hack I had
> to introduce for jsf 2.2.
>
> I would prefer to have IE11 as baseline, given that most
> corporations probably have frozen their environment on a Windows 7
> IE11 baseline by now, but I guess we have to drag at least IE9 with
> us with some third party lib support.
>
> By mildly adding small external libraries and avoiding shims
> we might get a small query monadish api on top of node.selectorAll
> like jquery.
>
> I still would avoid to integrate jquery because we have a core lib
> so everything integrated needs to be small. We do not have the
> luxury of for instance Prime Faces which can require or bundle a
> huge lib like JQuery and JQuery UI.
>
> Also we definitely would need promises (again rip the code out of a
> proven shim lib but do not shim it, if it is not supported by the
> browser natively)
>
> So my proposal is, after 2.3 I will start with a reimplementation
> which might take some time in a saner environment and with a newly
> defined baseline.
> And once I am done we can drop it in as alternative jsf.js codebase
> for the users (we still keep the old one for 2.3)
> And for 2.4 upwards we will drop the legacy codebase entirely and just
> use the new reworked and cleaned up one.
>
>
> Just a little bit of food for discussion.
>
> Werner
>
>
>
>
>
>
Re: jsf.js post 2.3 plans
Posted by Thomas Andraschko <an...@gmail.com>.
Hi Werner,
big +1 for doing a completely new jsf.js!
Basically it would be really great to use another lang as plain js.
But there is also another downside: most webdevelopers and commiters of
MyFaces are fimilar with plain js but maybe not with TypeScript or else.
But i think we should do it if can we can easily integrate it somehow in
our maven builds.
My personal opinion is that i would prefer plain js if the developers must
install nodejs etc. on their machines. If everything is done by maven in
the background, it's ok for me.
As you already said, we actually must avoid dependencies like kotlin.js and
jquery.js - thats a no go and also not really required.
Regards,
Thomas
2017-10-05 9:19 GMT+02:00 Werner Punz <we...@gmail.com>:
> Hi guys
>
>
> I just wanted to start a discussion on how we are going to proceed with
> the jsf.js codebase.
> The issue is following:
>
> Our codebase which currently is adapted by me for 2.3 is rather old.
> It by now is around 9-10 years old and back then most of the stuff I did
> made sense
> a) The library needed to be self contained
> b) There were an awful lot of browsers in use, which did not adhere to any
> standards whatsoever
> c) There was no real inheritance system available just the prototype
> system which is one level below inheritance by allowing to access the
> class/object tree and manipulate it on the fly
>
> So what I did was following
> Implement my own class system for not having to deal with prototype
> inheritance all the time
> Since I needed to be self contained integrating a library like JQuery
> (which also was it its infancy at that time) was out of the question
> due to possible conflicts. There also was no widespread support
> for querySelector on node level some browsers had it some browsers
> had other workarounds to speed the dom node lookup up.
>
> Also no unified ajax handling, the ajax api was at its infancy and I still
> had to support the archaic IE way of doing things.
>
> To the worse there were significant differences in dom and xml handling
> between the various browsers out in the wild compared to the already
> defined standards (I am speaking of you IE and mobile browsers in use back
> then)
>
> So in the end I ended up with a codebase which is about 40-50% there just
> to support legacy browsers. While I did some work to isolate the quirks
> code and compile it out of the codebase there still is work to be done.
>
> Again all of this made sense back then...
>
>
> Lots of things have been changed in those 10 years and now most of the
> things do not make sense anymore.
>
> a) We have saner meta languages which allow to compile to javascript,
> following candidates come to my mind
>
> - Typescript, a language which I amn very familiar with due to my day to
> day work
> - Coffeescript ... not very familiar with that one
> - Kotlin... yes that one also has a javascript target compiler
>
> We definitely should opt for a meta compiler instead of pure js.
> The reasons are many, and I can speak here atm only for Typescript
>
> - You can change ecma script levels on build level
> - You can change the package management system in build level
> - You get additional coding security by having the apis fortified at least
> with some types instead of doing constantly your manual asserts
> - In the end the Meta language codebase is way cleaner than the original
> one
>
>
> The downside is
>
>
> at least for typescript the maven integration is non existent, there is a
> maven clientside plugin which downloads the entire node js chain onto your
> machine within a build, but my guess is we do not need to do this
> for the apache integration builds, because in the end we just need the js
> codebase. We can add special dev profile which enables the client side
> build to build the js files.
>
> As for Kotlin, I have not evalauted their javascript stuff but what put me
> off was that the website said you have to integrate kotlin.js which is a no
> go, but this depends, if kotlin.js just implements their runtime lib we can
> probably bypass that. I need to have a serious look at it.
>
> The plus side probably is that it has decent maven support and a perfect
> IDE support on the Jetbrains IDEs. (Dont get me wrong the IDE support
> of Typescript also is very good on those, I use it on a daily base)
>
>
> Browser support:
>
> Since mobile browsers are up to rather recent standards nowadays the
> problem is the desktop which at least in a corporate environment is moving
> really slowly (I wonder corporations are really cautious regarding security
> and yet often use stone old often outdated not updated anymore, browsers -
> but that is just a snarky sidenote). But still there things have gotten
> better.
>
> From a browser support standpoint we probably can strip the support pre
> IE9 level which means we finally at least can use a standard ajax api, ajax
> multiform requests instead of the iframe hack I had to introduce for jsf
> 2.2.
>
> I would prefer to have IE11 as baseline, given that most corporations
> probably have frozen their environment on a Windows 7 IE11 baseline by now,
> but I guess we have to drag at least IE9 with us with some third party lib
> support.
>
> By mildly adding small external libraries and avoiding shims
> we might get a small query monadish api on top of node.selectorAll like
> jquery.
>
> I still would avoid to integrate jquery because we have a core lib
> so everything integrated needs to be small. We do not have the luxury of
> for instance Prime Faces which can require or bundle a huge lib like JQuery
> and JQuery UI.
>
> Also we definitely would need promises (again rip the code out of a proven
> shim lib but do not shim it, if it is not supported by the browser
> natively)
>
> So my proposal is, after 2.3 I will start with a reimplementation which
> might take some time in a saner environment and with a newly defined
> baseline.
> And once I am done we can drop it in as alternative jsf.js codebase
> for the users (we still keep the old one for 2.3)
> And for 2.4 upwards we will drop the legacy codebase entirely and just
> use the new reworked and cleaned up one.
>
>
> Just a little bit of food for discussion.
>
> Werner
>
>
>
>
>
>