CDI: Faces lifecycle events as CDI events and/or annotation processing

[pizzi80]

It would be nice to replace the f:metadata and f:viewAction with a @PreRenderView, for example:

@Named
@RequestScoped
public class Bean {

   private String input;   // get + set
   private Pojo pojo;   // get + set

   @PreRenderView
   public void action() {
      // compute some login on some bean property
      // bound to form inputs
   }

}

[tandraschko]

Thats not good IMO, we have this in deltaspike

It requires to map the bean to a view, where you now have a stronger bidirectional mapping The strengt of JSF was always to have less JSF code in the backing bean

[tandraschko]

Also related to: https://github.com/jakartaee/faces/issues/1501

[tandraschko]

And https://github.com/jakartaee/faces/issues/1443

Similar to your request, just the CDI way

[pizzi80]

Actually it's not clear how CDI's @PostConstruct relates to Faces' lifecycle

At the moment It's not easy to work with a @RequestScoped bean combining:

• ajax submit and validation
• conditional rendering
• get parameters processing
• inputHidden binding

Also f:metadata with templating can be defined only in a super strict manner ... ui:define as first child of a ui:composition with a template with an f:view as first child of the html tag ..... o_O

Overall it's very unintuitive

I know that you and other super seasoned Faces committers have crystal clear how everythings works at which line of code and how things get reworked during years, but it's not really easy for a normal dev

This is probably because only Faces 4 it's CDI only? ... and things has been modified on the go during the last 10+ years... ?

Thanks to OmniFaces we have o:inputHidden and @Param which simplify a lot but it's an external library...

Also DeltaSpike it's an external library, I don't even know if it's still supported or if support Faces 4+ ... the website it's the same since 5 years and on github there are no releases

[tandraschko]

PostConstruct is of course not clear as its lazy There is no fixed point from JSF perspective, only from CDI perspective

It feels like you mix a lot of points here and there are many ways to overcome such stuff

Soften f:metadata is a great Idea in general and there is already a issue about it

Deltaspike had a release some months ago Just not much commiters to update homepage and so on

[tandraschko]

We can just reuse @View for this:

void myMethod(@Observes PreRenderViewEvent event)

Or

void myMethod(@Observes @View("index.xhtml") PreRenderViewEvent event)

[tandraschko]

Easy, 100% CDI, easy to implement with some hundred lines of code Already mentioned in some other spec ideas here

[pizzi80]

I would like to have a @ViewId which could be reused even for this:

void myMethod(@Observes PreRenderViewEvent event)

Or

void myMethod(@Observes @ViewId("index.xhtml") PreRenderViewEvent event)

Yes something like that is perfect,

As you said it's similar to DeltaSpike Faces module!

[arjantijms]

Also strongly related: https://github.com/jakartaee/faces/issues/1580

[pizzi80]

Also strongly related: #1580

OMG now I remember the discussion! I've read it some years ago! ...

I think that this is very useful to have a 100% CDI version of f:metadata

at the moment I'm using OmniFaces @Param + @PostConstruct to process GET parameters but when you need also to process fields coming from o:inputHidden you need to call a method in the PreRenderView phase

for example when you're working with f:view transient="true" and @RequestScoped you have some inputHidden to keep the state across requests ...

[tandraschko]

closing in favor of: #1501

im working a prototype in MF now, its really really only a few lines of code...