Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Works as designed
    • Affects Version/s: 2.2
    • Fix Version/s: 2.2
    • Component/s: None
    • Labels:
      None

      Description

      The goal of this feature is to define a standard structure for a JSF 2.2 application. And here is the proposal :

      Resources


      The css, js, images files must be stored in the resources folder like for JSF 2.0

      • resources
      Views


      The views must be stored in a folder named views

      • views


      The protected views must be stored in a sub folder named protected

      • views
        • protected
      Templates


      The templates must be stored in a folder named templates

      • templates
        • mytemplate
          • css
          • js
          • images
          • template.xhtml
          • template.png
          • template.xml
      Tasks Flows (modules)


      The modules must be stored in a folder named modules. Note that the structure of a Task flow has not yet been set.

      • modules

      And we end up finally with this standard and cohesive structure :

      • app
        • resources
        • views
        • templates
        • modules
        • web-inf
      Externalization of the JSF artifacts


      The folders must be externalized and stored out of the WAR file to enlarge the possibilities for new ideas and systems.

        Activity

        Hide
        Neil Griffin added a comment -

        Should templates be under /WEB-INF in order to protect them from direct access by the user-agent?

        Show
        Neil Griffin added a comment - Should templates be under /WEB-INF in order to protect them from direct access by the user-agent?
        Hide
        lamine_ba added a comment -

        Yes Neil, that is the next step. Find the right location. Can we protect the artifacts from direct access by the user-agent if they are not under /WEB-INF? If so, I would love to have this solution..

        Show
        lamine_ba added a comment - Yes Neil, that is the next step. Find the right location. Can we protect the artifacts from direct access by the user-agent if they are not under /WEB-INF? If so, I would love to have this solution..
        Hide
        Neil Griffin added a comment -

        Well, I don't know if this is the most elegant solution, and it's certainly not zero-config, but this is what I do to protect XHTML files from direct access via WEB-INF/web.xml:

        <!-- Prevent direct access to Facelet view XHTML by the userAgent (browser). -->
        <security-constraint>
        <web-resource-collection>
        <web-resource-name>Facelet View XHTML</web-resource-name>
        <url-pattern>*.xhtml</url-pattern>
        </web-resource-collection>
        <auth-constraint>
        <role-name>nobody</role-name>
        </auth-constraint>
        </security-constraint>
        <security-role>
        <role-name>nobody</role-name>
        </security-role>

        Show
        Neil Griffin added a comment - Well, I don't know if this is the most elegant solution, and it's certainly not zero-config, but this is what I do to protect XHTML files from direct access via WEB-INF/web.xml: <!-- Prevent direct access to Facelet view XHTML by the userAgent (browser). --> <security-constraint> <web-resource-collection> <web-resource-name>Facelet View XHTML</web-resource-name> <url-pattern>*.xhtml</url-pattern> </web-resource-collection> <auth-constraint> <role-name>nobody</role-name> </auth-constraint> </security-constraint> <security-role> <role-name>nobody</role-name> </security-role>
        Hide
        lu4242 added a comment -

        MyGourmet JSF examples here:

        https://github.com/jsflive/mygourmet-ee

        uses META-INF/templates. I think it has more sense to use that location, but I have seen other applications using WEB-INF/templates too. I'm not an EG expert, but I vote for META-INF/templates.

        Show
        lu4242 added a comment - MyGourmet JSF examples here: https://github.com/jsflive/mygourmet-ee uses META-INF/templates. I think it has more sense to use that location, but I have seen other applications using WEB-INF/templates too. I'm not an EG expert, but I vote for META-INF/templates.
        Hide
        lamine_ba added a comment - - edited

        Yes the solution proposed by Neil would be very nice if we could make it automatic. Can we add this behavior at runtime? Regarding the proposal of lu4242, Yes like the resources directory of JSF 2.0, the templates can be stored in the META-INF/templates directory. One can have the need to package things in a jar file.

        Show
        lamine_ba added a comment - - edited Yes the solution proposed by Neil would be very nice if we could make it automatic. Can we add this behavior at runtime? Regarding the proposal of lu4242, Yes like the resources directory of JSF 2.0, the templates can be stored in the META-INF/templates directory. One can have the need to package things in a jar file.
        Hide
        lamine_ba added a comment -

        If JSF 2.2 has a dependency with the Servlet 3.0 api. I think the solution that Neil comes with can be implemented using the web-fragment feature.

        1) http://www.javabeat.net/articles/97-new-features-in-servlets-30-2.html

        We just provide and write this default behavior in a predefined web-fragment.xml thus we can bring an automatic and default protection for our standard folders from direct access by the user-agent.

        Show
        lamine_ba added a comment - If JSF 2.2 has a dependency with the Servlet 3.0 api. I think the solution that Neil comes with can be implemented using the web-fragment feature. 1) http://www.javabeat.net/articles/97-new-features-in-servlets-30-2.html We just provide and write this default behavior in a predefined web-fragment.xml thus we can bring an automatic and default protection for our standard folders from direct access by the user-agent.
        Hide
        Neil Griffin added a comment -

        I think we need to maintain compatibility with Servlet 2.5 (Tomcat 6) for JSF 2.2

        So I think the web fragment feature could be utilized, so long as developers realize that a zero-config feature like that will only get activated if they deploy their webapps/portlets in Servlet 3.0 (Tomcat 7).

        Show
        Neil Griffin added a comment - I think we need to maintain compatibility with Servlet 2.5 (Tomcat 6) for JSF 2.2 So I think the web fragment feature could be utilized, so long as developers realize that a zero-config feature like that will only get activated if they deploy their webapps/portlets in Servlet 3.0 (Tomcat 7).
        Hide
        lamine_ba added a comment -

        Yes I agree but having a default web-fragment.xml file does not mean, we will not be compatible with Servlet 2.5. This api does not even know what a web-fragment.xml is all about. It means only when a developer is using a server like Tomcat 6, he has to do things manually but when he moves to use tomcat 7, things are done automatically for him. And that is another good reason for a developer to make the switch...

        Show
        lamine_ba added a comment - Yes I agree but having a default web-fragment.xml file does not mean, we will not be compatible with Servlet 2.5. This api does not even know what a web-fragment.xml is all about. It means only when a developer is using a server like Tomcat 6, he has to do things manually but when he moves to use tomcat 7, things are done automatically for him. And that is another good reason for a developer to make the switch...
        Hide
        Neil Griffin added a comment -

        Right, I think you and I basically just said the same thing.

        Show
        Neil Griffin added a comment - Right, I think you and I basically just said the same thing.
        Hide
        lamine_ba added a comment -

        I'm closing this feature now. Thank you all for your clever comments.

        As blake sullivan wrote, it is better to make it a recommended best practice.
        Thus it will be implemented as a JSF 2.2 maven archetype. In this implementation, you will see also the solution described by Neil Griffin to protect the artifacts from direct access by the user-agent. This behavior will be automated and implemented using the Servlet 3.0 web-fragment feature. So if you are not using this api, please do it yourself.

        Thanks.

        Show
        lamine_ba added a comment - I'm closing this feature now. Thank you all for your clever comments. As blake sullivan wrote, it is better to make it a recommended best practice. Thus it will be implemented as a JSF 2.2 maven archetype. In this implementation, you will see also the solution described by Neil Griffin to protect the artifacts from direct access by the user-agent. This behavior will be automated and implemented using the Servlet 3.0 web-fragment feature. So if you are not using this api, please do it yourself. Thanks.
        Hide
        Manfred Riem added a comment -

        Closing resolved issue out

        Show
        Manfred Riem added a comment - Closing resolved issue out

          People

          • Assignee:
            Ed Burns
            Reporter:
            lamine_ba
          • Votes:
            2 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: