Bean based alternative for a view action on a page

[mnriem]

E.g similar to https://github.com/manorrock/oyena/tree/master/lifecycle/action

Annotations

@ ActionHeaderParameter @ ActionMapping @ ActionPathParameter @ ActionQueryParameter

[tandraschko]

Just my 2 cents: My current opinion is that it better fits in your addon library, im monitoring primefaces community since almost 10 years and there is almost noone asking for this feature It would be a shame that we invest many time and then its not often used like flows

Also see https://markmail.org/message/qanqdwoxpjtacbtw#query:+page:1+mid:fvdkd7xnc5gbgbsa+state:results

[tandraschko]

My expirience is that asp.net MVC like action frameworks were used somewhere between JSF and newer technologies like angular and react

Therefore JSF Users would like to just use JSF or directly use angular etc and their routing

[arjantijms]

This one is a little bit different though. I'm not sure whether I explained it more in detail here or at the list, but I did explain it for the Faces planning.

This is not about a full scale framework of any kind. The term "framework" makes it sound way bigger than it actually is.

What this boils down to is a bean based alternative for a view action on a page. Not rarely we now have to have an empty page with just a view action on it to respond to certain requests. That's a bit cumbersome and verbose, though it does do the trick.

Having a bean respond to a view action directly, without having to setup an empty page, feels more modern and lightweight. So this is definitely not a replacement for Spring MVC and certainly not for Jakarta REST.

So to sum up, this is a simplification for f:viewAction.

[arjantijms]

p.s. the f:viewAction simplification is of course what I intended with this. I can't speak directly for Manfred whether he has different ideas.

[tandraschko]

I see Then i would suggest the following changes: 1) call the main annotation something like ViewActionMapping (viewAction is a important keyword) 2) remove the word action or viewAction from the header/query param annotation and make them global useable with @Inject 3) do we really need the path-param thing?

2 and 3 should actually go into servlet to remove duplication with jaxrs, thats IMO the only correct way for future

[arjantijms]

1. I like that idea, sounds better that way indeed.

2 and 3. You are reading my mind regarding Servlet. But Jakarta REST (Jaxrs) is currently independent on Servlet in theory, although practically most implementations are based on Servlet. I think the original idea of Jaxrs was to be its own framework, with its own mvc, own http engine, own security, own dependency injection, etc etc

So to align better here, the first step is to have Jakarta REST depend on a (subset) of Servlet I guess.

[tandraschko]

Can you talk with the servlet and jaxrs guys? I think we should not introduce it without it

[arjantijms]

@tandraschko I started some conversation about this a while ago. There was some interest at least from the servlet side of things. I could try it again though, but this will not likely move fast.

We do have a need for an annotation that's more specific to faces though, to indicate something is listening to a view id. A view id is I think reasonable different from a URL expression to warrant its own annotation.

I was thinking along the lines of something like @FacesViewId, to indicate that a method or an entire class is to be invoked for a logical view id. This is useful for at least the programmatic Facelet/VDL feature as described here:

https://arjan-tijms.omnifaces.org/2011/09/single-class-pure-java-jsf-application.html

See also the plan here: https://projects.eclipse.org/projects/ee4j.faces/releases/4.0

Cagatay btw also talked about both this view action and the programmatic java pages: https://www.crowdcast.io/e/jakartaoneturkish_aug21_2 (around 03:08:05).

[tandraschko]

IMO ViewActionMapping is faces-specifiec enough and ok, so +1 Injecting url or header params is not

[tandraschko]

i have the following idea:

Introduce a ViewActionEvent (similar like PostAddToViewEvent)

and

afterwards make system events observeable like in DeltaSpike:

void myListener(@Observes PreRenderViewEvent event)

and

hopefully we can also implement something like

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

or even

void myListener(@Observes @View("myfolder/*.xhtml") PreRenderViewEvent event)

[tandraschko]

also users can easily access parameters via FacesContext currently, maybe servlet api implements later cdi-producers for params

then this ticket is really almost no effort

[tandraschko]

related to https://github.com/eclipse-ee4j/faces-api/issues/1443

[tandraschko]

ping @arjantijms @BalusC everyone of us doesnt have much time for such tickets but i would like to push some features, so it would be great if we could at least discuss about such things so i can push it to MyFaces and i will try that someeone can also push it to Mojarra

[arjantijms]

@tandraschko I have a bit of other work to finish this week, but will return to this issue (and other Faces issues) towards the end of this week, and at the very latest beginning next week.

We're already passed our own deadline of 15 October, so we probably should start moving whatever still has many open questions to the next version of Faces.

[arjantijms]

Hi all (@tandraschko @mnriem @BalusC and others),

Clearly this one didn't make it into 4.0. Do we want to try again for Faces.next?

[tandraschko]

Sure If we would like to go the way we discussed above, we should also create a servlet Feature request soon

[mnriem]

I am closing this one as I have not found anyone to pick it up or found time to work on it myself.

[arjantijms]

Let's try this again for 5.0.

[volosied]

Just trying to understand this change better.

Arjan had stated the following in an earlier comment:

• Not rarely we now have to have an empty page with just a view action on it to respond to certain requests.
  • Can someone link an example of this? Or explain what kind of requests?
• Having a bean respond to a view action directly
  • Would a URL still be mapped to a bean's method, as demonstrated by @mnriem proposal?

[mnriem]

@arjantijms @volosied @tandraschko What is the proposal here?

[mnriem]

@arjantijms @BalusC @volosied @tandraschko Any comments?

[volosied]

I'm not entirely sure myself. Hope @BalusC or @arjantijms can explain in more detail.

[tandraschko]

i have the following idea:

Introduce a ViewActionEvent (similar like PostAddToViewEvent)

and

afterwards make system events observeable like in DeltaSpike:

void myListener(@Observes PreRenderViewEvent event)

and

hopefully we can also implement something like

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

or even

void myListener(@Observes @View("myfolder/*.xhtml") PreRenderViewEvent event)

Im still for this version, it's better fit JSF and easy to implement We can even close this issue and create a new one for it

[tandraschko]

And we plan to make events observeable anyway

[mnriem]

Closing out as not considering it at the moment. @tandraschko Feel free to open a more pointed proposal as outlined in your comments.