Alternative ways to provide JSF pages (or another web resources)

[lfryc]

We have started this discussion on JHackFest in Brno.

----

Ultimately, we should be able to use following methods to describe resources as JSF/XHTML pages:

• in javadoc
• using ShrinkWrap asset
• using ShrinkWrap Descriptor for given format
• referencing external/classpath file

Why?

We should allow to reference not only external files, but also allow to build true micro-deployments.

This will enable test-driven development in frameworks like JSF.

User can define very small fragment and test how it works with defined model.

JavaDoc

/**
 * @resource index.xhtml
 *
 *     <h:commandLink action="list" />
 *
 * @resource list.xhtml
 * 
 *     <rich:list value="#{...}">
 * 
 * @resource myscript.js
 *     
 *     console.log("heya, there!");
 */
@Test
public void myTest() {
    ...
}

Notes:

The conflicts of same files between tests needs to be solved.

In JSF, we can leverage own Facelet factory to register XHTMLs for each test specifically.

The comments (JavaDoc) can be pre-processed by APT compiler (integrated to JDK >6).

ShrinkWrap asset

Inspired by TestAutocompleteBehaviors

FaceletAsset p = new FaceletAsset();

p.body("<h:form id='form'>");
p.body("    <r:autocomplete id='autocomplete' autocompleteList='#{autocompleteBean.suggestions}'>");
p.body("        <r:ajax event='blur' listener='#{autocompleteBean.actionListener}' />");
p.body("    </r:autocomplete>");
p.body("</h:form>");

archive.addAsWebResource(p, "index.xhtml");

We must deal with quotations marks by replacing them with apostrophes - note that this is allowed by XML, no pre-processing required (even though it looks unfamiliar).

ShrinkWrap Descriptor

Descriptors.create(RichFacesDescriptor.class)
    .autocomplete()
        .id("autocomplete")
        .autocompleteList("#{autocompleteBean.suggestions}")
        .behavior()
            .ajax()
                .event("blur")
                .listener("#{autocompleteBean.actionListener}");

Ken's favorite...

Referencing external file

ShrinkWrap.create(WebArchive.class).addWebAppResource("index.xhtml")

note that the API is simplified from the version using addWebResource(new File("src/main/webapp/index.xhtml"), "index.xhtml");

[lfryc]

One concern which Brian came with is ability to copy a code you author from the test to a actual page source.

There the JavaDoc is a winner of definitions inside a test,

but you still need to deal with asterisk signs.

----

The IDEs could also help here since they could understand ShrinkWrap syntax - e.g. allow to view a external file content in contextual help (tooltip) or offer navigation from "index.xhtml" to the source.

[kenfinni]

I admit to being confused by the JavaDoc example. Is that saying that I want to make a JSF page comprised of those these resources, and then the indented lines are the resource content?

If so, I guess it could be useful, it just seems a little unusual. And only beneficial for a couple of lines of facelet code, otherwise it would be unmanageable.

Yes I do like the idea of taking a Descriptor like approach , but also appreciate that that solution is not appropriate all the time.

In terms of Brians desire to copy existing code into a test from a page, I may have misunderstood what I meant but I thought that would fit better with either Shrinkwrap Asset or Referencing an external file, as opposed to JavaDoc.

[lfryc]

Ken Finnigan wrote:

I admit to being confused by the JavaDoc example. Is that saying that I want to make a JSF page comprised of those these resources, and then the indented lines are the resource content?

If so, I guess it could be useful, it just seems a little unusual. And only beneficial for a couple of lines of facelet code, otherwise it would be unmanageable.

Yeah, the target for Javadoc-defined resources are one-liners - it is really beneficial for framework developers/testers, but it can be also natural for using in your playground - when you are evaluating technology using test-driven approach.

Yes I do like the idea of taking a Descriptor like approach , but also appreciate that that solution is not appropriate all the time.

I also appreciate its benefits: for example you can create default template and then customize it for particular use cases.

The similar concept (but very limited) might be achieved using FaceletAsset approach.