Re: JSF 2.3

[Matthew Broadhead]

Thanks Thomas.  Looking forward to trying it out

On 18/11/2017 13:16, Thomas Andraschko wrote:

1) I think we can ship 2.3.0 this year, there are only some issues left.
2) I would ask that the TomEE guys ;) I also think that TomEE is not ready
for a 8.0 release yet ;)

2017-11-18 12:43 GMT+01:00 Matthew Broadhead 

Re: JSF 2.3

[Thomas Andraschko]

1) I think we can ship 2.3.0 this year, there are only some issues left.
2) I would ask that the TomEE guys ;) I also think that TomEE is not ready
for a 8.0 release yet ;)

2017-11-18 12:43 GMT+01:00 Matthew Broadhead :

> Hi,
> When is 2.3 moving out of beta? https://github.com/apache/tome
> e/blob/fb_tomee8/pom.xml TomEE 8 is using MyFaces 2.2.12 but I thought it
> would be shipping with 2.3?
>

Re: JSF 2.3

[Thomas Andraschko]

If they add support for such actions with @RequestMapping, then it should
also be possible to declare request params as method params.
e.g.

@RequestMapping(...)
public void doSomething(@RequestParameter(name=..) private String test)


And of course conversion/validation of the request parameters.


2014/1/14 Karl Kildén karl.kil...@gmail.com

 Hello,

 Any opinions on this

 https://weblogs.java.net/blog/mriem/archive/2014/01/13/jsf-tip-56-using-action-based-prototype-mojarra

 Basically it's regarding the common opinon that JavaEE should have a action
 based framework or support a action based style in JSF.

 cheers

Re: JSF 2.3

[Christian Beikov]

Could you explain what the actual benefits of the action based 
programming style are? I am missing the purpose/use cases for the actual 
need of such a feature.


Thanks in advance!

Mit freundlichen Grüßen,

*Christian Beikov*
Am 14.01.2014 12:02, schrieb Thomas Andraschko:

If they add support for such actions with @RequestMapping, then it should
also be possible to declare request params as method params.
e.g.

@RequestMapping(...)
public void doSomething(@RequestParameter(name=..) private String test)


And of course conversion/validation of the request parameters.


2014/1/14 Karl Kildén karl.kil...@gmail.com


Hello,

Any opinions on this

https://weblogs.java.net/blog/mriem/archive/2014/01/13/jsf-tip-56-using-action-based-prototype-mojarra

Basically it's regarding the common opinon that JavaEE should have a action
based framework or support a action based style in JSF.

cheers

Re: JSF 2.3

[Karl Kildén]

Action based vs component based is a frequently discussed topic and you can
probably find many resources arguing for one or the other.

I really like JSF but I am still curious about stuff like this. For example
if I want to use a third part javascript library for special corner cases
it might be a good thing?

I don't know but I'm very interested in others opinions.

Thomas, useful for you?


On 14 January 2014 12:24, Christian Beikov christian.bei...@gmail.comwrote:

 Could you explain what the actual benefits of the action based programming
 style are? I am missing the purpose/use cases for the actual need of such a
 feature.

 Thanks in advance!

 Mit freundlichen Grüßen,
 
 *Christian Beikov*
 Am 14.01.2014 12:02, schrieb Thomas Andraschko:

  If they add support for such actions with @RequestMapping, then it should
 also be possible to declare request params as method params.
 e.g.

 @RequestMapping(...)
 public void doSomething(@RequestParameter(name=..) private String test)


 And of course conversion/validation of the request parameters.


 2014/1/14 Karl Kildén karl.kil...@gmail.com

  Hello,

 Any opinions on this

 https://weblogs.java.net/blog/mriem/archive/2014/01/13/jsf-
 tip-56-using-action-based-prototype-mojarra

 Basically it's regarding the common opinon that JavaEE should have a
 action
 based framework or support a action based style in JSF.

 cheers

Re: JSF 2.3

[Thomas Andraschko]

Not really but it's just matter of taste ;)


2014/1/14 Karl Kildén karl.kil...@gmail.com

 Action based vs component based is a frequently discussed topic and you can
 probably find many resources arguing for one or the other.

 I really like JSF but I am still curious about stuff like this. For example
 if I want to use a third part javascript library for special corner cases
 it might be a good thing?

 I don't know but I'm very interested in others opinions.

 Thomas, useful for you?


 On 14 January 2014 12:24, Christian Beikov christian.bei...@gmail.com
 wrote:

  Could you explain what the actual benefits of the action based
 programming
  style are? I am missing the purpose/use cases for the actual need of
 such a
  feature.
 
  Thanks in advance!
 
  Mit freundlichen Grüßen,
  
  *Christian Beikov*
  Am 14.01.2014 12:02, schrieb Thomas Andraschko:
 
   If they add support for such actions with @RequestMapping, then it
 should
  also be possible to declare request params as method params.
  e.g.
 
  @RequestMapping(...)
  public void doSomething(@RequestParameter(name=..) private String
 test)
 
 
  And of course conversion/validation of the request parameters.
 
 
  2014/1/14 Karl Kildén karl.kil...@gmail.com
 
   Hello,
 
  Any opinions on this
 
  https://weblogs.java.net/blog/mriem/archive/2014/01/13/jsf-
  tip-56-using-action-based-prototype-mojarra
 
  Basically it's regarding the common opinon that JavaEE should have a
  action
  based framework or support a action based style in JSF.
 
  cheers
 
 
 

Re: JSF 2.3

[Mike Kienenberger]

I am not an expert in action framework concepts, despite having used
struts for several years :) but I have some practical experience with
Struts, an action-based framework.   So hopefully I can comment on the
benefits of an action-based framework from the perspective a
component-based mindset.

I started writing web apps in a pure component-based web framework
(WebObjects/Objective C) back in the 90s, and around the year 2000,
give or take a couple years, wrote a major web application in
WebObjects/Java, which I continue to maintain to this day.   At some
point, maybe around 2005 or 2006, a political decision was pushed down
from above to switch the project to Struts, an action-based framework.

Eventually, the project was converted over to struts (which took
longer than developing the project in the first place, despite knowing
exactly what it was supposed to do), and it continues to run in struts
until this day.   Now there is a strong recommendation that the
project be switched over to JSF, which you might think that I, as a
component-based development mindset person, would agree, especially
since all of my other projects are in JSF these days.

However, as I considered the conversiion, I realized that the
action-based style provides some benefits for a public-facing
needs-to-be-secure-and-error-free application.

On a JSF page, anything that's a bean can have its methods called and
its values set.   There's no contract enforced between the view and
controller layer, so the designer has to insure that view beans aren't
providing non-view-bean access.   There's also no correspondence
between calling an action method and determining what field values
(component value bindings) are related to that method.

In Struts, you explicitly define which methods are actions (not every
public String or public void is neccessarily supposed to be an
action) and more importantly which fields (by defining the form) are
tied to which actions.   These value containers are completely
isolated from the real values, like UIInput.getSubmittedValue().   All
of this is enforced by the framework rather than designed-in by the
developer.This adds a lot more work, but will eliminate certain
classes of development errors due to the fact that you cannot break
the contract.   This is something that you probably could make happen
in JSF right now with enough extra work.

Action based framework action methods also operate on the idea of a
pipeline.   You don't call a single method, you call a chain of
methods, each of which, like the unix shell do one small job, then
forward to task on to the next thing.   Not being an
action-framework-mindset person, I probably don't fully take advantage
of what this is supposed to allow you to do.   it seems to me that it
is rare that a web form action can be broken up into many sharable
sequential input-output-based subtasks, other than processing a page
submit, then initializing the next page.  I used it a little bit to
add page-based state management to my application (webobjects, like
most component-based frameworks, was stateful, but struts was not
stateful).

I also cheated and used velocity as my view framework instead of
JSPs (just like I cheated and used facelets as my view framework in
JSF 1.1, which gave me a little bit more of a component-based
presentation layer. (velocity macros).

Explicitly initializing a page still seems good to me, even after 10
or 11 years of using JSF.

Integration and unit testing for a struts project currently is far
easier than testing a JSF project because of the explicit contract and
statelessness.

In an ideal world, I guess I'd like to upgrade this struts project so
that I am using facelets as the view templating system (rather than
velocity).   I'd like the project to remain stateless (my page state
system is more than adequate for the few things that need to retain
state).   I'd like to keep the explicit forced declaration of what
form values belong to which actions, and how those values are
validated for that action.  I don't want to lose my ability to test,
and maybe it is my own fault for not looking harder, but I haven't
found a good way to test JSF pages after all this time.  I'm not sure
if I care about action chaining, but I like explicit page
initialization.

So I'm glad to see that action support is being considered for JSF
2.3.   I think the explicit action/form declarations can be helpful.
 I'm glad that MyFaces is working on statelessness.   At some point,
it may indeed be practical to upgrade this project to JSF without
losing all of the benefits that I now, years later, see that struts
has provided.   I definitely didn't see any benefits when I initially
switched.

Hope this helps.


On Tue, Jan 14, 2014 at 6:24 AM, Christian Beikov
christian.bei...@gmail.com wrote:
 Could you explain what the actual benefits of the action based programming
 style are? I am missing the purpose/use cases for the actual need of such a
 feature.

 Thanks 

Re: JSF 2.3

[Christian Beikov]

See my answers inline.

Am 14.01.2014 16:40, schrieb Mike Kienenberger:

I am not an expert in action framework concepts, despite having used
struts for several years :) but I have some practical experience with
Struts, an action-based framework.   So hopefully I can comment on the
benefits of an action-based framework from the perspective a
component-based mindset.

I started writing web apps in a pure component-based web framework
(WebObjects/Objective C) back in the 90s, and around the year 2000,
give or take a couple years, wrote a major web application in
WebObjects/Java, which I continue to maintain to this day.   At some
point, maybe around 2005 or 2006, a political decision was pushed down
from above to switch the project to Struts, an action-based framework.

Eventually, the project was converted over to struts (which took
longer than developing the project in the first place, despite knowing
exactly what it was supposed to do), and it continues to run in struts
until this day.   Now there is a strong recommendation that the
project be switched over to JSF, which you might think that I, as a
component-based development mindset person, would agree, especially
since all of my other projects are in JSF these days.

However, as I considered the conversiion, I realized that the
action-based style provides some benefits for a public-facing
needs-to-be-secure-and-error-free application.
I am not quite sure about what you mean with that, please clarify. For 
me it sounds like you are refering to testability but please correct me 
if I am wrong.


On a JSF page, anything that's a bean can have its methods called and
its values set.   There's no contract enforced between the view and
controller layer, so the designer has to insure that view beans aren't
providing non-view-bean access.   There's also no correspondence
between calling an action method and determining what field values
(component value bindings) are related to that method.
Basicly what you wrote is true, but still, IMO this is no argument pro 
action based style. You can design your action methods just like in an 
action based framework, but on a higher level of abstraction. EL allows 
you to use parameters, so if you really want to be explicit about that, 
you can still do it. In fact I think that this is a nice approach that I 
successfully used in some projects, but it comes with some problems.
To wrap it up, you can be explicit about parameters and more or less 
design it to be stateless, but I guess most of the time this makes the 
whole thing more complicated.


In Struts, you explicitly define which methods are actions (not every
public String or public void is neccessarily supposed to be an
action) and more importantly which fields (by defining the form) are
tied to which actions.   These value containers are completely
isolated from the real values, like UIInput.getSubmittedValue().   All
of this is enforced by the framework rather than designed-in by the
developer.This adds a lot more work, but will eliminate certain
classes of development errors due to the fact that you cannot break
the contract.   This is something that you probably could make happen
in JSF right now with enough extra work.

Could you elaborate what kind of errors you are refering to?


Action based framework action methods also operate on the idea of a
pipeline.   You don't call a single method, you call a chain of
methods, each of which, like the unix shell do one small job, then
forward to task on to the next thing.   Not being an
action-framework-mindset person, I probably don't fully take advantage
of what this is supposed to allow you to do.   it seems to me that it
is rare that a web form action can be broken up into many sharable
sequential input-output-based subtasks, other than processing a page
submit, then initializing the next page.  I used it a little bit to
add page-based state management to my application (webobjects, like
most component-based frameworks, was stateful, but struts was not
stateful).

I also cheated and used velocity as my view framework instead of
JSPs (just like I cheated and used facelets as my view framework in
JSF 1.1, which gave me a little bit more of a component-based
presentation layer. (velocity macros).

Explicitly initializing a page still seems good to me, even after 10
or 11 years of using JSF.

Agree and I guess therefore the viewActions have been introduced in JSF 2.2


Integration and unit testing for a struts project currently is far
easier than testing a JSF project because of the explicit contract and
statelessness.
As written above, I guess if you design with testability in mind, you 
can also reach that with JSF.


In an ideal world, I guess I'd like to upgrade this struts project so
that I am using facelets as the view templating system (rather than
velocity).   I'd like the project to remain stateless (my page state
system is more than adequate for the few things that need to retain
state).   I'd like to 

Re: JSF 2.3

[Howard W. Smith, Jr.]

On Tue, Jan 14, 2014 at 10:40 AM, Mike Kienenberger mkien...@gmail.comwrote:

 Hope this helps.


+1 Mike and thanks for sharing.

it's good to hear/know this about struts. when i learned java ee 6 via java
ee 6 tutorial, of course, JSF is mentioned there; i don't remember struts
being mentioned there at all. so, my java web application development
experience/world has been JSF, and that is where my preference is today,
still.