[solved] DynaView doesn't work with #{resource['x']}

Splash Forums PrettyFaces Users [solved] DynaView doesn't work with #{resource['x']}

This topic contains 11 replies, has 3 voices, and was last updated by  Lincoln Baxter III 11 years, 5 months ago.

Viewing 12 posts - 1 through 12 (of 12 total)
  • Author
  • #17768



    I’m using prettyfaces-jsf2:3.0.1

    I’m trying to create a framework for my application so I have some pages that are located in META-INF/resources. I have the following declaration in pretty-config.xml:

    <url-mapping id="javascript">
    <pattern value="/pages/javascript.xhtml"/>

    When I try to open the page, I receive error 500 with java.util.regex.PatternSyntaxException: Illegal repetition near index 0


    I debugged PrettyFilter.doFilter() -> PrettyContext.shouldProcessDynaview() -> UrlMapping.isDynaView() -> Expressions.isEL() and got the following regular expression:


    Square brackets and apostrophe is not allowed. Is this a missing functionality?

    Thanks for the attention,



    It really looks like the regular expression isn’t correct.

    Could you create a ticket for this?



    <view-id>#{resource['javascript.xhtml']}</view-id> will not work. The view ID must be provided by an action method, not any other type of expression.

    This is currently a limitation of the framework, but could possibly be enhanced.

    Until that happens, you can do this instead:


    Or something similar. The resource is still there, you just need to provide the path in a way that PrettyFaces understands.

    /faces/resources/javascript.xhtml == #{resource['javascript.xhtml']}

    I may not have the path exactly right, but that’s the idea.


    I really like the idea of supporting value expressions here. This could be very useful in some situations. We should create a ticket for this feature.

    Nevertheless I think the regular expression for EL expressions is not correct. Theoretically someone could build an expression like this one:


    I think this would be a valid method binding, right?



    Yes, Lincoln, I think it’s : /faces/javax.faces.resource/

    OK, I’ll try to use that for the moment.

    From what I’ve understood looking at the sources, it’s possible to create an implementation of PathParameterProcessor that handles this type of expressions. Am I correct?



    The syntax /faces/javax.faces.resource/javascript.xhtml doesn’t work either. It’s not understood as a ResourceRequest. When I use it with h:link a span is rendered and it says that no navigation case is found.

    At line 502, MultiViewHandler is looking directly for a file at that location:


    It’s not possible to reference the xhtml file in META-INFresources inside the jar file that is in WEB-INFlib. The resource should be resolved at a certain step.



    I have moved the xhtml files from the library (jar) to my application (war). Obviously for the moment resources is not intended to contain xhtml files that you can navigate to.


    Ah, actually I forgot. You don’t even need /resources…

    Any file under JAR:/META-INF/resources/* will be hosted as if it were at the root of the application (obviously folder structure still applies, so /META-INF/resources/foo/bar.xhtml will be hosted at /app/faces/foo/bar.xhtml

    See JSF ref docs for a start: https://javaserverfaces.dev.java.net/nonav/docs/2.0/javadocs/index.html

    However, that doesn’t give the full explanation. Anyway… that should work. Just put your file in JAR:/META-INF/resources/javascript.xhtml, and the file will be accessible as if it were in /WebContent/.

    So http://localhost:8080/app/faces/javascript.xhtml should be the location of the file.

    Also note that you can place additional configuration files in the JAR:/META-INF/pretty-config.xml file, and these will be merged into the master configuration when the server starts. This can help keep the configuration clean.


    Also, that EL pattern is correct. Square brackets in regular expressions denote custom character classes. See reference: (http://ocpsoft.com/opensource/guide-to-regular-expressions-in-java-part-1/#charclasses)

    Notice the […] to the right of each character class — this is valid syntax that is equivalent to the shorthand notation shown on the left, but also allows more customization and control.


    But that does not mean that […] will be a valid EL expression, it just means that the Regex engine understands those characters, and that they have meaning which does not literally mean the ” characters :)



    You’re correct about the JAR:/META-INF/resources/* being transparent. I overlooked the documentation.

    As to the EL pattern, it’s correct for the purpose it is intended at the moment. Maybe it doesn’t support the full EL syntax but obviously there is no need for modifications in my case.

    Thanks :)


    No problem! I can’t blame you for missing the docs… they are pretty obtuse…

Viewing 12 posts - 1 through 12 (of 12 total)

The forum ‘PrettyFaces Users’ is closed to new topics and replies.

Comments are closed.