Never mind, I just found the affecting code, you can mark resources as having value expressions, which I can do for the jsf.js file. This will open the door for solution 1 I have proposed, using direct bean calls/aka value expressions in the js codebase.
Werner Am Mi., 28. Sept. 2022 um 15:14 Uhr schrieb Werner Punz < [email protected]>: > Hi... > > Following, I am almost done with the integration on JSF 4.0 level (yes i > moved the code spec level wise already up, all namespaces are relegated, but > the codebase still works witzh 2.3, some fallback code was added). > But when checking the spec I noticed that something was added which did > not make it into the high level documentation: > https://jakarta.ee/specifications/faces/4.0/jsdoc/faces.html > > a new property was added contextPath which relegates to > ExternalContext.getRequestContextPath() > on javascript level, basically similar to the property separatorChar which > has been in there for ages. > Now to the problem and where I need feedback > Up until now this separator char on our side was added as url parameter to > the jsf.js loading request (code from the new impl) > > searchJsfJsFor(/separator=([^&;]*)/).orElse(":") > > You get the idea. First of all this code does not seem to work anymore. I > am not getting this parameter attached anymore. > But secondly I wonder if there is not a better way to get this in. Given > this wont be the only call. > Aka maybe bean resolution on load time on the code by searching for > #{xxxx} patterns straight in the js source, or template markers which > replace the template marker with the final result on resource loading level. > > Either way I would need a decision on this one and then a little bit of > help on the java side by either fixing this or implementing one of the 2 > solutions i proposed on code level. > > Werner > >
