+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 bui
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
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
wrote:
Just to clarify it:
Be
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 fo
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 c
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 i
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 kotl
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 i
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 regardin
yep. +1 for IE11 in JSF.next
2017-10-05 14:36 GMT+02:00 Werner Punz :
> 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
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 stil
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 w
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
wrote:
> Hi Werner,
>
> big +1 for doing a completely new jsf.js!
>
> Basically it would be really great to use another lang as plain j
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
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 librar
15 matches
Mail list logo
