Re: [VOTE] Release Apache MyFaces Ext-Scripting 1.0.6

[Werner Punz]

Ups Copy paste Error

 Hi,

 thank you for checking and voting for the release. The result is

 +1
 Werner Punz
 Udo Schnurpfeil
 Thomas Andraschko
 Nicola Cisternino [No Binding]

 Regards,

 Werner

PS: I should take my morning coffee, Again thanks to everyone who voted.



Am 06.10.17 um 08:27 schrieb Werner Punz:

Hi,

thank you for checking and voting for the release. The result is

+1
Werner Punz
Udo Schnurpfeil
Thomas Andraschko
Nicola Cisternino [No Binding]


so I will proceed with the next steps for the release.

Regards,

Udo





Am 05.10.17 um 09:20 schrieb Werner Punz:

Thanks guys, that was quick.

Cheers

Werner


Am 05.10.17 um 08:46 schrieb Werner Punz:

Hey guys I really would need additional votes here.
I know it is not the most important project under the myfaces umbrella
but I want to get this bugfix out.

Cheers

Werner


Am 03.10.17 um 13:31 schrieb Nicola Cisternino:

On 10/02/2017 09:53 PM, Werner Punz wrote:

Am 02.10.17 um 15:23 schrieb Werner Punz:

Hello,

I would like to release Apache MyFaces Ext Scripting 1.0.6.

This is a PATCH release with backwards-compatible bug fixes to 
myfaces 2.2.x.


For a detail list please consult the release notes at:

https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310964&version=12323748 




The version is available at the staging repository (Nexus) at:

https://repository.apache.org/content/repositories/orgapachemyfaces-1119 




Please vote now! (The vote is open for 72h.)

[ ] +1
[ ] +0
[ ] -1

Regards,
Werner

PS: Sorry for the delay regarding the release.







+1

Of course..

Werner



+1

Of course...

N.Cisternino

Re: [VOTE] Release Apache MyFaces Ext-Scripting 1.0.6

[Werner Punz]

Hi,

thank you for checking and voting for the release. The result is

+1
Werner Punz
Udo Schnurpfeil
Thomas Andraschko
Nicola Cisternino [No Binding]


so I will proceed with the next steps for the release.

Regards,

Udo





Am 05.10.17 um 09:20 schrieb Werner Punz:

Thanks guys, that was quick.

Cheers

Werner


Am 05.10.17 um 08:46 schrieb Werner Punz:

Hey guys I really would need additional votes here.
I know it is not the most important project under the myfaces umbrella
but I want to get this bugfix out.

Cheers

Werner


Am 03.10.17 um 13:31 schrieb Nicola Cisternino:

On 10/02/2017 09:53 PM, Werner Punz wrote:

Am 02.10.17 um 15:23 schrieb Werner Punz:

Hello,

I would like to release Apache MyFaces Ext Scripting 1.0.6.

This is a PATCH release with backwards-compatible bug fixes to 
myfaces 2.2.x.


For a detail list please consult the release notes at:

https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310964&version=12323748 




The version is available at the staging repository (Nexus) at:

https://repository.apache.org/content/repositories/orgapachemyfaces-1119 




Please vote now! (The vote is open for 72h.)

[ ] +1
[ ] +0
[ ] -1

Regards,
Werner

PS: Sorry for the delay regarding the release.







+1

Of course..

Werner



+1

Of course...

N.Cisternino

[jira] [Commented] (MYFACES-4153) h:selectOneRadio when rendered inside h:panelGroup which is right aligned stands out from the group

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16193446#comment-16193446
 ] 

Thomas Andraschko commented on MYFACES-4153:


What about a small example? There are many bean references in your code which i 
can't use. It's surely a small bug which can be replicated with a very small 
xhtml, without any beans.
JFYI: If you would provide a example with this quality in PF, i would just 
close the issue. If someone is willing to solve a issue in his freetime(!), i 
think can expect a good & small example, which shoudln't be much effort for you.

> h:selectOneRadio when rendered inside h:panelGroup which is right aligned 
> stands out from the group
> ---
>
> Key: MYFACES-4153
> URL: https://issues.apache.org/jira/browse/MYFACES-4153
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: General
>Affects Versions: 2.3.0-beta
>Reporter: Dora Rajappan
>Priority: Minor
> Attachments: login.xhtml
>
>
> h:selectOneRadio when rendered inside h:panelGroup which is right aligned 
> stands out from the group towards the left since it gets rendered as html 
> table. This is same behaviour for mojarra 2.2 also.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4154) The browser (chrome) always show the previous page name while its on the current page rendered properly

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16193443#comment-16193443
 ] 

Thomas Andraschko commented on MYFACES-4154:


What about a small example?

> The browser (chrome) always show the previous page name while its on the 
> current page rendered properly
> ---
>
> Key: MYFACES-4154
> URL: https://issues.apache.org/jira/browse/MYFACES-4154
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Dora Rajappan
>Priority: Minor
>
> The browser (chrome) always show the previous page name while its on the 
> current page rendered properly . This bug is already logged in jira not sure 
> of the bug id. Not sure its browser problem  or jsf. Not checked this with 
> mojarra also.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: jsf.js post 2.3 plans

[Thomas Andraschko]

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 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
>>  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 :
>>>

 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 ty

Re: jsf.js post 2.3 plans

[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 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
 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 :


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 imple

Re: jsf.js post 2.3 plans

[Werner Punz]

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 >:


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 asse

Re: jsf.js post 2.3 plans

[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
 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 :
>>
>> 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

[jira] [Commented] (TOBAGO-1795) Set Java Source to Java 8

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/TOBAGO-1795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16192602#comment-16192602
 ] 

Hudson commented on TOBAGO-1795:


SUCCESS: Integrated in Jenkins build Tobago Trunk #1059 (See 
[https://builds.apache.org/job/Tobago%20Trunk/1059/])
TOBAGO-1795: Set Java Source to Java 8 * remove compiler warnings: move 
(lofwyr: rev e93674ad22dc42d41d1eb31c6081eb41c3f42c68)
* (edit) 
tobago-tool/tobago-tool-apt/src/main/java/org/apache/myfaces/tobago/apt/processor/AbstractGenerator.java
* (edit) 
tobago-tool/tobago-tool-apt/src/main/java/org/apache/myfaces/tobago/apt/processor/ClassesGenerator.java
* (edit) 
tobago-tool/tobago-tool-apt/src/main/java/org/apache/myfaces/tobago/apt/processor/CheckstyleConfigGenerator.java
* (edit) 
tobago-tool/tobago-tool-apt/src/main/java/org/apache/myfaces/tobago/apt/processor/FacesConfigGenerator.java
* (edit) 
tobago-tool/tobago-tool-apt/src/main/java/org/apache/myfaces/tobago/apt/processor/TaglibGenerator.java


> Set Java Source to Java 8
> -
>
> Key: TOBAGO-1795
> URL: https://issues.apache.org/jira/browse/TOBAGO-1795
> Project: MyFaces Tobago
>  Issue Type: Task
>  Components: Build
>Reporter: Udo Schnurpfeil
>Assignee: Udo Schnurpfeil
> Fix For: 4.0.0
>
>
> This also implies the minimal runtime version to JDK 1.8



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: jsf.js post 2.3 plans

[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 :

> 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 I

Re: [VOTE] Release Apache MyFaces Ext-Scripting 1.0.6

[Werner Punz]

Thanks guys, that was quick.

Cheers

Werner


Am 05.10.17 um 08:46 schrieb Werner Punz:

Hey guys I really would need additional votes here.
I know it is not the most important project under the myfaces umbrella
but I want to get this bugfix out.

Cheers

Werner


Am 03.10.17 um 13:31 schrieb Nicola Cisternino:

On 10/02/2017 09:53 PM, Werner Punz wrote:

Am 02.10.17 um 15:23 schrieb Werner Punz:

Hello,

I would like to release Apache MyFaces Ext Scripting 1.0.6.

This is a PATCH release with backwards-compatible bug fixes to 
myfaces 2.2.x.


For a detail list please consult the release notes at:

https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310964&version=12323748 




The version is available at the staging repository (Nexus) at:

https://repository.apache.org/content/repositories/orgapachemyfaces-1119 




Please vote now! (The vote is open for 72h.)

[ ] +1
[ ] +0
[ ] -1

Regards,
Werner

PS: Sorry for the delay regarding the release.







+1

Of course..

Werner



+1

Of course...

N.Cisternino

jsf.js post 2.3 plans

[Werner Punz]

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 en

[jira] [Commented] (MYFACES-4160) ViewState not written for Ajax request

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16192541#comment-16192541
 ] 

Thomas Andraschko commented on MYFACES-4160:


cool! :)

> ViewState not written for Ajax request
> --
>
> Key: MYFACES-4160
> URL: https://issues.apache.org/jira/browse/MYFACES-4160
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Thomas Andraschko
>Assignee: Werner Punz
> Fix For: 2.3.0
>
>
> If you run the application from MYFACES-4156 via mvn jetty:run, the 
> viewStateId isn't rendered again after the first ajax request.
> Seems like FaceletViewDeclerationLanguage line 1910 should handle that but it 
> skips.
> [~lu4242] Could you please check that?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [VOTE] Release Apache MyFaces Ext-Scripting 1.0.6

[Thomas Andraschko]

+1

2017-10-05 9:05 GMT+02:00 Udo Schnurpfeil :

> +1
>
> Regards,
>
> Udo
>
> Am 03.10.17 um 13:29 schrieb Nicola Cisternino:
> > On 10/02/2017 09:53 PM, Werner Punz wrote:
> >> Am 02.10.17 um 15:23 schrieb Werner Punz:
> >>> Hello,
> >>>
> >>> I would like to release Apache MyFaces Ext Scripting 1.0.6.
> >>>
> >>> This is a PATCH release with backwards-compatible bug fixes to
> >>> myfaces 2.2.x.
> >>>
> >>> For a detail list please consult the release notes at:
> >>>
> >>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> projectId=12310964&version=12323748
> >>>
> >>>
> >>>
> >>> The version is available at the staging repository (Nexus) at:
> >>>
> >>> https://repository.apache.org/content/repositories/
> orgapachemyfaces-1119
> >>>
> >>>
> >>> Please vote now! (The vote is open for 72h.)
> >>>
> >>> [ ] +1
> >>> [ ] +0
> >>> [ ] -1
> >>>
> >>> Regards,
> >>> Werner
> >>>
> >>> PS: Sorry for the delay regarding the release.
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >> +1
> >>
> >> Of course..
> >>
> >> Werner
> >>
> >>
> >
> > +1
> >
> > Of course...
> >
> > N.Cisternino
> >
>

Re: [VOTE] Release Apache MyFaces Ext-Scripting 1.0.6

[Udo Schnurpfeil]

+1

Regards,

Udo

Am 03.10.17 um 13:29 schrieb Nicola Cisternino:
> On 10/02/2017 09:53 PM, Werner Punz wrote:
>> Am 02.10.17 um 15:23 schrieb Werner Punz:
>>> Hello,
>>>
>>> I would like to release Apache MyFaces Ext Scripting 1.0.6.
>>>
>>> This is a PATCH release with backwards-compatible bug fixes to
>>> myfaces 2.2.x.
>>>
>>> For a detail list please consult the release notes at:
>>>
>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310964&version=12323748
>>>
>>>
>>>
>>> The version is available at the staging repository (Nexus) at:
>>>
>>> https://repository.apache.org/content/repositories/orgapachemyfaces-1119
>>>
>>>
>>> Please vote now! (The vote is open for 72h.)
>>>
>>> [ ] +1
>>> [ ] +0
>>> [ ] -1
>>>
>>> Regards,
>>> Werner
>>>
>>> PS: Sorry for the delay regarding the release.
>>>
>>>
>>>
>>>
>>
>>
>> +1
>>
>> Of course..
>>
>> Werner
>>
>>
> 
> +1
> 
> Of course...
> 
> N.Cisternino
>