[JAVASERVERFACES_SPEC_PUBLIC-611] Export FaceletFactory as a standard artifact vended from FactoryFinder. Created: 14/Aug/09  Updated: 23/Jun/13  Resolved: 29/Nov/12

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
Affects Version/s: 2.0
Fix Version/s: 2.2

Type: Improvement Priority: Major
Reporter: Ryan Lubke Assignee: Ed Burns
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 2 hours, 36 minutes
Original Estimate: Not Specified

Operating System: All
Platform: Macintosh

Attachments: Text File 20110914_i_spec_611.patch     Text File 20121109-1746-i_spec_611.patch     Text File changebundle.txt    
Issuezilla Id: 611
Status Whiteboard:

cat2 javadoc size_medium importance_medium


It would probably be useful for developers that wish to provide custom
functionality within the FaceletFactory to be able to do so in a standard fashion.

FactoryFinder.FACELET_FACTORY seems to be the logical place to expose such an
extension point.

Comment by Ed Burns [ 24/Sep/09 ]

Move to unscheduled target milestone

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "spec" subcomponent.

Comment by rogerk [ 05/Mar/10 ]


Comment by Ed Burns [ 22/Mar/10 ]


Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by Ed Burns [ 22/Jun/10 ]


Comment by Ed Burns [ 22/Jun/10 ]


Comment by Ed Burns [ 24/Jun/10 ]

Change target milestone.

Comment by rogerk [ 27/Oct/10 ]


Comment by Ed Burns [ 14/Sep/11 ]

Sending javaee7/src/web-facesconfig_2_2.xsds
Sending javaee7/test/web-facesconfig-standard.xml
Transmitting file data ..
Committed revision 49545.

Comment by Ed Burns [ 14/Sep/11 ]


Comment by Ed Burns [ 15/Sep/11 ]

Sending jsf-api/doc/web-facesconfig_2_2.xsd
Sending jsf-api/src/main/java/javax/faces/FactoryFinder.java
Sending jsf-api/src/main/java/javax/faces/package.html
Sending jsf-api/src/main/java/javax/faces/view/ViewDeclarationLanguageWrapper.java
Adding jsf-api/src/main/java/javax/faces/view/facelets/Facelet.java
Adding jsf-api/src/main/java/javax/faces/view/facelets/FaceletFactory.java
Adding jsf-api/src/main/java/javax/faces/view/facelets/FaceletFactoryWrapper.java
Sending jsf-api/src/main/java/javax/faces/view/facelets/package.html
Sending jsf-ri/resources/jsf-ri-config.xml
Sending jsf-ri/src/main/java/com/sun/faces/application/ApplicationAssociate.java
Sending jsf-ri/src/main/java/com/sun/faces/application/view/FaceletViewHandlingStrategy.java
Sending jsf-ri/src/main/java/com/sun/faces/application/view/ViewMetadataImpl.java
Sending jsf-ri/src/main/java/com/sun/faces/config/WebConfiguration.java
Sending jsf-ri/src/main/java/com/sun/faces/config/processor/FactoryConfigProcessor.java
Deleting jsf-ri/src/main/java/com/sun/faces/facelets/Facelet.java
Deleting jsf-ri/src/main/java/com/sun/faces/facelets/FaceletFactory.java
Sending jsf-ri/src/main/java/com/sun/faces/facelets/impl/DefaultFacelet.java
Sending jsf-ri/src/main/java/com/sun/faces/facelets/impl/DefaultFaceletContext.java
Sending jsf-ri/src/main/java/com/sun/faces/facelets/impl/DefaultFaceletFactory.java
Sending jsf-ri/src/main/java/com/sun/faces/facelets/tag/jsf/CompositeComponentTagHandler.java
Sending jsf-ri/test/com/sun/faces/application/TestApplicationImpl.java
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-611/build.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-611/i_spec_611_war
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-611/i_spec_611_war/pom.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-611/i_spec_611_war/src
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-611/i_spec_611_war/src/main
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-611/i_spec_611_war/src/main/java
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-611/i_spec_611_war/src/main/java/com
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-611/i_spec_611_war/src/main/java/com/sun
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-611/i_spec_611_war/src/main/java/com/sun/faces
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-611/i_spec_611_war/src/main/java/com/sun/faces/regression
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-611/i_spec_611_war/src/main/java/com/sun/faces/regression/i_spec_611_war
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-611/i_spec_611_war/src/main/java/com/sun/faces/regression/i_spec_611_war/MyFaceletFactory.java
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-611/i_spec_611_war/src/main/webapp
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-611/i_spec_611_war/src/main/webapp/WEB-INF
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-611/i_spec_611_war/src/main/webapp/WEB-INF/beans.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-611/i_spec_611_war/src/main/webapp/WEB-INF/faces-config.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-611/i_spec_611_war/src/main/webapp/WEB-INF/web.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-611/i_spec_611_war/src/main/webapp/i_spec_611_war.xhtml
Sending jsf-test/build.xml
Transmitting file data ...........................
Committed revision 9381.

Comment by Ed Burns [ 09/Nov/12 ]

Need to add FacesContext to signatures.

Comment by Ed Burns [ 09/Nov/12 ]

Patch to add FacesContext to all relevant methods of FaceletFactory.

Comment by Ed Burns [ 28/Nov/12 ]

Before proceeding, verify that DIRTY: < http://hudson-sca.us.oracle.com/view/MOJARRA_ALL/job/MOJARRA_TRUNK_GLASSFISH_3_1_2_2_NO_CLUSTER/40/ > and CLEAN: < http://tim-vm9.us.oracle.com:7070/hudson/view/Mojarra%20Trunk/job/trunk-test-glassfish-3_1_2_2/155/ > are clean.

Comment by Ed Burns [ 29/Nov/12 ]

Before proceeding, verify that CLEAN: < http://hudson-sca.us.oracle.com/view/MOJARRA_ALL/job/MOJARRA_TRUNK_GLASSFISH_3_1_2_2_NO_CLUSTER/42/ > is clean.

Comment by Ed Burns [ 30/Nov/12 ]

Mark closed when CLEAN: < http://hudson-sca.us.oracle.com/view/MOJARRA_ALL/job/MOJARRA_TRUNK_GLASSFISH_3_1_2_2_NO_CLUSTER/55/ > and CLEAN: < http://tim-vm9.us.oracle.com:7070/hudson/view/Mojarra%20Trunk/job/trunk-test-glassfish-3_1_2_2/175/ > are clean.

Comment by jasonzhang2002gmailcom [ 08/Jan/13 ]

javax.faces.view.facelets.FaceletFactory is not present in jsf-api-2.2.0-m07.

Is this desired feature or just an accident in building?



Comment by Ed Burns [ 09/Jan/13 ]

I intentionally removed that class based on feedback from Leonardo Uribe.

Comment by betermieux [ 07/Feb/13 ]


can you elaborate on the reasons to remove the FaceletFactory-API altogether? The context param "com.sun.faces.faceletFactory" was also removed, which was pretty crucial to my application. What would you suggest to use instead? I am relying on creating a single Facelet programmatically while delegating the creation of all other Facelets to the DefaultFaceletFactory.


Comment by betermieux [ 07/Feb/13 ]

OK, I found the mailinglist thread:

I will resort to the mailinglist for detailed questions.

Comment by Frank Caputo [ 07/Feb/13 ]

So Mojarra will 2.2 will not be compatible to 2.1?

Comment by betermieux [ 07/Feb/13 ]

I am not able to post to the mailinglist, so I will continue the discussion here.

I read Leonardo Uribes concerns, but I don't think that adding Application.createComponent(context, taglibURI, tagName, attributes) is enough to remove the FaceletFactory interface altogether. It is arguable if JSF-coders should be able to generate Facelets programmatically or add Taghandlers to the tree, but at the moment, it is not possible to create template clients programmatically. For example <ui:include/> does not generate a UIComponent, Application.createComponent(context, "http://java.sun.com/jsf/facelets", "include",...) returns null. My programmatically generated Facelet only used TemplateClient-based TagHandlers, so the concerns of Leonardo regarding duplicate or missing IDs don't apply, since the Tags never generate a UIComponent.

So Mojarra 2.2 will not be compatible to 2.1 if you used the context parameter com.sun.faces.faceletFactory to delegate the DefaultFaceletFactory. The only solution at the moment would be to subclass DefaultFaceletFactory and hack through ApplicationAssociate. There must be a better solution.


Comment by jasonzhang2002gmailcom [ 07/Feb/13 ]

My Application depends on FaceletFactory heavily. What I need is a feature to include a facelet fragment(xhtml) to my UI tree. This fragment is neither composite component, nor ui:component. Most, it is a panelGroup.

I use code like this

f = faceletFactory.getFacelet(resource.getURL());
UIPanel panel = (UIPanel) application.createComponent(UIPanel.COMPONENT_TYPE);
f.apply(fctx, panel);

If FacelteFactory is removed, I can not find a way to turn a xhtml fragment into component.


Comment by Ed Burns [ 07/Feb/13 ]

S> can you elaborate on the reasons to remove the FaceletFactory-API
S> altogether? The context param "com.sun.faces.faceletFactory" was also
S> removed, which was pretty crucial to my application. What would you
S> suggest to use instead? I am relying on creating a single Facelet
S> programmatically while delegating the creation of all other Facelets
S> to the DefaultFaceletFactory.

We decided to remove it because it wasn't possible to cleanly decorate
it. There were leaking abstractions.

FC> So Mojarra will 2.2 will not be compatible to 2.1?

When it comes to com.sun.faces parameters that are not a part of the
spec, there is no guarantee that it will be compatible across releases.

S> I read Leonardo Uribes concerns, but I don't think that adding
S> Application.createComponent(context, taglibURI, tagName, attributes)
S> is enough to remove the FaceletFactory interface altogether.


S> TagHandlers, so the concerns of Leonardo regarding duplicate or
S> missing IDs don't apply, since the Tags never generate a UIComponent.

I see your point, but I must give appropriate weight to Leonardo's
comments as he is the lead implementor of MyFaces.

S> So Mojarra 2.2 will not be compatible to 2.1 if you used the context
S> parameter com.sun.faces.faceletFactory to delegate the
S> DefaultFaceletFactory.


JZ> If FacelteFactory is removed, I can not find a way to turn a xhtml
JZ> fragment into component.

Ahh, I see what happened here.

When I initially implemented the standardized attempt at FaceletFactory,
in r9371, I removed the context param, since if it was standardized it would no longer be necessary.

r9381 | edburns | 2011-09-15 11:36:09 -0400 (Thu, 15 Sep 2011) | 128 lines

Expose FaceletFactory and a wrapper for same http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-611

This commit replaces two tests with one, thereby reducing the
expected.passed.test.count by one. Please update the hudson builds

M jsf-ri/src/main/java/com/sun/faces/config/WebConfiguration.java

  • Remove supoprt for the com.sun.faces.faceletFactory config param.

But when I removed the standardized FaceletFactory, in r11053, I didn't
put back the context param.

Would you be satisfied if I just put it back and it worked as in 2.1?

Comment by jasonzhang2002gmailcom [ 08/Feb/13 ]

Leave it as it is in 2.1 is good. At least I have a way to look up FaceletFactory.
On the other hand, FaceletFactory provides many useful features which are essential sometime. It will be good to expose it and let the user to use it as his own risk.

Comment by betermieux [ 08/Feb/13 ]

I have slept over the issue and rethought about Leonardo's comments. Most of his concerns are about creating Components using the FaceletFactory. I am fine with restoring 2.1 functionality and writing some words of warning in javadoc. As Jason stated, there are many more uses of a custom FaceletFactory, which should not be limited without a reason.

Comment by Frank Caputo [ 09/Feb/13 ]

Restoring 2.1 behavior would be fine.

Comment by jasonzhang2002gmailcom [ 21/Jun/13 ]

I checked that FaceletFactory is not in the official 2.2 release. There is no way to create a component from a xhtml fragment. For example, I have a resource.xhtml using ui:compoonent. I would like to turn it into a component. Clearly Application.createComponent(FacesContext, Resource) is only useful for composite component, but I need a approach to create simple component.

Comment by lu4242 [ 23/Jun/13 ]

From my point of view, the spec as is in JSF 2.2 should support something like this:

// Dynamic include
Map<String, Object> attributes = new HashMap<String, Object>();
attributes.put("src", "/addSimpleIncludeVDL_1_1.xhtml");
UIComponent component = vdl.createComponent(facesContext,
"include", attributes);

The idea is very simple: if multiple components are inside an xhtml fragment, just return one parent component that wraps everything. If it is just one, return the same component. I made a working prototype in MyFaces some weeks ago about this idea and it works very well, because inside vdl.createComponent(...) it is possible to put the necessary code to make it work programatically, something that just does not work well doing it through FaceletFactory, which I still consider a bad idea.

I like this approach because it is totally "decoupled" from the underlying vdl implementation.

Note I don't know if that approach works for Mojarra, or if the original idea has this in mind(I suppose no).

Generated at Mon Feb 27 17:20:05 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.